'Created for' vs. 'Compatible with' Adobe Experience Manager
When discussing a migration to Adobe Experience Manager (AEM) Cloud Service with our clients, one of the fundamental questions underlying our approach is whether they will be best served by a migration that is "compatible with" AEM Cloud Service, or if the business and long-term platform goals are more effectively achieved by being "built for" AEM Cloud Service.
In a rush to get onto the latest and greatest version of AEM in the quickest and cheapest way, many clients and AEM partners overlook this question, simply driving forward on a path that seems most obvious, updating the codebase to remediate anything that’s no longer supported on AEM Cloud Service and making the jump.
However, what happens when you take a CQ 4.x, CQ 5.x, or AEM 6.x codebase and update it to run on AEM Cloud Service? Well, you get exactly that—a legacy codebase that runs on AEM Cloud Service. But is running on AEM Cloud Service your real goal? For companies simply looking to offload the infrastructure responsibilities of AEM and capture some of the benefits of Cloud Service deployments and auto-scaling, the answer might be yes. But for others that see this upgrade as a strategic move to a modern AEM, this migration path could leave stakeholders wanting. In that context, here are some risks we help clients navigate in determining the best migration path to achieve their goals.
Risk One: Missing Features
A major motivation for running on AEM Cloud Service is to be able to use all the modern features of AEM. Unfortunately, not all upgrade paths achieve this goal.
As an example, one area often skipped past in a straight-path upgrade to AEM Cloud Service is static page templates. Dynamic page templates allow authors to modify page templates without the need for a developer. But for many stakeholders, developers managing page templates doesn’t represent a significant pain point to their business, and thus upgrading templates from static to dynamic can be seen as an unnecessary expense. Forgoing dynamic templates, however, means that modern authoring features of AEM such as Layout mode (the ability for authors to create bespoke, responsive content without developers) and Style System (the ability for authors to toggle through different stylistic versions of a component and immediately see the result) remain locked away.
Be sure your migration path is actually unlocking the features you’ve been waiting for.
Risk Two: Suboptimal Site Performance and SEO
Moving to AEM Cloud Service, one would assume this would result in a step forward for site performance and SEO. Those goals can certainly be achieved, but they are definitely not automatic.
One relevant feature easy to overlook in moving to a modern AEM implementation is automatic image renditions that come out of the box with Adobe WCM Core components and Bounteous Activate for Experience Foundation. Strictly speaking, there’s no need to upgrade off of the legacy image component when moving to AEM Cloud Service, so this is often avoided in an effort to cut costs. However, websites that avoid making the change will continue to suffer SEO penalties for inefficient image renditions being served out of the DAM that don’t match the size needed by the page layout and current device viewing.
If your site could stand some improvement in the areas of performance, accessibility, and/or SEO, be sure those issues are being addressed specifically in your migration as running on AEM Cloud Service won’t improve these areas automatically.
Risk Three: Siloed and/or Duplicated Content
Centralized content and experiences in the form of Content Fragments and Experience Fragments didn’t exist in their current form when most legacy systems were built. Abstracting reusable content into these newer content structures is an extra effort, and thus often avoided. But for some content that can be reused across websites or in headless applications such as a mobile app, email campaigns, or Facebook posts, dimes spent now could save dollars spent later. Now might be the time to get your information architecture and content strategy in order.
Risk Four: Ongoing Maintenance Costs
Let’s be honest, some platforms being upgraded to AEM Cloud Service are just simply getting long in the tooth. Many AEM platforms were built originally on CQ 4.x and 5.x and have been through nearly a decade of multiple development teams adding, changing, and refactoring code according to tight timelines and ever-evolving business requirements.
Unless a consistent team of expert AEM talent has been engaged on the platform from the time it was created, it stands to reason that significant technical debt has accrued. Technical debt manifests itself in the form of extra time and money spent on every change and addition to the platform, and simply upgrading to AEM Cloud Service won’t solve that problem. A migration can often be an opportunity to rewrite key parts of a platform to be purpose-built for AEM Cloud Service for a reasonable incremental cost that results in significant run cost savings and higher return on investment.
Risk Five: Lingering Legacy Patterns
Last but not least, what works on AEM Cloud Service today in terms of legacy patterns may have limited shelf life and support. WCM Use objects (precursor to Sling Models), static templates, legacy 'image' and 'page' components, SCR annotations, and other deprecated constructs run on AEM Cloud Service for now, but each of them has been superseded by new approaches for many years at this point. Similar to Classic UI, the day may come where upgrading these constructs is no longer optional, and continuing those patterns now only compounds the costs for later.
Determining Your AEM Cloud Service Migration Path
There are deep implications to your approach for upgrading to AEM Cloud Service, and the most obvious path is often not the best. The approach you take can and should be customized to your specific situation. A quality partner specialized in AEM Cloud Service migrations will assess your platform and help you determine the path of migration that provides the optimal balance of value, timeline, cost, and risk to fit your business and derive value from AEM both now and in the future.
