Website Migration Between Hosts: A Zero-Downtime Cutover

This page explains how a website migration between hosting providers actually works, from discovery through DNS cutover to rollback, and is written for IT managers, digital leads and agency owners who need the move to happen without an outage.

Most website migrations do not fail at the technical step people worry about. The database copies fine. The files transfer fine. What goes wrong is a CAA record nobody checked, a payment gateway webhook still pointing at the old IP, a TTL of 86400 that was never lowered, or an SSL certificate that cannot be issued because the validation challenge is being served by the server you just left. These are all sequencing problems, and sequencing is the part that gets skipped when three parties are involved and none of them owns the whole job.

What people mean by migration, and the four kinds that get confused

"Website migration" is used to describe four quite different projects with different risk profiles. Being clear about which one you are doing changes the entire plan.

This page is about the first one, the host-to-host cutover, because it is the one that is supposed to be invisible to users and the one most often treated as trivial. If you are also changing who looks after the site afterwards, the handover considerations in website migration to a new vendor apply on top of everything below.

Discovery: inventory everything before you touch anything

A migration plan is only as good as the inventory it is built on. The failure mode is discovering a dependency during the cutover window, at which point you are debugging under time pressure with the site half-moved.

Before any file is copied, the inventory should cover:

• Runtime versions: PHP or Node major and minor version, extensions loaded, opcache settings, memory limits, max_execution_time.
• Database engine and version, character set and collation, and any stored procedures, triggers, events or full text indexes.
• Web server configuration: virtual hosts, rewrite rules, custom headers, request body size limits, reverse proxy behaviour.
• Cron jobs and scheduled tasks, with their schedules and the user they run as. These are the single most commonly forgotten item.
• Outbound mail: SMTP relay, credentials, sending domain, and whether the application sends directly or via an API.
• Environment variables and secrets, including API keys that may be IP-bound.
• Every DNS record on the zone, not just the A record.
• Search, queue, cache and object storage services: Elasticsearch, Redis, Memcached, S3 buckets.
• Scheduled integrations and anything that connects inbound on a fixed IP.

Write the inventory down. The same document becomes the verification checklist on cutover night.

DNS reality: TTL, propagation and the records you can break

DNS is where a zero-downtime cutover is won or lost, because it is the only part of the process you cannot fully control once it is in motion.

Reduce TTL days in advance

If the A record TTL is 3600 or 86400, resolvers will keep serving the old IP for that long after you change it. Reduce the TTL on the records you intend to change to 300 seconds at least 48 hours before cutover, so that the old long TTL has fully expired from caches before the short one takes effect. Raise it again a week after the move. Note that some recursive resolvers ignore very low TTLs and enforce a floor, so plan for a tail of traffic hitting the old origin regardless.

Records that are not the website

The most common migration-caused outage is not the website at all, it is email. If the zone is being recreated on a new DNS provider rather than edited in place, every record has to be reproduced exactly:

• MX records and their priorities.
• SPF TXT record, including every include: for marketing platforms, CRMs and transactional senders.
• DKIM selectors, which are usually CNAMEs with unguessable names and will not be rediscovered if lost.
• DMARC policy at _dmarc.
• Domain verification TXT records for Google, Microsoft and any SaaS platform.
• CAA records, which will silently block certificate issuance from a certificate authority that is not listed. If your old host used DigiCert and your new stack uses Let's Encrypt, issuance fails until the CAA record allows letsencrypt.org.
• SRV records for services such as Microsoft 365 autodiscover.

Export the full zone file from the current provider and diff it against the new zone before you change the nameservers. Do not rebuild from memory.

Certificates issued before cutover, not after

A certificate must be valid and installed on the new origin before any traffic reaches it. The complication is that ACME HTTP-01 validation serves a challenge file over port 80 on the hostname being validated, and that hostname still resolves to the old host. There are three practical ways through this.

• DNS-01 validation. Prove control by publishing a TXT record at _acme-challenge. This works before cutover and is the cleanest option, and it is the only way to issue a wildcard.
• Issue on a temporary hostname, then reissue. Acceptable for testing, but leaves a gap at cutover.
• Import an existing certificate and private key from the current host if it is a commercial certificate with time remaining.

