Moving to a Dedicated Server With a Rollback That Works

Most dedicated server migrations go fine. The ones that do not go fine share a characteristic: there was no way back. The plan assumed success, so when something unexpected appeared at 2am, the only options were to push forward or improvise.

Plan the reverse path first and the rest gets easier.

Rehearse on the real hardware

Build the new server, migrate a copy of the data, and run the application against it — before the real cutover. Not a spec review; an actual working copy.

This is where you find the PHP extension nobody documented, the cron job that only exists in one user's crontab, the hardcoded path, the licence tied to a MAC address. Every one of those is a ten-minute fix in rehearsal and a crisis during cutover.

Choose your data transfer method deliberately

Dump and restore is simple and needs a maintenance window proportional to database size. Fine up to a point; that point arrives sooner than people expect.

Replication sets the new server up as a replica ahead of time, so at cutover it is already current and you are only promoting it. More setup, dramatically shorter window. Worth it for anything where an hour of downtime is a problem.

For files, an initial bulk copy followed by incremental syncs, with a final sync during the window. Do not attempt to copy everything in the window itself.

DNS, and the thing people forget

Lower TTLs 48 hours ahead, same as any migration. But also: find everything that references the old server by IP address. Application configs, cron jobs on other machines, third-party integrations, firewall allow-lists on a payment gateway or a partner's system.

Those do not follow DNS. They keep pointing at the old box until somebody changes them, and they are usually discovered when a partner reports failures the following week.

Define rollback before you start

Write down, in advance:

• What specifically triggers a rollback — not "if it goes badly" but a named condition and a time limit
• Who makes that call
• The exact steps, in order
• How long rollback itself takes

The critical detail: rollback stops being clean once the new system accepts writes. Once orders have been placed on the new server, reverting means losing them. Know where that line is, and treat it as the real point of no return.

Cutover sequence

1. Application into maintenance mode
2. Final incremental file sync
3. Final database sync, or promote the replica
4. Verify record counts match between old and new
5. Point DNS at the new server
6. Smoke test the paths that matter — login, checkout, whatever generates revenue
7. Maintenance mode off
8. Watch logs and resource graphs closely for an hour

The week after

Keep the old server running, powered on and untouched, for at least a week. Resist the urge to reclaim it immediately — it is your only real fallback, and the cost of another week is trivial against what it protects.

Watch load, memory and disk on the new box under genuine production traffic. Rehearsal load is never real load, and the first busy day is where sizing assumptions get tested.

About the author. Kislay Chandan has worked with schools since 2014. Rather than gathering requirements from the outside, he worked inside a school to see what actually goes wrong day to day, and built what he found into the software. He still works with Shemrock Glitters in Patna — most changes to the product start with something that came up there.