How to Plan a Successful CMS Migration

A CMS migration can move every page and still fail the people who use the website. Editors may lose approval history, visitors may reach broken addresses and a scheduled announcement may disappear between the final export and launch. Successful migration means preserving the content operation and public journeys that matter, not merely importing rows into a new database.

The work combines editorial decisions, data transformation, technical delivery and operational coordination. Each needs an owner. A migration estimate should account for those responsibilities before a launch date becomes a public commitment.

Begin with a clear reason for the move. The new system might improve editing, support structured content or replace an unsuitable platform. Use that purpose to decide what should change and what continuity the organisation needs to protect.

Define the migration boundary

List what is moving: pages, structured records, assets, users, redirects, metadata and publication history where required. Include content stored outside the CMS if it feeds the website. A document library or external product feed may be essential even though it is absent from the page export.

Separate the platform migration from optional redesign work. Some changes may be necessary to fit the new model, while others can be deferred. Combining a new platform, new information architecture and extensive rewriting increases the number of variables the team must validate.

Agree the destination of material that will not move. Retired content may need an archive, a redirect or an appropriate unavailable response. Do not let omission from the import become an accidental editorial decision.

Write acceptance criteria around the intended service. Editors can publish an approved update, important old links reach the right destination and assets retain appropriate access. These statements give the team a more useful target than “all content migrated.”

Build an inventory with accountable owners

Create a structured inventory from the current system and supplement it with representative public crawling where appropriate. Record identifiers, URLs, content types, publication state, language and important relationships. Keep the extraction method repeatable so the inventory can be refreshed.

Assign a content owner to each meaningful collection. The owner decides whether information remains accurate and which version is authoritative. Developers can transform data, but they should not have to infer business meaning from conflicting copies.

Mark content for retention, revision, consolidation or retirement. Start with high-value and high-risk material rather than demanding that every page receive equal review at once. The priority should reflect audience use and the consequences of getting the content wrong.

Identify orphaned records and assets. A file may have no current page link yet remain important through an external address. Conversely, a large unused asset collection may not deserve automatic transfer. Investigate enough context to make a deliberate choice.

Design the target model with real examples

Map each source content type to its destination structure. Decide which information becomes a field, relationship, reusable component or ordinary prose. The target should support the intended editorial work rather than reproduce every historical workaround.

Use representative records to test the mapping. Include long text, missing optional values, multiple languages and unusual relationships. A clean sample page cannot reveal all the conditions in a mature content collection.

Document transformations explicitly. If one source field contains several values, state how they are separated and what happens when the format is ambiguous. Send unresolved cases to the appropriate owner instead of silently guessing.

Keep source identifiers during migration where useful for traceability. A mapping between old and new records makes it easier to reconcile counts, update relationships and investigate a reported problem. It also supports repeatable imports without creating duplicates.

Treat URLs as part of the content contract

Build an old-to-new URL map before launch. Preserve useful addresses where practical, and identify the relevant destination for pages that move or merge. A blanket redirect to the homepage rarely preserves the visitor's original task.

Google Search Central's site-move guidance describes preparing URL mappings, using appropriate redirects, updating internal references and monitoring the move. Apply the relevant steps to your migration rather than assuming a CMS import preserves search visibility automatically.

Check canonical references, language relationships and sitemaps in the generated output. The administration interface may display a correct URL while templates or configuration still emit an old one. Validate the public result that visitors and crawlers receive.

Test important external entry points, including downloads and campaign links. Record the expected result for each and verify it after cutover. The migration plan should protect meaningful journeys, not just the URLs most convenient to check.

Move assets with their meaning and permissions

Identify where images, documents and derived files live. Some may be stored in the CMS, others in object storage or a separate media service. Include the relationships that connect those assets to content records.

Preserve useful metadata such as descriptions, alternative text and usage information according to the organisation's needs. A file transfer that loses its editorial context can leave the new library difficult to manage.

Review access separately from file existence. Private documents should remain private, and draft assets should not become public merely because the new storage location is reachable. Test with both authorised and unauthorised access contexts.

Check representative rendering and downloads. Image crops, file names, document links and embedded media can behave differently in the new templates. Confirm that the result remains useful on the actual pages where the assets appear.

Recreate workflows deliberately

Map roles and publication states to the new system. A draft, an approved revision and a scheduled release may not have exact equivalents. Decide how each should behave and communicate the change to the people who own the workflow.

Clarify what history must remain available. The organisation may need old versions, reviewer decisions or a record of publication changes. Decide whether that information belongs in the new CMS or a controlled archive, and verify that the chosen approach meets the actual requirement.

Test publication dependencies. A page may rely on a related record or asset that has not yet been released. The new workflow should make those dependencies manageable rather than leaving editors to discover them after publication.

Include urgent correction and withdrawal. A migration is not ready simply because the planned approval route works. Staff need to handle an incorrect public statement through an understood process on the first day of operation.

Make the import repeatable

Use a deterministic transformation and import process where practical. A migration usually needs several rehearsals, and the team should be able to rerun the same inputs without uncontrolled duplication or inconsistent relationships.

Keep a record of imported, rejected and unresolved items. A successful process exit does not show that every intended record arrived. Produce results that content owners can review and connect errors to identifiable source records.

Separate data cleanup from undocumented manual fixes in the destination. If a correction must be repeated after the next rehearsal, encode it in the transformation or maintain an explicit editorial decision record. Otherwise each rerun can reintroduce the same problem.

Protect the source during extraction and rehearsal. Use appropriate access and avoid changing production records merely to simplify a test. The organisation still needs the existing site to operate while the new one is prepared.

