Strategy to Consider when Migrating a Large Amount of Assets into an AEM author Instance

One of my biggest strategies to consider when migrating a large number of assets to production live AEM author instance is to enable/disable the workflow launchers.

Every time when a new asset is installed (via the package manager) or uploaded into AEM, the OOTB (out of the box) AEM workflow launchers will be triggered. During the operation/processing of these assets, the author instance will start consuming the CPU, and the environment may be slowed down, depending on the number of assets being processed at the time.

Since all your assets have already been processed by another AEM author environment, it would not make sense for each asset to again be processed; this will be a waste of usage of the CPU.

I am recommending that if a large amount of AEM DAM assets (that already been processed, zipped in a content package) are being installed via package manager into a production live environment, to inform or disable all authors to stop authoring within a time frame. Within the time frame, disable the workflow launchers and install the assets into the production AEM instance. Finally, re-enable the workflow launchers after all assets have been successfully installed.

8 Critical Factors of CMS Migration

While much of the attention of a CMS implementation is focused on the performance of new software, the vital step of content migration often comes as an afterthought. Critical to the success of an implementation project, a migration needs careful planning and analysis.

Considering these eight success factors will help an organization save time, cost, and resources while increasing the ROI of their CMS implementation.

1. Dedicate the Appropriate Personnel
Assign the appropriate personnel to a data migration project to minimize downtime and avoid large-scale user disruption.
2. Understand CMS Data Migration Complexity
Perform a complete assessment of the complexity of a CMS migration to help set expectations for upper management and ensure their buy-in throughout the process.
3. Assess the Value of Historical Data
Identify data that provides high value and those that have lost their significance. Migrate only the essential data to reduce complexity and streamline the migration process.
4. Understand Target System Requirements
With any CMS, controlling all assets has certain preparation requirements including data cleanliness, completeness, and compatibility. Not addressing these critical data requirements can cause a CMS project to fail, resulting in cost and time overruns.
5. Create a Comprehensive Migration Plan
Meticulous planning for, and deployment of, a comprehensive migration plan will ensure the corporation’s data is properly migrated.
6. Identify and Assess Risks
The key to successful data migration is to anticipate and plan for risks. This will help avoid major delays in the migration schedule that can impact critical business processes.
7. Utilize the Appropriate Migration Tools
Bulk loading migration software enables organizations to maintain system availability and complete data integrity while minimizing the effects on the application and user performance. It provides the most benefit to organizations with heterogeneous storage environments.
8. Obtain Expert Guidance
Highly qualified migration consultants have performed hundreds of data migrations. Organizations should leverage that expertise to navigate the complexities of the migration process and ensure project success on the first attempt.

Which Content Management System is Right for You?

Choosing the right content management system (CMS) can be difficult. There are so many options available that it’s hard to know which one is the best to fit your needs. We could tell you how amazing one is over the other, but ultimately only you know what features and benefits matter most. Is there a magical content management system that will solve all of your problems? No. But there are content management systems that will make your life dramatically easier, and save you time not only in the interim but for the long haul as well.
Here are a few of the more popular CMS’s:

WordPress
WordPress is a really amazing tool for creating a simple blog or managing a small marketing site. My favorite thing about it is the amount of support you can find for it. There are endless resources on the web that can help with either development or everyday authoring. And with tons of plugins available, the creative possibilities are endless.

But of course, there is a downside. One of the biggest issues is security. There have been numerous security exploits within WordPress over the years, resulting in compromised data and inappropriate content being shown. Some of the breaches happen when you are installing a plugin. You have to be very mindful when choosing a plugin because anyone can submit one to the WordPress site.  Sometimes there are security holes with the plugin you’re installing; be sure you look at the reviews before installing anything.

Drupal
One of the biggest advantages of Drupal is its ability to scale. You can use it for a small business site, and then scale it to thousands of pages as you grow. Drupal’s showcase page shows some popular sites using the system, like whitehouse.gov, Timex, Red Hat, and even Bruno Mars (you know it has to scale with how popular he is).

