Knowledge base
Planning a migration window
The migration itself is usually twenty minutes. Everything that makes it safe happens in the week before.
A week before
- Lower your DNS TTL to 300 seconds. It has to be done far enough ahead that the old, long TTL has expired everywhere — that is the step people leave too late. See DNS records.
- Rehearse the whole thing on the new machine with a copy of the data. Time each step and write the timings down.
- Write the rollback, concretely: which records change back, which service starts again, who decides. A rollback plan invented during an incident is not a plan.
- Agree the window with whoever it affects. If our maintenance could collide with it, tell us — see maintenance and notice.
The day before
- Full backup of the source, and test that it restores — see testing a restore
- Certificates already issued and working on the new machine, via the DNS challenge so you do not need to move traffic first
- Monitoring already configured for the new machine, so you can see it working the moment it takes over
- A first sync of the bulk data, so the final one is small
The window itself
- Stop writes at the source, or put the application in read-only mode
- Final delta sync — this is why the first sync mattered
- Start the service on the new machine and test it directly by address, with a hosts entry, before anything public changes
- Change DNS
- Watch both machines. Traffic drains from the old one over the TTL rather than stopping dead
- Leave the old machine running, untouched, for at least a week
Decide the abort point in advance
Pick a time — say forty minutes in — at which, if it is not working, you roll back rather than keep debugging. Without that, every migration becomes open-ended, and the decision gets made by someone tired at the worst possible moment.
Before you call it done
- Certificates valid, and the renewal timer actually enabled on the new machine
- Cron jobs and timers present and running — this is the commonest omission
- Mail still flowing, with SPF, DKIM and PTR correct for the new address if it sends — see sending mail
- Backups configured and the first one verified
- Firewall rules in place; do not leave it open “until things settle”, see firewalling
- The old machine's data destroyed only after you are certain — see leaving
Migrate on a Tuesday morning, not a Friday evening. If something surfaces two days later, you want to be at work.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base