We talk a lot about Built to Run around here at Perficient. We put an enormous focus on making sure we build our AEM implementations so that marketing departments can run most efficiently. You obviously can’t do that without content. Creating content from scratch is an option, but starting from scratch for really large enterprises, who have spent years cultivating their content, is rare. So in most cases, content has to come over from the legacy system to help populate the site with valuable content.
Have you ever considered what’s really involved during a content migration? Me neither! I never really cared until I was forced into it during one of our system migrations where we were resource constrained and needed to act fast. We pushed our way through it and were successful. I was also pleasantly surprised at the series of tasks, activities, and deliverables executed during the migration track that we were able to later formally define, and re-implement in upcoming projects; thus, our migration process lifecycle was born and we’ve been refining it ever since.
Ultimately, it’s evolved into an overall blueprint that provides a strategy for content migration projects within the enterprise throughout a specified period of time. It is strategically purposed to provide recommendations on when to migrate content and how to best leverage the experiences during the content migrations in order to influence future migrations in a positive way. It’ s a program approach that offers a model for migrating existing content into the newly defined platform structures.
The model includes a program component as well as a technology component. The Program focuses more on process and governance from a tactical perspective. Technology focuses more on the recommended technical approach based on the type and functionality of the content that is being migrated. To be clear, the overriding philosophy of the blueprint is to focus most on people, process, and vision. With good people and a reasonable process, the vision will eventually manifest.
First, define the program…
The Migration Program is responsible for managing the multiple, related projects as it relates to the underlying migration of all identified content into the platform. It exists only for the duration of its individual migration projects, and it is focused on managing the risk and complexity between them to deliver the entire system.
In short, the Migration Program is responsible for:
- Driving the completion of content migration projects within the program
- Identifying and managing interdependencies between the migration projects
- Providing process consistency and predictability, and acting as the focal point to ensure that best practices are applied and re-used
- Validating and verifying accurate project progress, status, and migration audit
- Accountability to Program Sponsor and/or Steering Committee
Second, follow a process…
Remember, the entire process has to be repeatable and allow for the release of content through the target environment in controlled stages. Let’s first look at some guiding principles:
- Inventory, analyze and validate the source content identified for migration.
- Extract the web content, metadata and resource files from the source systems.
- Programmatically correct malformed content where feasible.
- Map the source web pages to pre-defined templates in the target system.
- Classify the source data into the pre-defined functional taxonomy of the target system.
- Modify the hyperlinks and other web references as appropriate in the migrated content to ensure proper operation of the web pages.
- Automatically provide intelligent link management to ensure seamless operation of the target and source systems until all content is migrated and the source systems can be turned off (EOL).
- Populate an audit dashboard that provides an up-to-the-minute status of current migration status.
Now, our process is five steps, but honestly, you can and should adapt to fit the exact nature of your needs. Every migration is complex in its own way; you should adapt as you go, following the above principles. In one of our more trimmed down versions, we had defined the process as:
Most are very self-explanatory, but the one I get asked about the most is Migration Processing, so I have broken up the steps that go into physically moving the content:
- Content Indexing – get content for migration (based on MIL)
- Data Extraction – applies rules for metadata assignment based on the structure of the content, or the content itself
- Attribute Assignment / Propagation – propagates assigned metadata down to the children for consistency
- Chunk Extraction – Extracts chunks of content from the pages and creates new objects that are associated to the legacy parent
- Template Mapping – Maps content to a defined template in the target CMS
- Export / Import – Export and import into the target CMS
- Audit – Dashboard of current migration status
To recap, the migration program combines the process lifecycle with the roadmap of events that take place during a typical migration, with the purpose of providing the program with a complete overview of its tasks, activities, and delivery artifacts necessary to successfully complete. Hopefully, content migration endeavors will be easier to break down and more importantly, I hope this helps you put the final touches on your build…and as you know, we’re all about Built to Run.
