Don’t Let Content Migration Trip Up Your Move to AEM

Don’t Let Content Migration Trip Up Your Move to AEM

When moving your enterprise customer experience to a modern digital experience platform (DXP) like Adobe Experience Cloud, it is highly likely you will need to migrate one or more websites from a legacy web application or content management system (CMS) to Adobe Experience Manager (AEM) Sites and Assets.

One of the often overlooked and underestimated efforts as part of the migration to Adobe Experience Manager Sites and Assets is the actual content migration.

When overlooked, content migration can cause a lot of unexpected, costly headaches for the enterprise. With a little forethought, these pains can be avoided, easing the move of Adobe Experience Manager.

Here are a few recommendations to help you avoid some of the missteps I’ve seen around content migration.

Acknowledge that Content Migration is a Critical Factor to Overall Success

In my experience, stakeholders in marketing and IT are often excited about getting on the new Adobe platform. The promise and potential of Adobe Experience Manager often has marketers salivating for the control they will have over the customer experience, while IT can’t wait to get their hands on the backend capabilities to integrate and scale across the enterprise.

As a result, the rather mundane tasks of content migration can be overlooked or ignored, setting project teams up for some unexpected unpleasantness in the middle of the project.

Once teams realize the misstep, they will be compelled to hastily create a migration plan. At that point, they are compounding the problem. After launching on AEM with a half-baked content migration strategy, marketers will face limitations in their ability to put content in front of users at the right time on the user journey, and IT will find that pushing content out to other apps and endpoints will be more difficult.

To avoid this misstep, acknowledge upfront that failing to plan well for the content migration has the potential to push launch dates, balloon budgets, and limit future potential.

Analyze a Content Extract As Soon As Possible

When approaching content migration, analyze the content from the legacy web app or CMS as soon as possible to spot any potential problems that might be encountered during the migration. Request an XML extract from the current CMS before the project even starts. Don’t wait until midway through the project to ask IT for an extract.

After years and years of content creation in the legacy system, there will be broken links, missing content, and inconsistent data structures that need to be remediated. Often hardcoded HTML and tables may hide within the content, posing real issues for page rendering and responsiveness once moved to the target system, AEM.

By finding out early whether or not content is a mess, a project team can ready stakeholders and sponsors for the manual effort that may be required to scrub and move portions that can be moved automatically.

Decide If and When You Want to Update Your Content

Once content is migrated to AEM and displayed in a beautiful new front-end design, there is a potential that business users will be supremely disappointed in the quality of the content. They may be looking at the same old content they have had on the web for years, but now it is suddenly unacceptable to launch on the new platform in the new design.

Encountering this issue late in a project will likely cause a project delay as the teams scramble to find and make available product managers and marketers to rewrite product and marketing content.

As an alternative, determine upfront if and how content updates will be required. If the content is good to go, this will not be an obstacle. If it needs to be updated, however, create the plan for updating content.

We most often recommend making content updates in the target system, AEM, versus making updates through an existing process or CMS. It makes sense to do this because the AEM authoring tools will undoubtedly be more powerful than whatever a business has available in a legacy system, and authoring in AEM ahead of launch provides business users and authors the opportunity to learn on the new platform before go-live.

In wrapping up, do not underestimate or overlook the content migration. It can be easy to get a project into trouble by overlooking content migration, though it can be just as easy to avoid those mistakes. I’m confident that by considering the three main thoughts shared in this article, you will avoid the common pitfalls of content migration and have a smooth migration to AEM.

If you’re in the process of optimizing or implementing your AEM solution, we can help. Reach out to Blue Acorn iCi today.