AMS cloud migration provides lot of benefits -
- Extend the server capacity based on the demand
- Quick spinning up of new servers
- Less management and initial setup cost
- Better security and monitoring of platform
- Streamlined process
- Higher availability
Below are some of the important items need attention while migrating the On-Premises AEM platform to AMS Cloud.
Deployment options:
There is different deployment options available based on the SLA
The Deployment option should be selected based on the requirement, ideally, Dev, QA, UAT, Stage, and PROD environments will be used.The Dev and QA environments can be deployed with "Non-High Availability" deployment option, UAT environment can be deployed with "High Availability" and "Geo/High Availability" deployment option should be ideal for Stage and Prod environments.
Ideally the Stage and Prod environment should be with same setup.
The Capacity requirement should be defined - Ideally the disk space, S3 bucket size, and the Server memory and CPU.
CDN:
Content Delivery Network (CDN) are distributed servers help to improve the end user performance by caching the content and serving the requests from nearby servers.
Akmai or CloudFront can be used in this case, better to use Cloud Front as this is part of the AWS Cloud and less license cost compared to Akamai but at the same time Akmai provides more configuration options.
SSL Certificate:
The client SSL certificate should be installed on AWS ELB(Enterprise Load Balancer) and CloudFront if used, SAN certificate will be the right option to include the certificate in ELB and CDN - There is a restriction from CloudFront as of now it only accepts single certificate.
Content/Asset Migration:
This is one of the important activity as part of the migration process, the option should be chosen based on the requirement
CRX2Oak Migration Tool should be used if the content/asset size is large and the requirement is to migrate the version histories.
Some of the additional items to be considered during migration:
Additional resources(CPU) to support the migration - The environment will be impacted during the migration so the resources should increaed to avoid the impact on the authors.
The content/asset from the author should be migrated to AMS Author and Publisher to AMS Publisher - The will help to avoid the issues with deactivated assets and modified but not published assets. Tree activation form(selecting the appropriate options)from the author will be another option but it will create performance issues.
DAM asset related workflow(Update and Create) should be disabled in Author - this will help as to speed up the migration and also to avoid changing the last modified date and modified by values of content/assets
Curl command to install the packages - if the package based approach is considered then use the CURL command to install the packages that will provide better tracking options and performance.
Temp folder disk apace availability - Make sure the On-Premises server is having enough temp space to build the larger packages if the package based migration approach is considered, better to point the temp folder to the location(-Djava.io.tmpdir=/path/to/tmpdir) that has required space.
To avoid the individual migrations the AMS servers can be built from the copy of on-premises servers so that only the delta changes need to be migrated later.
The CRX2Oak migration tool can be used to migrate the complete repository.
Users/Groups Migration:
The required users/groups should be set up in AMS platform, the below approaches can be used
Content Delivery Network (CDN) are distributed servers help to improve the end user performance by caching the content and serving the requests from nearby servers.
Akmai or CloudFront can be used in this case, better to use Cloud Front as this is part of the AWS Cloud and less license cost compared to Akamai but at the same time Akmai provides more configuration options.
SSL Certificate:
The client SSL certificate should be installed on AWS ELB(Enterprise Load Balancer) and CloudFront if used, SAN certificate will be the right option to include the certificate in ELB and CDN - There is a restriction from CloudFront as of now it only accepts single certificate.
Content/Asset Migration:
This is one of the important activity as part of the migration process, the option should be chosen based on the requirement
- Package based migration
- CRX2Oak Migration Tool
CRX2Oak Migration Tool should be used if the content/asset size is large and the requirement is to migrate the version histories.
Some of the additional items to be considered during migration:
Additional resources(CPU) to support the migration - The environment will be impacted during the migration so the resources should increaed to avoid the impact on the authors.
The content/asset from the author should be migrated to AMS Author and Publisher to AMS Publisher - The will help to avoid the issues with deactivated assets and modified but not published assets. Tree activation form(selecting the appropriate options)from the author will be another option but it will create performance issues.
DAM asset related workflow(Update and Create) should be disabled in Author - this will help as to speed up the migration and also to avoid changing the last modified date and modified by values of content/assets
Curl command to install the packages - if the package based approach is considered then use the CURL command to install the packages that will provide better tracking options and performance.
Temp folder disk apace availability - Make sure the On-Premises server is having enough temp space to build the larger packages if the package based migration approach is considered, better to point the temp folder to the location(-Djava.io.tmpdir=/path/to/tmpdir) that has required space.
To avoid the individual migrations the AMS servers can be built from the copy of on-premises servers so that only the delta changes need to be migrated later.
The CRX2Oak migration tool can be used to migrate the complete repository.
Users/Groups Migration:
The required users/groups should be set up in AMS platform, the below approaches can be used
- Manually setup users/groups in the AMS platform - This approach can be used if the user and groups are minimal
- Migrate the users/groups from On-Premises to AMS platform - This approach can be used if the user and groups are more, use the acs-commons ACL Packager to migrate the required users and groups to AMS platform, the acs-commons package should be installed in On-Premises server to create the package and also use the Package ACL handling option as merge while building the package.
Additional resources considered for Migration:
- /etc/designs/<design name>/jcr:content - the design mode changes are stored under this node
- i18n folders
- /etc/tags
- Cloud Configurations
- Standard and Custom OSGI configurations - should be manually migrated if run mode specific configurations are not enabled and stored in the code repository
Dispatcher configurations:
The same On-Premises dispatcher configuration can be used with minimal changes like cache folders, if the On-Premise dispatcher is not configured as per the standard the that should be corrected
The authoring freeze in the On-Premise environment should be enabled to complete the migration of content and assets.
The following approaches can be followed if there is any changes during the freeze period
The same On-Premises dispatcher configuration can be used with minimal changes like cache folders, if the On-Premise dispatcher is not configured as per the standard the that should be corrected
- Only the required client headers should be allowed
- Only the publishers IP should be enabled for dispatcher cache flushing
- White-list only the required URL's
The authoring freeze in the On-Premise environment should be enabled to complete the migration of content and assets.
The following approaches can be followed if there is any changes during the freeze period
- Author on both environments
- Perform delta content backfill
Top Domain Supports:
The Top domains should be supported with on-premises systems as the CNAME records cant be created for top domains(e.g example.com), the following approaches can be followed to handle this scenarios
The Top domains should be supported with on-premises systems as the CNAME records cant be created for top domains(e.g example.com), the following approaches can be followed to handle this scenarios
- Redirect the traffic from on-premises network level(load balancer) to AMS platform
- Handle the redirect from Apache server
DNS Configuration:
AMS enables the default DNS(cqms) to access the dispatchers/author but if required client specific domains or site specific test domains that should be created in the on-prem network and C-NAMED to AMS platform and the corresponding dispatcher and publisher configurations to support this domain.
CI/CD configurations:
The CI/CD can be enabled through Jenkins and Code Repository, there are two option
AMS enables the default DNS(cqms) to access the dispatchers/author but if required client specific domains or site specific test domains that should be created in the on-prem network and C-NAMED to AMS platform and the corresponding dispatcher and publisher configurations to support this domain.
CI/CD configurations:
The CI/CD can be enabled through Jenkins and Code Repository, there are two option
- AMS provided code repository and Jenkins
- Client hosted code repository and Jenkins
Some additional items to consider:
SSO/SAML configurations - SSO/SAML configurations for Author instance
Run Book - Run Book should be updated with custom changes and reviewed by AMS team
Performance testing - Performance testing should be performed with agreed SLA and the report should be reviewed by AMS
Penetration testing
- AWS approval is required for penetration testing
- Critical and High issues should be fixed before going live
Cloud/Client Firewall changes - The firewall rule changes are required from both cloud and on-premises to allow two-way traffic.
Testing:
Below are some of the basic items should be considered for Testing the websites
Define the rollback strategy in case the migration did not meet the requirements, the traffic should be redirected to the On-Premises environment by changing the CNAME pointing.
Issues:
Proxy communication - If the external communication is enabled via network proxy in on-premises but the external communication is direct in AMS, if the code is not enabled to optionally support the proxy then code change is required to make the proxy as optional.
Email: If the internal SMTP server is configured in on-premises the same will not work in AMS, the external-facing SMTP server should be configured
HTTPS URL's resulting with 404 - Refer https://www.albinsblog.com/2018/07/https-url-is-resulting-with-404-adobe-experience-manager-aem.html
Package building issue in on-premises server - Refer https://www.albinsblog.com/2018/06/resolving-issues-with-migrating-packages-between-aem-instances.html
The content in this post is my personal view, please check with Adobe before confirming the implementation.
- The deployment to Stage and Prod will be performed by AMS and manual via package
- The deployment package should be versioned - the SNAPSHOT package is not accepted for Stage and Prod.
SSO/SAML configurations - SSO/SAML configurations for Author instance
Run Book - Run Book should be updated with custom changes and reviewed by AMS team
Performance testing - Performance testing should be performed with agreed SLA and the report should be reviewed by AMS
Penetration testing
- AWS approval is required for penetration testing
- Critical and High issues should be fixed before going live
Cloud/Client Firewall changes - The firewall rule changes are required from both cloud and on-premises to allow two-way traffic.
Testing:
Below are some of the basic items should be considered for Testing the websites
- Soft launch web sites through test domains
- Apache Redirect/Vanity URL validation - Validate the apache redirects, better to use some sort of utility to test the redirects and vanity URL's
- Authoring validation - Validate the activation replication,i18n, workflow, creation, and modification of content and assets, make sure the required permissions are available for the authors.
- Validate the site functionality, site search, cache flushing, email functionality, and integration
Define the rollback strategy in case the migration did not meet the requirements, the traffic should be redirected to the On-Premises environment by changing the CNAME pointing.
Issues:
Proxy communication - If the external communication is enabled via network proxy in on-premises but the external communication is direct in AMS, if the code is not enabled to optionally support the proxy then code change is required to make the proxy as optional.
Email: If the internal SMTP server is configured in on-premises the same will not work in AMS, the external-facing SMTP server should be configured
HTTPS URL's resulting with 404 - Refer https://www.albinsblog.com/2018/07/https-url-is-resulting-with-404-adobe-experience-manager-aem.html
Package building issue in on-premises server - Refer https://www.albinsblog.com/2018/06/resolving-issues-with-migrating-packages-between-aem-instances.html
The content in this post is my personal view, please check with Adobe before confirming the implementation.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.