If you don’t know what you’re doing with Drupal, it can be a nightmare, especially from a development perspective. First, Drupal isn’t object-oriented. And second, everything, and I mean everything, is stored in the database: caches, logs, settings, and content. Doing simple theming is pretty straightforward, but if you’re doing anything complex, or want to have considerable interaction with the database – it can be a steep learning curve.

Joomla
Similar to WordPress, Joomla has a ton of support online. There are endless extensions and themes available for anyone to use. One of my favorite things about Joomla, is how developer-friendly it is. Joomla is one of the pioneers in open source CMS’s adopting the MVC design strategy. It allows the views to be separate from the back-end logic. Joomla also makes use of Bootstrap in many of its core templates, making your site responsive out-of-the-box.

However, I do find Joomla’s UI incredibly difficult to navigate. No matter how much I use it, I feel like I never know where anything is. There are a lot of menus with somewhat cryptic labels, and I feel like I’m constantly guessing what pressing a button will do.

Another issue is that Joomla out-of-the-box isn’t SEO friendly. You can install extensions to improve that, but in my opinion, CMS should be SEO friendly out-of-the-box; especially if so many users are installing and implementing their product.

Adobe Experience Manager
For the average author, AEM is by far the most user-friendly. Its drag-and-drop interface makes authoring pages a breeze. The inheritance model it’s based on is also extremely useful and time-saving. You can author a header or a sidebar, and have it inherited across thousands of pages. You can easily turn it on and off for child pages as well. 

Another one of AEM’s great features is its ability to integrate with 3rd party APIs, or other integrations like Salesforce or Eloqua. AEM uses sling, which is inherently RESTful, making integrations much easier.

The biggest gripe with AEM is its steep development learning curve. If you’re not familiar with its underlying technologies (few are) such as OSGi, Sling, and the JCR, it can make development difficult and hard to get up to speed. Documentation and support for AEM are growing, but still hard to find, and can make development even that much more difficult.

Choosing the Right One for You
It’s important to know that these are just four of the more popular CMS’s available today. There are of course others available, each with their own set of pros and cons. Every project is different, and it’s important to understand your business objectives and goals before even looking at which content management system to implement. It’s important to consult your IT team or agency to consider their capabilities, or how you might utilize outside support. Partnering with a company like Blue Acorn iCi is a good first step in the CMS process. If you or your team needs help with an IT strategy or has technology needs, feel free to reach out to us.

The easiest way to copy content from one AEM to another.

Moving Content in AEM is a big task regularly… You may be thinking that moving content isn’t big task. Just package, download & upload.

In my personal opinion, it is big task for everybody. Let me explain in details. Let’s consider a scenario where you want to move content from one AEM environment to another. The easy thing is to do to use AEM Package manager. That is good. And just build a package from one AEM, download it & install somewhere else. Easy process? You may think it is but it is not. From the Business perspective, the Package Manager tool totally sucks & for the following reasons:

Lack of basic features in Package Manager: There are many basic features missing. Some of them are:

• No way you can schedule the content package as a whole. And, if 100 pages to be scheduled then Each individual pages must be scheduled to replicate them.
• No way you could upload the individual pages content from one environment to another if individual pages are the parent pages in the content hierarchy. All the content has to be overridden.
• Not easy to revert the certain content if installed by the package manager. either whole content or nothing can be reverted.

Not easy to use by the Non-Technical Person: Authoring team must have a working knowledge of package manager tool. I know you might think working knowledge? My answer would be YES. Someone needs to know how to upload, build, install, download & uninstall etc. And needs access to the packages when someone can misuse it.

Time-consuming & does not work in most of the cases: Downloading from one environment & uploading in another is very old fashion & time-consuming. For heavy content like size GB’s, It does not even work.

So, here are the list of possible Solutions:

1. TWC Grabbit is one of them. It was developed by one of our team members however not sure if it is working in all the AEM versions. It has so many dependencies & Needs to install & managed in source & destination. But it was a quite good one.
2. AEM Package Manager Out of the box.
3. Copy whole source CRX-QUICKSTART folder & override the destination: Not a feasible option if the content has to be moved to production from stage or from stage to prod. Also not a solution if you want to move the only fewer pages or images. However, Not bad solution for Dev & QA but comes with lots of maintenance once the content is overridden.

