Cutover is the moment your domain starts pointing at the new platform instead of the old one, and the way to avoid downtime is to do almost all the work before that moment rather than during it: freeze content changes on the source, run a final synchronization, verify the destination on its own address, then switch, keeping the old platform fully reachable for a defined window afterward in case you need it.
This is a different problem from moving a site to a new server on the same platform, which is a hosting question this site does not cover. What follows is specific to the moment a content platform changes: where your CMS-to-CMS content migration hands off to the address that visitors actually use.
Before any of this, the backup and rollback plan has to be current and verified, and it has to survive the cutover itself: the source platform is your rollback path, so it stays running and untouched, not shut down the moment the new one goes live. If you have not already, rehearse this sequence on a test migration before running it for real. The cutover is exactly the part of the process where a rehearsal has the most value, because it is the step you get to do live only once.
Why a platform cutover is not a hosting move
Moving a site to a new server keeps the content model the same and changes where it lives. A CMS-to-CMS cutover changes the content model at the same time as the address, which means the destination has to already be a correct, complete copy of your content before the domain ever points at it, not something you finish configuring after the switch. That is the whole reason the sequence below front-loads almost everything before cutover day: there is no acceptable state where the new platform is live and still incomplete.
Preparing the window before cutover day
Lower your DNS record’s cache lifetime in advance, not on the day itself. A DNS record’s cache lifetime determines how long visitors and their internet providers keep using the old answer after you change it. Shortening that window ahead of time, days before the actual switch, is what makes the eventual change take effect quickly rather than slowly and unpredictably. This is preparation, done early, not part of the cutover sequence itself.
Decide your content freeze point. From the moment you start the final synchronization until the switch is verified, nothing new should be published or edited on the source. A freeze that starts too late means your final sync misses recent changes; one that starts too early means unnecessary downtime on the source while you wait.
Notify anyone who publishes to the site. If more than one person can add content, everyone needs to know the freeze window, or the “final” sync will not actually be final.
Verifying the destination before anything points at it
Before the domain changes at all, confirm the migrated content is correct on the destination platform’s own address, using its default or temporary URL, not the live domain. This is the point where the checks that matter, namely content fidelity, links, and taxonomy, get run against the destination as it actually is, while the live domain still points safely at the working source.
Treat this verification as a gate, not a formality. If something is wrong at this stage, the cost of fixing it is low: nobody has been sent to the new platform yet, and the source is still fully live. Finding the same problem after cutover is more expensive to fix and more visible while it is broken.
The sequence, in order
- Freeze content on the source. Stop publishing and editing at an agreed point.
- Run the final synchronization. Move whatever changed since your last full migration pass. This should be a small delta, not a repeat of the whole migration, if the freeze point was chosen correctly.
- Verify the destination on its own address. Full content check, not a spot check, against the source as it stood at the freeze point.
- Point the domain at the destination. This is the actual cutover: the step everything before it exists to de-risk.
- Keep both platforms reachable. The source stays live and available, not decommissioned, for a defined window after the switch.
- Monitor. Watch for errors and unexpected behavior on the new platform while both systems are still available for comparison.
What to watch for while both systems are live
Because a DNS change does not take effect for every visitor at the same instant, some visitors will keep reaching the old platform for a period after you switch, while others reach the new one. Both platforms need to work correctly during this window, which is a stronger requirement than treating the old one as an inert backup you can ignore. Keep the source reachable, keep it in whatever state it was in at the freeze point, and resist the temptation to make changes to it once the new platform is live, since that would leave the two platforms with different content and defeat the point of having a rollback at all.
Plan to keep the source available for at least a week after cutover, not decommission it the same day. Problems that only surface under real traffic, rather than in verification, often take longer than a few hours to appear, and the source is only useful as a rollback path for as long as it still exists and still matches what visitors expect.
Once the cutover has held for a period without incident, the post-migration audit is the next step: a fuller check than what you ran before switching, now against the live site under real traffic. For where cutover fits in the overall sequence, the migration guide sets out the order the whole cluster follows.
FAQ
When exactly should I change my DNS settings?
Only after the destination has been fully verified on its own address and your content freeze is complete. Lower the DNS cache lifetime days in advance so the eventual change propagates quickly, but make the actual switch only once verification has passed.
How long should I keep the old platform running after cutover?
At least a week is a reasonable minimum, longer if your traffic or publishing cadence gives you reason for caution. The source platform is your rollback path only while it still exists and still reflects the state you migrated from.
Do I need to freeze content before migrating, or just before cutover?
Just before cutover, and only for the gap between your final synchronization and the switch itself. A freeze that starts too early costs you unnecessary downtime on a system that is still working fine.
What if I find a problem after the domain has already switched?
That is what the rollback window is for. If the source platform is still live and unchanged, you can point the domain back at it while you fix the problem, rather than trying to fix it live on the new platform under traffic.
Is this the same as moving a WordPress site to a new hosting provider?
No. A hosting move keeps your content platform the same and changes where it runs, which is a different problem with different risks. This sequence is specifically for the moment your content platform itself changes.
Written August 2026, based on general cutover and DNS-propagation practice as documented across hosting and migration guidance current on that date, not tied to a specific platform’s release. Review this article’s guidance again in roughly six months, since propagation defaults and platform import behavior can shift.
