Migration
Hosting migration rollback: decide how you will reverse a failed cutover
Hosting migration rollback means preserving a safe path back while traffic and data move. The rollback must account for writes created on the new environment, DNS cache overlap, mail/cron/webhook behavior, and changes made to the source during preparation; it is more than saving the old IP address.
Freeze destructive source changes
Keep the old hosting account/server intact until verification ends. Record files, database, DNS, mail, cron, redirects, certificates, runtime versions, integrations, and any source-specific configuration.
Avoid cancelling the old provider on the same day as DNS cutover.
Define the authoritative data point
Decide when the database/uploads switch from source to destination and how final writes are synchronized. For transactional sites, use maintenance/read-only, replication, or an explicit final delta process.
If rollback occurs after new writes, plan how those writes return to the source or are preserved.
Keep DNS rollback narrow
Save old/new records and TTLs, change only the service records required, and leave unrelated mail/verification records alone. Remember recursors can hold both old and new values through the transition.
A low TTL reduces cache duration but does not guarantee immediate convergence.
Set rollback triggers and end condition
Define errors/latency/data-integrity failures that trigger rollback, who decides, and what tests prove recovery. End the rollback window only after real traffic, writes, jobs, mail, and monitoring are healthy on the destination.
- Keep source alive.
- Plan write synchronization.
- Save exact DNS.
- Define trigger/owner/end condition.