Reconcile more than record counts

Counts are useful but incomplete. The same number of pages can conceal missing text, broken relationships or one duplicated item replacing another. Compare identifiers and important fields as well as totals.

Create checks by content type. For a service page, that may include title, body, contact relationship and public URL. For a document, it may include the file, access rule and related product. Choose checks that reflect the meaning of each record.

Review a representative visual sample with editors. Automated comparisons may not reveal a heading hierarchy damaged by rich-text conversion or a table that becomes unreadable. Human review should focus on the transformations most likely to affect comprehension.

Track unresolved exceptions with an owner and launch consequence. Some may be acceptable to defer if the affected content is deliberately withheld. Others may block an important public journey. The sponsor needs that distinction to make a responsible readiness decision.

Choose a strategy for changes during the move

A migration rehearsal and final launch rarely happen at the same instant. Decide how edits made in the source during that interval will reach the destination. The approach depends on publishing frequency and the tools available.

A short content freeze may be workable for a small site. A busy operation may need a final incremental transfer or a carefully controlled change log. Whatever the method, editors should know which system is authoritative at each stage.

Include scheduled and unpublished material in the plan. A future announcement may change after the main content export, and a draft may depend on a newly uploaded asset. Test these cases rather than focusing only on currently public pages.

Avoid uncontrolled editing in both systems. Conflicting revisions are difficult to reconcile when neither location has clear authority. Define who can make exceptions and how those changes are recorded for the final transfer.

Rehearse the cutover as an operating event

Write the cutover sequence with prerequisites, responsible people and observable checks. Include the final data transfer, configuration changes, cache behaviour and verification of public and editorial journeys. Keep the sequence specific to the actual architecture.

Run a rehearsal in an appropriate environment and time the meaningful steps. Use the result to refine the launch window and identify dependencies. A theoretical schedule should not become a commitment without testing the difficult parts.

Define stop conditions. If the final reconciliation shows missing critical records or access tests fail, the team should know whether to delay, restore a previous state or apply a known correction. These decisions are easier to make before launch pressure builds.

Plan customer and staff communication where the move affects availability or working arrangements. Explain the expected interruption and the route for reporting problems. Avoid promising seamless continuity unless the implementation and rehearsal support that claim.

Make rollback account for new work

Returning traffic to the old system may be technically simple while preserving edits made after launch is not. Decide how new content, submissions and other business activity will be retained or reconciled if the team changes direction.

Distinguish code rollback from data recovery. A template defect and a destructive data transformation require different responses. The recovery plan should reflect the actual changes made during migration rather than rely on a generic instruction to restore a backup.

Verify access to the required backups and configuration before cutover. Identify who can perform recovery and how the team confirms the restored system is usable. Include assets and external dependencies as well as the database.

Keep the rollback window explicit. As new work accumulates, returning to the old platform may become more complex. The team should understand when a forward correction is more appropriate and who makes that decision.

Use a representative migration rehearsal

Consider a regional service website with shared office records, translated pages and private staff documents. Select one service that uses all three. Migrate its content and relationships before attempting the entire site.

Ask an editor to update a shared contact detail, preview both language versions and obtain the required approval. Then test an old public URL and an unauthorised document request. This exercise checks editorial continuity, visitor continuity and access in one bounded sample.

Introduce a late source edit after the first import and run the planned incremental process. Confirm that the destination receives the change without duplicating the record or losing a deliberate local variation. Record any manual intervention and decide whether it can be eliminated or safely owned.

The result becomes evidence for the full migration plan. If the sample exposes a model problem, resolve it before multiplying the work across hundreds of records. If it succeeds, retain the checks and use them during later rehearsals and launch.

Create a launch decision pack

Before the migration window, assemble a short decision pack that connects readiness to evidence. It should identify the final data set, unresolved exceptions, completed rehearsals and the people responsible for cutover. The sponsor needs to understand the remaining risks without reading every import log.

For each exception, state the affected content or workflow and the consequence of launching with it unresolved. A missing decorative image and an incorrectly public staff document have different significance. The decision should reflect that difference rather than treating every outstanding item as equal.

Include the final change-capture plan. Editors should know the last point at which they can use the source, how urgent corrections are handled and when the destination becomes authoritative. Confirm that the people working during the launch window received the plan, not only the project team that wrote it.

List the checks that demonstrate a usable service immediately after cutover. These might include a priority public URL, a private document denial, a scheduled publication and an editor's approved update. Keep the list small enough to run promptly but representative enough to expose a serious migration failure.

Record who can decide to stop or recover, and which evidence triggers that decision. A launch team should not have to find an unavailable sponsor while deciding whether missing critical content is acceptable. The authority needs to be practical for the actual window.

Finally, define when the migration project hands ownership back to normal operations. That may follow a successful publishing cycle and resolution of material exceptions rather than the instant traffic switches. The destination is only fully established when editors and support can carry out their responsibilities confidently.

A concise decision pack makes launch review concrete. It also preserves the reasoning for later investigation, so an unexpected issue can be compared with the tested assumptions and the content state the team intended to release.

Keep ownership through the first publishing cycle

After cutover, monitor errors and review important entry points and publishing tasks. Invite editors to report unexpected behaviour through an owned route. Early operational feedback can reveal issues that a pre-launch sample did not include.

Retain the source archive and migration mapping for the agreed period so investigations remain possible. Remove temporary access and migration tools when they are no longer needed, following the organisation's retention and operating decisions.

A useful first step is to select one difficult content type and prove its journey from source to public output, including editing, permissions and old links. That small end-to-end migration gives the project a reliable foundation for scope, timing and launch readiness.

---