Every migration has a moment where the old system stops being the real one and the new system takes over. That moment is the cutover, and it is the part clients lose sleep over, because they have all heard a story: the email migration that ate a weekend, the new server that went live Friday and was down Monday. Those stories are real, and they are almost always planning failures, not technical ones. Here is how we run cutovers so the business keeps working straight through them.
The core idea: never burn the bridge behind you
Every technique below comes down to one principle. At no point during a migration should the old system be gone before the new system is proven. Amateurs move things; professionals run things in parallel and then switch. The switch is small, fast, and reversible. The move happened earlier, quietly, while nobody was watching.
Parallel runs
Before any cutover, the new system runs alongside the old one, doing real work with real data, while the old system remains the one everyone uses. For a server migration, that means the cloud VM is built, the data is replicating continuously, and we are logging into it daily. For an email migration, mailboxes are synced and mail flow is tested to a pilot group. For a new application server, a handful of users work on it for days before anyone else knows it exists.
The parallel period is where problems are supposed to appear. A report that renders wrong, a printer that cannot reach the new host, a permissions gap. Every one of those found during the parallel run is a Tuesday-afternoon fix. The same problem found after cutover is an outage. So we do not rush this phase, and we treat "we found three problems this week" as the process working, not failing.
Lowering DNS TTLs ahead of time
Many cutovers ultimately happen in DNS: a name that pointed at the old server starts pointing at the new one. DNS records carry a TTL, a time-to-live, which tells the rest of the internet how long to cache the answer. If your record's TTL is 24 hours, some users will keep landing on the old server for up to a day after you change it. That is a slow, partial, confusing cutover.
So days before the switch, we drop the TTL on the relevant records to something like 300 seconds, five minutes. Nothing visible changes, but now the internet checks back frequently. On cutover day, we update the record, and within minutes essentially everyone is on the new system. If something is wrong, pointing the record back also takes minutes. After things settle, the TTL goes back up. This is a small, free step, and skipping it is one of the most common mistakes in DIY migrations.
Rollback plans, written before they are needed
Every cutover we run has a written rollback plan before it starts. Not "we'll figure it out," but specific steps: which record gets pointed back, which sync gets reversed, who makes the call, and, most important, what the decision criteria are. Something like: if core functions are not confirmed working within 45 minutes, we roll back and reschedule, no debate.
Deciding that threshold in advance matters because in the moment, everyone wants to push through. It is one in the morning, the fix feels ten minutes away, and it has felt ten minutes away for two hours. A pre-agreed line takes ego out of it. Rolling back is not failure; it converts a potential Monday outage into a rescheduled maintenance window nobody outside the room ever hears about. We have rolled back cutovers and had the second attempt go clean a week later. That is the system working.
A rollback plan also has to be tested in one specific way: the old system must still be intact and untouched. This is why we never decommission, repurpose, or "clean up" the old environment on cutover night. It sits there, powered on, ready to take the load back, until the new system has survived real use.
Cutover windows, chosen on purpose
Even a well-planned switch deserves a window: a scheduled block of time when the change happens, users know about it, and the right people are on hand. We pick windows based on the actual rhythm of the business, not a generic "weekends are safe." For a restaurant group, Monday morning beats Saturday night. For an accounting firm, nothing moves in the first two weeks of April. The right window is when a hiccup would cost the least and when the people who can verify the system, meaning your staff who actually use it, are reachable.
Inside the window, the sequence is boring on purpose: final data sync, switch, verify against a written checklist, then a decision point. The checklist is written with the client beforehand and is specific: can the front desk pull up a customer, can invoices print, does mail flow in both directions. "It seems fine" is not a verification.
The morning after matters as much as the night of
Cutovers do not end when the switch flips. The first business day on the new system is part of the plan: someone is watching, response time is short, and the old system is still one decision away. Most post-cutover issues are small, a mapped drive here, a bookmark pointing at an old address there, and they surface in the first hours of real use. Being present for that window is the difference between "the migration went fine" and "the new system was a disaster," even when the underlying work was identical.
What this looks like from your side
If your IT provider is doing this well, you will notice mostly paperwork: a schedule, a checklist with your staff's names on it, a rollback plan you were asked to approve, and a boring switch night. If instead the plan is "we'll move everything over the weekend and it should be up Monday," with no parallel period and no written way back, that is the story that ends badly. Downtime during migrations is not bad luck. It is a plan with the safety steps skipped.
Stuck on this, or want it done for you? That's the job.
Email us →