How to plan a website migration with rollback

Most migration horror stories share one root cause: the old environment was dismantled before the new one had proven itself. A migration succeeds when the new environment is verified and the old one still works as a recovery path. DNS is just the final traffic switch — the migration is everything you do before you touch it.

Inventory the complete system

List domains, DNS records, files, databases, object storage, uploads, users, certificates, cron jobs, queues, mail, webhooks, APIs, secrets, redirects, analytics, monitoring, and third-party allowlists. Record versions and required extensions.

Identify where the system accepts writes. Orders, form submissions, uploads, comments, and account changes can be lost if two environments diverge.

Define success and rollback

Write measurable acceptance checks for public pages, administration, authentication, transactions, email, background work, performance, and logs. Choose rollback triggers and name the person authorized to act.

Document the old DNS values, previous release, and the steps required to direct traffic back. Confirm the old environment can continue serving the site for the observation window.

Prepare the destination

Match supported runtime, database, extensions, storage, network access, environment values, and file permissions. Install monitoring and backup before launch, not after.

Issue TLS certificates or prepare automated issuance. Restrict search-engine access to private testing without embedding temporary rules that could ship to production unnoticed.

Copy and test privately

Copy files and data, then test the destination through a hosts-file override, private hostname, or platform preview. Avoid changing public DNS just to see whether the new server works.

Use the real public hostname when testing where possible so cookies, redirects, canonical URLs, and certificate coverage behave correctly. Confirm outbound email and webhooks do not affect real customers from the test environment.

Plan the final data sync

Choose one approach:

• Pause writes briefly, run a final sync, then cut over.
• Replicate data continuously and promote the destination.
• Route writes to one system while both can serve safe reads.

The right method depends on data volume, business tolerance, and application support. “We’ll sync again after” is not a plan — it’s how orders go missing.

Cut traffic deliberately

Lower relevant TTLs ahead of time, then execute the data plan and change only the intended DNS or routing values. Follow the DNS cutover runbook.

Verify authoritative and recursive DNS, HTTPS, redirects, key user journeys, queues, email, logs, and new writes. Monitor both environments for traffic and unexpected changes.

Observe, close, and retire

Keep the old environment read-only or otherwise protected during the observation period. Raise TTLs after stability is established. Re-enable normal deployments, confirm backups, rotate temporary credentials, and update documentation.

Retire the old environment only after logs show no meaningful traffic and all data, jobs, mail, storage, and integrations have been accounted for.