The most easiest way move content regularly
You need to have just two things: Have a servlet in source code & Configure destination replication agent. You can see below it.

Pros/Cons of this solution:

1. First, a good thing is that it is pretty easy & you can replication any JCR path. Include a content package, one page/child pages, one image/set of images. if you replicate a content package then no need to install in the destination environment. And, Helpful when you just need some pages in your QA or dev from the stage. Not whole content.
2. No dependency. No installation. Just one servlet, replication agent. And, using out of the box solutions.
3. Pretty extensible. You can build fancy UI out of it & make it a tool out of it.
4. Cross-environment replication & replication only for content movement. Any environment can be a source or destination. Having a separate replication agent just for copying content does not cause any replication queue issue.
5. Cons is it is still using replication API & not any fancy third-party solution.

NOTE: I have tool build around which solves all the issue a content package has. But, not yet sure if I could simply provide source code here. However, let me know if you need some help or idea to understand the full solution.

Hit this URL from a browser after your servlet & agent is done: http://localhost:4502/bin/support/content/publisher?path=etc/packages/abc.zip&destEnvName=QA&publishChildNodes=true.  publishChildNodes is required when you want to publish child nodes also.

Agent Configuration in AEM Author

Replication authoring – Nothing different from other replication agent except Triggers configuration. Do the same as you see in the snapshot.

Replication Request Handler

import com.day.cq.replication.*;

import org.apache.commons.lang3.StringUtils;

import org.apache.felix.scr.annotations.Component;

import org.apache.felix.scr.annotations.Reference;

import org.apache.felix.scr.annotations.sling.SlingServlet;

import org.apache.http.HttpStatus;

import org.apache.sling.api.SlingHttpServletRequest;

import org.apache.sling.api.SlingHttpServletResponse;

import org.apache.sling.api.resource.Resource;

import org.apache.sling.api.servlets.SlingAllMethodsServlet;

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

import javax.jcr.Session;

import java.io.IOException;

import java.util.ArrayList;

import java.util.Iterator;

import java.util.List;

/**

 * Sample URL http://localhost:4502/bin/support/content/publisher?path=etc/packages/abc.zip&destEnvName=QA&publishChildNodes=true

 */

@SlingServlet (paths = "/bin/support/content/publisher",

 methods = "GET", metatype = true, label = "Content publisher to publish content across environments")

public class PackagePublisher extends SlingAllMethodsServlet {

    private static final Logger LOGGER = LoggerFactory.getLogger(PackagePublisher.class);

    @Reference

    private Replicator replicator;

    private List<String> activatedPathsList;

    @Override

    public final void doGet(final SlingHttpServletRequest request, final SlingHttpServletResponse response) throws IOException {

  String requestPath = request.getParameter("path");

  String publishChildNodes = request.getParameter("publishChildNodes");

  final String destEnvName = request.getParameter("destEnvName");

  if (StringUtils.isNotBlank(requestPath) && StringUtils.isNotBlank(destEnvName)) {

      activatedPathsList = new ArrayList<String>();

     Session userSession = request.getResourceResolver().adaptTo(Session.class);

  ReplicationOptions replicationOptions = new ReplicationOptions();

 AgentFilter agentFilter = new AgentFilter() {

    public boolean isIncluded(Agent agent) {

 if(agent.getId().toLowerCase().contains(destEnvName.toLowerCase())) {                   return true;

                    }

                    return false;

                }

            };

            replicationOptions.setFilter(agentFilter);

            LOGGER.info("replication starting ");

            try {

                replicator.replicate(userSession, ReplicationActionType.ACTIVATE, requestPath, replicationOptions);

                Resource childResource = request.getResourceResolver().getResource(requestPath);

                if ("true".equalsIgnoreCase(publishChildNodes)) {

                       publishChildPages(childResource, userSession, replicationOptions);

                }

                for (String path: activatedPathsList){

                    LOGGER.info("Activate paths" + path );

                }

                response.setStatus(HttpStatus.SC_OK);

                response.getWriter().print("given path is replicated to given environment. Check in destination env.");

            } catch (ReplicationException e) {

                response.setStatus(HttpStatus.SC_BAD_REQUEST);

                response.getWriter().print("Check Parameters. Also check author replication agents for " + destEnvName);

                e.printStackTrace();

            }catch (Exception ex){

                response.setStatus(HttpStatus.SC_BAD_REQUEST);

                response.getWriter().print("Something was wrong!!");

            }

        } else{

            response.setStatus(HttpStatus.SC_BAD_REQUEST);

            response.getWriter().print("Parameters are not passed.");

        }

    }