Check HSTS before you go anywhere near the cutover. If the site sends Strict-Transport-Security with a long max-age, or the domain is on the HSTS preload list, a certificate error on the new origin is not a warning users can click through. It is a hard block with no bypass. Verify the full chain with an external checker, not just a browser on a machine that may already trust an intermediate.

Database strategy: dump, delta sync or read-only window

The database is the only asset that changes while you are moving it. How you handle that depends entirely on how much write activity the site has.

For MySQL and MariaDB, take the seed dump with mysqldump --single-transaction --quick on an InnoDB database so you get a consistent snapshot without locking tables, then either configure the new server as a replica using binary log position or GTIDs, or take a short final dump during the window. For PostgreSQL, logical replication from the old primary to the new instance lets you promote with a very small gap. Whichever route you choose, confirm character set and collation match. A migration from utf8 to utf8mb4 that is not handled deliberately will mangle emoji and non-Latin characters in a way that is tedious to unwind later.

Files, media and user uploads

Application code should come from version control and be deployed to the new environment, not copied from the old server. Uploaded assets are different: they only exist on disk or in object storage.

Sync them in two passes. Run a full rsync -a days before cutover while the old site is live, then a second incremental pass during the window to pick up anything added since. Preserve ownership and permissions, and check for symlinks that point at absolute paths which will not exist on the new host. If assets are already in S3 or equivalent, you may be able to leave the bucket in place and only change the credentials and CORS policy, which removes a large chunk of transfer time. Verify file counts and total bytes on both sides before declaring the sync complete.

Third-party dependencies that break quietly

These are the items that pass every test on cutover night and fail three days later when a scheduled job runs.

• IP allowlists. Payment gateways, bank feeds, government APIs, partner SFTP endpoints and some CRMs restrict access by source IP. The new egress IP has to be registered in advance, and some of these take a week to action.
• Webhooks. Inbound callbacks from payment providers, form platforms and CRMs are configured in the remote system. If they resolve by hostname they will follow DNS. If they are pinned to an IP, they will not.
• SSO. SAML and OIDC configurations contain assertion consumer service URLs, redirect URIs and signing certificates. A new certificate on the service provider side needs the identity provider updated.
• Outbound email. If the application sends via the local MTA, a new server IP has no sending reputation and SPF will fail unless updated. Route transactional mail through an authenticated relay.
• CDN and WAF. If the site sits behind a proxy, the origin IP changes while the public IP does not, which is helpful. Firewall rules on the new origin must still allow only the proxy's ranges, and the application must read the real client IP from the forwarded header. Our notes on running enterprise sites behind Cloudflare cover the configuration in more detail.

Staging verification before you move production

The new environment should run the full site, with production data, under its real hostname via a hosts file override, before cutover is scheduled. Test with the hostname forced locally rather than on a temporary subdomain, because absolute URLs, cookie domains, canonical tags and CSRF origin checks all behave differently otherwise.

The verification pass should cover authenticated sessions, admin login, a complete checkout or form submission end to end, file upload, search, scheduled task execution, email delivery, 404 and 500 handling, redirect rules, and a crawl of the site compared against a crawl of production to catch status code differences. Make sure staging is blocked from indexing while it is public, and equally make sure that block is removed before the site goes live. A noindex header carried into production is one of the more painful self-inflicted migration injuries.

The cutover window itself

A well-prepared host-to-host cutover is short, because everything expensive has already been done. A workable sequence:

1. T minus 72 hours. Lower TTLs. Confirm certificates issued and installed. Confirm IP allowlist changes applied.
2. T minus 24 hours. Full file sync. Seed database restore. Replication running or delta process tested.
3. T minus 1 hour. Freeze content editing. Notify stakeholders. Disable cron on the new environment so nothing fires early.
4. T zero. Put the old site into read-only mode or maintenance. Run the final delta sync and incremental file pass. Verify row counts on key tables.
5. T plus 10 minutes. Run the verification checklist against the new origin with a hosts override. Do not change DNS until it passes.
6. T plus 20 minutes. Update the A or CNAME record. Enable cron on the new environment.
7. T plus 25 minutes. Watch logs on both origins. Traffic should appear on the new one within a few minutes and taper off the old one over the following hour.
8. T plus 2 hours. Confirm old origin traffic has fallen to near zero. Check error rates, response times and transaction volume against the pre-migration baseline.

Keep the old origin serving the old site during the tail, rather than switching it off or showing a maintenance page. Visitors on stale DNS should get a working site, not an error. The only thing that must not happen is writes landing on the old database, which is what the read-only mode is for.

