Adobe Experience Manager(AEM) On-Premises to Adobe Managed Service(AMS) Cloud Migration

Adobe Experience Manager(AEM) On-Premises to Adobe Managed Service(AMS) Cloud Migration

This post explains the different things that should be considered while migrating On-Premises Adobe Experience Manager(AEM) platform to the AWS cloud managed through AMS.

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

We have to consider this option based on the how much control we require on the production environment - AMS environments will be restricted for client access.

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 near by 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 in 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

Package based migration should be used if the content/asset size is less and there is no requirement to migrate the version histories.
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 to the authors.

The content/asset from 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 from(selecting the appropriate options)from 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 CURL command to install the packages that will provide better tracking option 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 build 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 setup in AMS platform, the below approaches can be used

• Manually setup users/groups in 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 code repository

These resources will be part if the CRX2Oak migration is used instead of package based migration to migrate the complete 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

• 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

Authoring Freeze:

The authoring freeze in 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 back fill

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

• 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 on-perm network and C-NAMED to AMS platform and the corresponding dispatcher and publisher configurations to support this domains.

CI/CD configurations:

The CI/CD can be enabled through Jenkins and and Code Repository, there are two option

• AMS provided code repository and Jenkins
• Client hosted code repository and Jenkins

Some additional items to consider:

• 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.

Additional Considerations:

SSO/SAML configurations - SSO/SAML configurations for Author instance

Run Book - Run Book should 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

        - The Critical and High issues should be fixed before go live

Cloud/Client Firewall changes - The firewall rule changes are required from both cloud and on-premises to allow two way traffic.

Testing:

The below are some of the basic items should be considered for Testing the websites

• Soft launch the 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

Rollback Strategy:

Define the roll back strategy in case the migration not met the requirements, the traffic should be redirected to 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.