    private void publishChildPages(Resource childResource, Session userSession,

                                   ReplicationOptions replicationOptions) throws ReplicationException {

             if (childResource != null) {

                Iterator<Resource> itr = childResource.listChildren();

                while (itr.hasNext()) {

                    Resource temp = itr.next();

                    if (!temp.getPath().contains("rep:policy") && !temp.getPath().contains("jcr:content")) {

                        if (temp.hasChildren()) {

                            publishChildPages(temp, userSession, replicationOptions);

                        }

                        activatedPathsList.add(temp.getPath());

                        replicator.replicate(userSession, ReplicationActionType.ACTIVATE, temp.getPath(), replicationOptions);

                    }

                 }

            }

    }

}

Final Thought
I found it very easy in day to day work when you want to move the content here & there. However, if there is any confusion & question. leave a comment. will respond asap. thanks.

Migration of 6k AEM pages in batches with zero downtime

old to new simple structure from left to right

Changing designs of thousands of topics on telegraph.co.uk whilst maintaining 100% uptime

What is this blog about
At Telegraph Engineering we recently worked on creating a new topic page design and migrated 6k+ pages from its existing layout to a new fast, simple and engaging layout. This blog demonstrates what and how we did this from the perspective of the data content repository (JCR).

Note: This blog requires some basic understanding of Adobe Experience Manager architecture and data structure

Glossary
JCR — Content Repository for the Java Technology API.
AEM — Adobe Experience Manager; the underlying CMS for content management.

What are Topic Pages?
Topic pages are subject-specific landing pages that filter news articles based on their relevant topics. This screenshot shows the old and new topic page designs.

Before:

The old-look topic pages

After Migration:

After migration

Business Value — Why did we do it?
We decided to change the layout of some page types in AEM to help increase our readers’ engagement, drive registrations and support our vision.

How — Our Phased Approach

Phase 1: Component re-write:
We started by rewriting existing components. For example, the old list component was difficult to monitor and maintain, was impossible to call from services that were external to AEM, and the layout was very old. So we started by rewriting a list component that supported a new layout and monitoring, and had the facility to be used as a service (ie. external services can call the list service with a configurable parameter and maintenance is much easier).

This required us to modify the architecture, however, I am focusing only on the migration part in this blog. If you have any questions please add them into the comments section.

Phase 2: Create content packages in Pre-Prod
After the component rewrite, we removed the old page from the staging (pre-production) environment. We manually created the new pages using the newly-built layout. We then created and downloaded the content packages in AEM.

Phase 3: Content Migration in Live
Firstly we backed up existing pages (as packages). Then we installed the content package for the new topic pages — which we’d created on staging in phase 2 — on to production and activated these pages. This flushed the dispatcher cache and the page was ready with its new layout on production.

Easy, right? Not quite… The manual process worked for one topic page. We have more than 6,000! And they all require migration.

Phase 4: Automating the process
To migrate 6,000 pages we had to develop and adopt an automated solution. So we decided to migrate them in batches to reduce overhead and to make rollback easier if required.

Here are the steps that we followed:

1. Write and then run a Groovy script to find and build a list of pages that require migration (based on business logic).
2. Run a bash script to generate a content package of 500 pages (from different locations in AEM) on prod. The script also downloads the package to a local directory.
3. Manually upload the package to the staging environment so that you are in line with production.
4. Run a java program to migrate those pages from the old jcr structure to the new jcr structure.
5. Run the bash script again on the staging environment to create the content package and download it to local directory. This time the package has got migrated pages.
6. Install the content package on the prod author and publishers.
7. To clear up the dispatcher cache, we have a python script that rebuilds those pages on the dispatcher. Reactivating 500 pages from different locations in AEM is not easy and we can’t clear the whole dispatcher cache, so the only option is using a script that can automate this process and rebuild pages on the dispatcher, even before the first request reaches the dispatcher.
8. Follow step 1 to 7 until you have all 6k pages migrated.
9. Finally, celebrate your success!!

The whole process worked with zero downtime and it was so seamlessly happened that it was unnoticed by editors and/or subscribers.

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

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

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

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

Rollback Strategy:
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.

Drupal to AEM CMS Migration Approach

Milestones For DRUPAL to AEM Migration Approach:
The following steps illustrate the sequence of events in content migration.

• Finalization of functional specifications design
• Finalize the current and future document state
• Install and Configure the setup of AEM author and Publisher environment
• Finalization of a new design based on the existing and Future website structure
• Finalization of mapping structure between existing website and New website
• Validation of Migration functionality in a Test environment and then move it to production environments
• Add the new content entry to the newly designed website
• Pre-migration of Final content –finalist the content freeze
• Post Content migration, Validation in Production environments
• Delta Migration from existing website to new website based on the new structure
• Finalize the Go Live date

Existing Drupal system to AEM system mapping

Fig.1 Drupal system to AEM system Mapping

Pre-Migration Activities: AS-IS Site Migration to - To-Be Site Migration
The below diagram describes the Pre-migration steps.

• Existing site Audit Analysis
• Page to Template mapping
• Components to Page mapping
• Web Function migration
• Content Migration Hidden challenges
• Finalizing final wireframe
• Finalizing Base templates based on page structure
• SEO-Impact Analysis
• Complete Sitemap Analysis
• Migration Data Identified

Fig: 2 Pre-migration steps

Template mapping

• Template design for Obsolete pages will be a reference to AS-IS website pages
• Template designed for To-Be based on To-Be page structure
• Association of To-Be template

Fig: 3 Template mapping from AS-IS website to To-Be website

Page and Template mapping from AS-IS website to –To-Be website pages

• Page Design components identification with reference to AS-IS Page structure
• Create new pages based on finalized To-Be base templates
• Association of AS-IS page to- To-Be page Template

Fig: 4 Page and Template mapping from AS-IS website to –To-Be website 

Components and Page Mapping

• AS-IS website component list will be mapped to the To-Be site components list
• Validating AS-IS component mapping with the AEM OOTB component list
• Use of OOTB/Custom component while migrating the static content and dynamic components functionality from AS-IS website to the To-Be site website
• Create pages based on the mapped To-Be template and use custom and OOTB AEM components.

Fig: 5 Components to Page Mapping form AS-IS website to To-Be website

AEM tree taxonomy:

• Based on the existing taxonomy , Create taxonomy in the AEM CMS
• Finalize the Taxonomy structure

Sitemap
§ Derive the sitemap based on sitemap from existing site audit analysis and new pages need to be added.
§ For To-Be site map will be created based on the existing site audit map and To-Be sitemap

Cleaning Your Data
Data Cleaning includes the following tasks

• Inline Markup
• Embedded Links
• Embedded Server side code

Avoid SEO Impact during website migration

1. Key points need to be considered during website migration
2. Industry best Practice SEO Guidelines will be followed for the website migration-Meta data, keywords and tag migration from AS-IS website to To-Be site

• During migration Minimize the traffic loss
• During migration Minimize the ranking drops
• During migration avoid Key rankings maintenance
• During migration avoid Head traffic maintenance
• During migration avoid Covering additional keywords
• During migration avoid Eliminating non-performers
• During migration avoid Loss of Indexed pages
• During migration avoid 404 errors
• During migration avoid Old site still showing in Google
• During migration avoid Loss of page rank