Rollback criteria and how long to keep the old environment

Decide the rollback triggers before the window opens, and write them as thresholds rather than judgement calls. Typical criteria: error rate above an agreed percentage of requests, checkout or lead form success rate materially below baseline, median response time above an agreed figure, or any data integrity problem at all.

Rollback is repointing DNS back to the old origin and lifting read-only mode. That is clean only while the new environment has taken no writes you cannot afford to lose. Once orders or form submissions have landed on the new database, rollback becomes a data reconciliation exercise instead, which is why the first two hours matter so much more than the next two days.

Keep the old environment running and paid for at least 30 days. You will want it for anything that turns out to have been on that server and in nobody's inventory, and for log comparison when someone asks why a metric moved.

After the cutover

The migration is not finished when the site loads. The week afterwards is where the quiet failures surface.

• Confirm backups are running on the new environment and, more importantly, restore one to prove it works.
• Re-point or recreate uptime and availability monitoring, including SSL expiry checks, and confirm alerts reach a human.
• Compare server response times and Core Web Vitals against the pre-migration baseline you captured. A faster server with a cold object cache can look slower for the first day.
• Check Search Console for crawl errors and a spike in 404s or 5xx responses, and resubmit the sitemap.
• Watch for redirect chains introduced by new web server rules, particularly http to https to www sequences that should be a single hop.
• Verify logs, log rotation and retention are configured, and that security patching is scheduled rather than assumed.

Frequently Asked Questions

How long does a website migration between hosts take?

Preparation for a typical CMS site takes one to three weeks, covering discovery, environment build, data sync and staging verification. The cutover window itself should be under an hour for a lift and shift, and under a few minutes of write downtime if database replication is used. Large ecommerce platforms, complex integrations or multisite estates extend the preparation phase, not usually the cutover.

Can a website really be migrated with zero downtime?

Zero downtime for visitors is achievable, because both origins serve the same site during DNS propagation and users are never sent to a broken server. What cannot be avoided entirely is a short write freeze while the final database delta is applied, typically seconds to a few minutes depending on the strategy. The practical goal is zero visible outage and a write pause short enough that nobody notices.

Will migrating to a new host affect SEO rankings?

A same-domain host migration should have no ranking impact if URLs, status codes, redirects and robots directives are identical before and after. Rankings suffer when a staging noindex survives into production, when redirect rules change silently, or when response times degrade on the new infrastructure. Crawl the site before and after and compare status codes URL by URL to prove nothing moved.

Why do I need to lower the DNS TTL before migrating?

Recursive resolvers cache DNS records for the duration of the TTL, so a record with a TTL of 86400 can keep sending traffic to the old server for a full day after you change it. Dropping the TTL to 300 seconds at least 48 hours ahead means caches expire quickly once the change is made. Raise the TTL again about a week after the migration to reduce unnecessary lookups.

Does migrating website hosting affect my email?

It does if email is hosted on the same server or if the DNS zone is recreated at a new provider rather than edited in place. MX, SPF, DKIM and DMARC records must be reproduced exactly, and DKIM selectors in particular are difficult to recover once lost. Export the full zone file first and diff it against the new zone before changing nameservers.

Who is accountable if something breaks during a migration?

That depends entirely on how the work is contracted. When an old host, a new host and a separate development team are each responsible for one piece, nobody owns the sequencing, and during an incident each party can reasonably point at the others. A single provider holding both the infrastructure and the application work removes the gap, which is the main argument for consolidating migration and ongoing hosting with one team.

Talk to UnDigital about migrating and then managing your hosting

UnDigital runs host-to-host migrations for enterprise, government and ecommerce sites on WordPress, Silverstripe, Drupal, Magento and custom applications, and then keeps running them afterwards under an SLA. That matters more than it sounds. The team that built the inventory, mapped the DNS zone and watched the logs on cutover night is the same team patching the server six months later, so nothing gets lost in a handover that never happens.

Every engagement starts with an infrastructure audit of the current environment. If you are still deciding where the site should land, our guidance on what to look for in managed website hosting in Australia and how to evaluate a managed web services provider is a reasonable place to start, and the managed hosting service itself is available as hosting plus management, hosting only, or management only if you are bringing your own AWS or Azure infrastructure.