Control content changes during a CMS migration

Define the content inventory and editors

Inventory drafts, scheduled posts, images, attachments, authors and localized copies as well as published articles. Identify where each editor makes changes and whether the migration export represents the live publication. Page counts cannot reveal a missing image or a draft accidentally made public. Record stable identifiers, publication state, URL and modification time, with an owner for approving changes during migration. Include content created by automated imports, because stopping human edits alone does not freeze a system that still receives scheduled updates.

Define a bounded freeze window

If a freeze is possible, specify its start, scope and the person who can end it. Consider completing the bulk transfer and checks before a shorter final-delta window rather than halting publishing for the entire project. Keep an emergency correction route and require approved exceptions to enter the change ledger. A request not to edit does not stop scheduled publication or another import process. Check the actual update paths and state which remain active, so the migration owner can explain what the word frozen means.

Track unavoidable changes explicitly

For unavoidable corrections, record the content identifier, time, editor, reason and authoritative updated copy. The migration operator records when that delta was applied and who verified it. Decide whether editing in the new CMS is allowed; otherwise two teams may independently change the same article. Track URLs, publication state, relationships and replaced assets, not only body text. Treat deletion as an explicit change so a final bulk import cannot resurrect an article the editorial team intentionally withdrew during the project.

Check what export and import actually preserve

Read the active CMS’s export and import documentation rather than assuming one CSV preserves every feature. Webflow documents CSV workflows, but you still need to distinguish updating an identified item from creating a new item. Verify references, assets, rich text and localized content with representative records. A wrong import mode can create duplicates. Test a small set against expected publication states before expanding. Keep the import method and mapping with the migration record so the final delta uses the same understood rules.

Reconcile the final snapshot by identifier

Before cutover, save the final inventory and compare identifiers, bodies, URLs and publication states across both systems. A correction in one language is not evidence that its counterpart was checked. Inspect representative rendered pages for assets and links as well as stored text. Classify unresolved differences as launch blockers or explicitly assigned follow-up work with deadlines. Preserve enough of the accepted final snapshot to reproduce what was approved; otherwise a later issue cannot be distinguished from a change made after the migration.

Resume editing in one authoritative system

After cutover, name one authoritative editing system and tell all editors where new changes belong. Keeping the old CMS for rollback does not mean using both for normal publication. Verify the first new edit, including language, URL and publication state, and define when the migration ledger can close. Confirm that exceptions have an owner and no unapplied deltas remain. The related multilingual and handover guides cover continuing operation; this procedure establishes which content version actually survived the transition.

• Hand over a client website without losing operational ownership
• Choose a platform for a Japanese-English business website