Digital asset missing

• During pre-migration Identify the asset to be migrated
• During pre-migration Create asset taxonomy structure in AEM and upload images to AEM

Web Function

• During migration Identify the web function if any
• Prepare a plan for the static and dynamic component migration

Migration Cutover-Activities

• List of Migration Activities

Fig: 6 Migration cutover activities

Migration Cutover Process:

• Migration from UAT to Prod environment
• After a content freeze in the existing system, for creating any new pages To-Be template will be used to create content in AS-IS website
• During delta, migration author is Drupal system should make note of content and to be the template used for creating content in existing website
• Delta migration to SIT and Delta migration from SIT to UAT, UAT to Prod environments.

Fig: 7 Migration Cutover process

Database Table Mapping from existing to AEM database.

• Existing MySQL and MS SQL database table mapping will be done with AEM JCR repository
• Drupal content migration from MySQL to AEM JCR repository

SEO-tags

• During migration from Drupal to AEM all the SEO tags mill be migrated
• While SEO tag migration association of tags with content, dam assets will be taken care in AEM Tagging system

Existing Tag structure and entire tag list

• Existing Tag structure will be taken care of so that it will not impact SEO.
• If required reorganization of Tag structure will be taken care during migration

SEO Friendly URL Redirects

• URL mapping to achieve search-engine-friendly URLs can be accomplished using the Apache Felix Web Management Console. apache sling resource resolver

Video’s
§ Uploading images from the local file system to the AEM system through DAM console

Converting HTML embedded content to Plain text

• Most of the content in Drupal CMS is HTML embedded content, during migration these HTML embedded contents are converted to Plain text.
• AEM doesn’t support the embedding of HTML content inside the component, from the AS-IS website all the HTML embedded content will be converted to the AEM component.

Static content and dynamic content

• Now migrating the content from Drupal to AEM, Mapping the content and content type to the AEM OOTB components.

Component from Drupal	Drupal CMS	Adobe AEM component
Only Static Content	Extract	Text component
Static content with image	Extract	Text Image Component
Video, Images, and Document	Extract	Has to be stored in the DAM
URL	Extract	Part of Sling resource resolver
		Sling Resource resolver component allows adding/remove the absolute or relative path of any URL
Taxonomy	Extract page path	Create a taxonomy level page

Adobe AEM Static Content-Text OOTB Component

• For any static content, the Text component will be used for the content migration from Drupal to Adobe AEM CMS.

RSS feeds

• Existing RSS feeds data will be migrated from Drupal CMS to AEM JCR repository
• AS-IS functionality will be migrated of RSS will be migrated from source to destination system

Web forms data

• All the web forms data from source to destination will be migrated

Migration Process

• Page-level migration through Manual process
• I. Obsolete pages will follow the manual migration
• Set of pages migration through Automated process

Extract Content from Source CMS

• Extracting content from Drupal CMS
• Testing and verifying the accuracy of the extraction and making appropriate changes to the script or program if needed.

Import Content to Target CMS

• Create scripts/programs to perform migration based on mapping specs
• Run migration script to import data to the new CMS
• Test and verify the accuracy of the import and make appropriate changes to the script/program if needed

User Access Control

• Export the existing User Details and creating User details and assigning the CRUD privileges to the imported users in AEM
• Creating users and Group details in AEM.

Create a Test Plan and Test Scripts Design Approach

Migration Activities	SIT	UAT Environment	Prod
	Environment		Environment
Static Content validation	YES	YES	YES
Dynamic content Validation	YES	YES	YES
End to End  Site Navigation validation	YES	YES	YES
Branding validation	YES	YES	YES
Copyright Validation	YES	YES	YES
Validation of images, video, URL	YES	YES	YES
Validation of Meta-data, keyword, SEO tags	YES	YES	YES
User access control validation	YES	YES	YES
The database schema, Table and total records validation	YES	YES	YES
Content Version and Latest content validation	YES	YES	YES
Sitemap validation	YES	YES	YES

Note: Yesà Validation is completed.
Table: 1 Test Plan and Script execution sequence.

