Abstract
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.
Read Full Blog
Q&A
Please use this thread to ask the related questions.
Kautuk Sahni