A Step-by-Step Approach for Migrating to AEMaaCS

AEMaaCS is Adobe’s software-as-a-service (SaaS) version of Adobe Experience Manager (AEM) that scales to your needs. It provides clients with a cloud-based CMS platform (Sites), Digital Asset Management (DAM, or simply Assets), and Forms. Released only a few years ago with several upsides and little downsides, Adobe has continued to build the platform with new features and releases—improving functionality for its users according to their unique needs.

Many organizations (small and large) have been enticed with licensing discounts and package deals to embrace Cloud Service (CS) and migrate their AEM instances to it. One North has experience helping our clients with this journey to get their websites live on CS. In this post, we will describe the key steps involved in such a migration.

Step 1: Assess the Current State

The migration from on-premise (data center) or cloud-hosted to Cloud Service (CS) is not a lift-and-shift. It is a great opportunity to modernize and clear off technical debt, but significant refactoring is required to make your AEM implementation ready for CS.

Adobe provides several tools like the Best Practice Analyzer (BPA) and Cloud Acceleration Manager (CAM) to help with the analysis of your AEM code base and recommend the best path and list of to-dos for migration to CS.

Step 2: Prioritize Sites and Components

When prioritizing your sites and components for migration, there are two key strategies to choose from:

• One is to migrate your simplest site first in order to become familiar with the CS lifecycle, which is not trivial.
• The other is to migrate your most complex site first in order to solve the high-risk elements of your overall ecosystem before you commit to a migration.

The right choice for you might depend on a number of factors, including the complexity of your code base, the strengths of your team, and/or your organization’s appetite for risk. Following your choice of strategy, develop a high-level timeline for the migration of all the chosen sites.

Step 3: Remediate and Enhance

Certain changes are required for a migration to CS. For example, if you’re still using Classic UI component dialogs, static templates, or Java Server Pages (JSPs), you will need to modernize your implementation by converting to dynamic templates, refactoring workflows, and replacing JSPs with Sightly, known as HTML Template Language (HTL).

When you’re knee-deep in the code base, it is a great opportunity to future-proof your AEM implementation. Making changes, such as moving to the latest archetype, will better position your organization to move to a Single Page Application (SPA)-based architecture down the road.  During this step, the latest AEM archetypes introduce the ui.frontend module that is explicitly designed to house your frontend code. This offers benefits like leveraging AEM’s Webpack build tool and facilitating swift deployment of frontend changes—eliminating the need to deploy the backend as well.

Step 4: Automate

CS uses Cloud Manager (CM) to automate and validate deployments (similar to Jenkins and other build tools). CM ensures no incompatible code is deployed and the code has adequate test coverage to protect you from regressions.

Setting up your local development environments to efficiently work with CS and CM ensures rapid deployments and quick time to market for new functionalities that your organization relies on to grow and flourish.

Step 5: Deploy and Test

Once the code changes are done and the infrastructure is ready, it’s time to start planning the migration of your content, taxonomy, metadata, and more.

Don’t forget to test the authoring experience, which could be dramatically different if you’re coming from the Classic UI experience. The real test happens once you start showing your stakeholders a few finished pages in a higher environment like quality assurance (QA), stage/staging, or user acceptance testing (UAT).

Ideally, you should develop some regression test cases (manual or automated), both for authors and end-users, to make sure that you’re on par with the user experience (UX) offered by the legacy AEM site that you’re upgrading from.

Step 6: Finalize

Once you benchmark the website’s performance, it’s time to fine tune and finalize your environment sizing and caching strategy to achieve the best performance for your buck. You should be looking at performance for both authoring use cases as well as end-user use cases. Things work a little differently in CS, so you should likely see an automatic improvement in authoring performance.

If your AEM sites are integrating with other solutions such as analytics, optimization, CRM, etc., then this is the time to make sure all of them are functioning as needed before you cut over from your legacy website to the new CS-based website.

Partnering with One North as an experienced agency in CS implementations not only gives you the additional resources needed for such an initiative but also mitigates any risk of errors during your migration to CS. Click the button below to learn more about One North’s Adobe capabilities and expertise.

Photo Credit: Collin Watts | Unsplash