• Post content migration few content mapping needs to verify and validated
• Migration verification and validation report shows the status of content migrated from source to destination
• If content creation is getting failed to migrate in any of the instances, that failure needs to be highlighted in the report

Perform Migration from SIT to UAT and Prod

Activities List	SIT Environment	UAT Environment	Production environment
§  Content and Digital assets Migration and Validation	Author Instances	Validate the content migration	Author Instances	Validate the content migration	Author Instances	Validate the content migration
§  Delta Migration and Validation
Publish instances	Publish the validated content from the author to publish	Publish instances	Publish the validated content from the author to publish	Publish instances	Publish the validated content from the author to publish

Table: 2 Migration from SIT to UAT and UAT to PROD

Clean up Content Versions in Production approach

• Make sure only the latest content is migrated staging instance to the production instance
• If the content is versioned prior to production migration those content details need to note

Content Migration Methods or Approaches
Automated Approach for Migration

Task ID	Task Name	Description	Remarks
1	Content-Type based metadata	Define a list of metadata for each content type
2	Finalized XML Structure	XML  Structure needs to be finalized with Client SME's
3	Design and Develop Migration Script	Design and Develop Migration script based on finalized XML structure from Task# 2
4	Content Populated XMLs for the website to be migrated	Client to provide populated XMLs for all target websites which are used for migration
6	Dry Run of Migration Script in Test Environment	A dry run of migration script for a single product

Table: 3 Approach for Automated migration

Manual Migration Approach

• Identify the Static content
• Identify the dynamic content
• Identify the regular dynamic content
• Identify the Static component
• Identify the Dynamic component
• This approach will be “cut and paste.

Initial Content in Production approach

• Post the entire content migration to production instances, migration has to be tested
• And content changes need to freeze in the OLD CMS
• Avoid content changes in the OLD CMS by removing access rights for the content author
• No need of content freeze in the new CMS in the production environment while the delta content is being imported as shown below approach
• o Post content freeze- To-Be template will be used for any content updates in the AS-IS website – that newly added information needs to be captured in the separate spreadsheet- helps to migrate into the To-Be website.

o During Delta content migration- initially, migration will happen to production author instance hence there is no need for a content freeze in production – however delta migration will not impact the live website-i.e. publish instances.

Fig: 8 Content freeze in Production

Validate the Production Migration

• Have validation and verification of steps followed during test migration
• Production migration ensures that all verification and validation approach works in the production environment.

Delta Migration & Validation approach

• To-Be Template will be used for creating content in the Drupal CMS after the content freeze in the Production.
• A final export from the old CMS will pick up all content that has been created or modified since the main migration and import it to the new CMS in production.
• Once the final content migration is done, finally verify and validate the content which is migrated in the production instances.

Fig: 9 Delta content migration and validation

Perform Migration Validation and Verification in the Test Environment Approach

• Validate and verify the content has been migrated to the destination location i.e. AEM
• During migration different type error can show up during this process:
• The error can be Content Issues – Content can be missing, placed in the wrong location, or have incorrect attributes.
• The error can be Mapping Specifications – The mapping specification may be incorrect or incomplete.
• The error can be CMS Configuration – The migration may fail because the new CMS has not been configured correctly.

Fig10: Migration Validation Steps.

Post Website Migration Checklist

• Make sure website pages render properly
• Make sure spelling and grammar on landing and Home page and detail pages
• Use build-in External link checker to verify all external links are working fine
• Make sure all URL redirection works fine
• Make sure all forms are in Reset mode
• Make sure robots.txt file is used for to avoid instance searching for the google engine
• Make sure all Social media buttons are working and URL redirection happens to correct website page
• Make sure 404 and 500, 502,503 custom error page are build
• Make sure website backup is happening on an hourly basis of content and digital assets (incremental backup)
• Make sure once in a 1-month full repository backup is taken
• Make sure internal system monitoring is happening for the Disk, CPU, Memory, I/O, network, Bandwidth
• Make sure there is no temporary URL redirect exist in your website

Fig11: Post website Migration checklist.