How to Change Your News CMS While Your Newsroom Keeps Publishing

Decide which system owns the live story

During preparation, give the newsroom one clear place to publish. If reporters edit the old CMS while another team changes the imported version, conflicting headlines, dates, and corrections can appear. Record which system is authoritative at each stage and who can approve the changeover.

Treat a story as more than its body text. The headline, photo, caption, category, byline, URL, publication time, and corrections may all change after the first export. Your migration plan needs a way to identify those changes and carry them into the destination without silently overwriting newer work.

Move the archive before moving the news desk

Begin with a representative sample on a restricted staging site. Check old and recent content, different language editions, and media-heavy stories. Once the mappings are accepted, transfer the larger archive while the current website continues serving readers.

Use this period to train editors and check templates, permissions, section navigation, and search. A rehearsal should include an ordinary story, a breaking update, a correction, and a photo replacement. Keep staging access and indexing controls distinct from the settings that will be required on the public site.

Plan the gap between the first export and launch

A delta import transfers changes made since an earlier export. Whether it is possible depends on the source system, available identifiers, reliable timestamps, and the destination importer. Ask the implementation team to demonstrate it with a new story, an edited story, and a changed media attachment before relying on it.

If reliable synchronization is unavailable, agree on a controlled alternative. That might be a short final editing window, a documented queue of late updates, or a smaller staged release. Assign someone to reconcile that queue before editors resume normal work. Avoid promising zero downtime or automatic synchronization without a verified mechanism.

Give the launch desk a written runbook

The runbook should name the person who authorizes the switch, the person handling technical changes, and the editor responsible for urgent coverage. Record the launch sequence, expected checks, communication channel, and the conditions that stop the release.

Protect the reader’s route to the archive

Keep valuable article URLs when practical. Where a path changes, map it to the relevant destination and check the redirect. Update links and the sitemap to point to the intended live pages. Google’s migration guidance emphasizes URL mapping, redirects, and monitoring when URLs change; those tasks belong in the launch plan.

Also inspect the newest stories and the pages readers use most: section fronts, author pages, ePaper access, search, and contact information. Confirm the public site has the correct canonical URLs and indexing permissions. Check the page readers actually receive, not only the record visible inside the CMS.

Keep a support window after the switch

The first working shift often reveals issues a technical import did not expose: an editor cannot find a draft, an old embed is missing, or a category has been mapped incorrectly. Keep a shared issue list with URLs, screenshots where useful, ownership, and resolution status.

Monitor server errors, search indexing, traffic, and operational integrations against the earlier baseline. Preserve the old system securely for the agreed recovery period and settle the export and retention plan before decommissioning it. A migration is complete when the newsroom can work reliably and the agreed content and reader journeys are accounted for.