Acquisitions, mergers, growth, industry competition, lack of product support, and outdated solutions might be a few of the reasons why organizations undertake a migration exercise. Whatever the reason to initiate a migration, migration isn’t just a copy and paste or lift and shift activity but rather a more engaging operation that requires commitment and championship from top management to achieve any level of success.
This article, which is the first of two episodes, will focus on Web Content management systems (WCMS) migration and explore its considerations, challenges, and approaches (detailing manual migration in this episode).The second episode will tackle factory/automated and semi-automated migration approaches.
Migration projects are often nightmares to organizations as there are many factors to consider amidst regular business operation.
WCMS Migration – Considerations and Approaches
A typical web content management migration may take the approach in the image above, going through several phases; detail analysis of both systems, templates development (for destination WCMS) or factory development (automated migration), migration execution, test, review, validation, and go-live. Ideally, sites are grouped into batches based on a set of criteria.
WCMS migration is the set of processes (activities and tasks) that enable the transfer of organizational public facing website content (text and media assets) and in most cases functionalities/features from a source WCMS tool/product to a destination WCMS tool/product. The proper execution of the processes and activities from start to finish will determine the faith of the migration exercise. Leadering WCMS vendors/products according to Gartner(2016) are Sitecore, Adobe Experience Manager (AEM), Acquia (Drupal), Episerver, IBM (Web Content Manager), and Oracle Webcenter (aka. Universal content Management).
Although the focus of this article is on migration, it’s important to highlight some aspects that should occur prior to any form of content migration. Prerequisite for a migration includes but are not limited to the following:
- Have identified the need and the eventual value added opportunities and ensure they align with an organization’s business strategy
- Have reached a decision on the destination WCMS product and the deployment architectural option.
- Have put in place a change management, communication management, and information governance
- Have finalized Websites analysis and inventory (Analysis of existing websites to determine content volume, complexity, functionalities, and features)
- Have collected a list of functionalities (prioritized on business relevance) including others from websites analysis exercise
- Have established an information architecture (metadata, taxonomy, security, and retention)
- Have established a content strategy to repurpose/retire outdated content
WCMS migration is analogous to repairing a car on a running engine. Migration requires the transfer of content (and the associated functionalities, features, and front-end design) from one system to another “without” a disruption of regular business operations. Achieving “no business disruption” it’s a challenge that requires careful consideration and execution of the following phases: pre-migration (prerequisite), migration, post migration. Assuming the prerequisite activities (phase) as listed above have been completed, organizations may select one of the following migration options:
- Manual migration from source to destination
- Automated migration from source to destination
- Semi-automated media assets migration
A decision on any of the above options can make or break the entire initiative, thus organizations need careful considerations and should evaluate their choices wisely. Below is a guide to selecting the right migration option; however, organizations have different processes and levels of digital maturity, therefore a selected option must fit and align appropriately with current and future organizational objectives.
Manual Migration from Source to Destination WCMS
There are several reasons to performing a manual migration, here a few below, for organizations that have selected this route.
- Opportunity to repurpose content: organization/site owners use the opportunity to rethink their content strategy
- Opportunity to rebrand the website(s)
- Opportunity to present/create a consistent corporate tone across websites
- Opportunity to induce harmonized information governance across organization
- Opportunity to retire obsolete content
- Opportunity to classify content as well as establishing retention schedules
A typical manual migration approach would include the following:
- Perform content analysis of all the different sites with the purpose of identifying all features/functionalities on the sites AS IS
- Determine any existing and new requirements (purpose is to capture current and relevant value added requirements)
- Consolidate all requirements and make tradeoff with stakeholders
- Group sites into batches based on similarity of needs, availability of internal content editor, and business priorities
- Proceed to develop new templates (layouts), components, and features/functionalities
- Move content from legacy sites into the new CMS using on new templates (Initial content copying/data entry may be outsourced)
- Internal site owner/content author review of the transferred/copied content on web pages.
- Go-Live of migrated site on new CMS
- Decommission legacy website / Archive
Use Cases for Manual Migration:
- Organizations that plan to migration from one vendor WCMS to a new Vendor WCMS: Here, it’s likely that the internal representation of content and eventual display/rendering greatly differ. Automating, in this case, would only lead to expensive and time-consuming post migration effort.
- Organizations that have acquired several silo WCMS resulting from acquisitions or mergers. The varied nature of the different web content management systems and hosting environments greatly complicate any automation initiative.
A manual migration is most meaningful in the above use cases–with the help of a content matrix, sites are manually copied or re-entered in a new CMS.
At the start of a migration run, Production (Prod) is the source WCMS with the active content whereas Staging is the target WCMS. Once migration is completed and tested (UAT & Post Migration), Prod becomes the new WCMS (target) and the old CMS (source) becomes a candidate for decommissioning.
Key Concerns with Manual Migration:
Development freeze on source WCMS
- Source WCMS is limited to bug fixes and placed on support mode. However, it may accept urgent business requirements, but these would also be reimplemented on target WCMS (additional cost)
- New business requirements would have to wait until the target WCMS is up and running.
Content freeze on source WCMS
- During migration run, new content is only entered in the not yet published new CMS.
- During migration run, an organization can’t update or publish information to the public.
Heavy people involvement
- Developers to create new layouts and functionalities
- Authors to re-enter content. However, initial copying exercise could be outsourced and the review and validation performed internally.
Stay tuned for the next article on wcms migration. The next article will focus on factory/automated and semi-automated approaches. You will need to read both episodes to have a complete picture of wcms migration considerations, hurdles, and lessons learned.
Read part 2 of this guide!
Latest posts by Carlson Ngwa (see all)
- A technical assessment of leading SharePoint Migration Tools - June 27, 2017
- WCMS Migration – A how-to Guide (part 2 of 2) - April 20, 2017
- WCMS Migration – A how-to Guide (part 1 of 2) - March 29, 2017