How to migrate hosting safely without taking your site down

Moving hosting without downtime is a sequencing problem more than a technical one. Inventory what you actually run, clone it to a staging environment that matches production, lower your DNS TTL well ahead of the move, and move the data last. Done in that order, the switch itself takes minutes and nobody outside your team notices.

Start with an inventory, not a backup

A backup captures files and a database. It does not capture the environment those files were living in, and the environment is where migrations break. Before you touch anything, write a single document that lists every moving part.

• DNS: export the full zone file, including MX, TXT (SPF, DKIM, DMARC), CAA and any verification records for third-party tools.
• Runtime: exact language version, extensions and modules, memory limits, upload limits, timezone and locale settings.
• Certificates: who issues them, how they renew, and whether renewal depends on a file challenge that the new host will need to serve.
• Scheduled work: cron jobs, queue workers, backup jobs, report emails. These are invisible until the day they stop running.
• Outbound and inbound integrations: payment gateways, ERP or CRM connections, webhooks and APIs. Note every service that allowlists your current server IP address.
• Secrets: environment variables, API keys, SMTP credentials, and where each one is stored.
• Edge configuration: CDN rules, WAF rules, redirects, custom headers, caching behaviour, rate limits.
• Observability: uptime monitors, log destinations, analytics and tag manager containers.

The IP allowlist item is the one that quietly turns a clean cutover into a Tuesday-afternoon incident. A payment processor or a bank feed that only accepts traffic from your old server address will fail the moment traffic moves, often without an obvious error on your side. Ask every vendor for the change process now, because some of them take days to action it.

Clone to staging and prove the clone works

Build the new environment and restore a full copy of production into it, matching runtime versions exactly. Resist the temptation to upgrade the platform and change hosts in the same step. One variable at a time makes failure legible; two variables at once makes it a guessing game.

Protect the staging clone with HTTP authentication rather than a robots.txt rule, so there is no chance of it being indexed or of a stray link leaking. Then test the things a smoke test misses:

• Submit every form and confirm the notification email arrives, passes SPF and DKIM, and does not land in spam.
• Run a checkout or booking end to end against a sandbox account.
• Trigger each cron job manually and read the output.
• Log in as each user role, including the admin roles nobody uses until quarter end.
• Crawl the old site and the staging clone, then compare the two lists of URLs and status codes. Anything that changed from 200 to 404 or 301 is a finding.

Take a performance reading on staging under the same conditions you will measure later. If the new stack is slower, you want to know before the move, not from a customer.

Plan DNS around TTL, not around hope

Time to live is the number of seconds a resolver is allowed to cache your record. If your A record has a 24-hour TTL and you change it at noon, some resolvers will keep serving the old address until noon tomorrow. That is the window in which two servers are live at once, which is why the database has to be handled carefully.

The working rule is simple: the worst-case split-brain window is the TTL that was in force before you changed it. So lower the TTL at least one full old TTL period ahead, let the old value expire everywhere, and only then plan the cutover. Nameserver changes at the registrar are a different animal: delegation records are cached by TLD servers on their own schedule, typically a day or two, and you cannot shorten that. Never combine a nameserver change with a hosting move.

Move the data last

Split your data into two categories: things that change slowly and things that change constantly. Media libraries, uploads and static assets are slow. Copy them days in advance with a tool that supports incremental transfer, then run a short delta sync at cutover so only recent files move.

The database is the constant one, and it is the reason you need a write freeze. Measure the freeze on staging: dump, transfer, import, verify, and time each stage. Add a buffer of roughly half again to allow for a larger production dataset and a stressed operator. That number is your maintenance window, and it is usually far shorter than people fear.

Four database issues cause a disproportionate share of migration surprises. Absolute URLs stored in content or settings need a search and replace that understands serialised data, or you will corrupt the rows you touch. Character set and collation mismatches between the old and new servers quietly mangle accented characters and emoji. Auto-increment counters can be reset by a partial dump, which lets new rows collide with old identifiers. And database users and grants do not travel with the data, so you have to recreate them on the new server.

The safest migration is a boring one. By the time you change DNS, the new environment has already been serving the real site to your own team for a week.

Run the cutover in order

Give the window a single owner who reads the steps aloud and a second person who verifies each one. Follow the sequence:

1. Put the old site into read-only or maintenance mode and announce it internally.
2. Run the final media delta sync.
3. Dump the production database, transfer it, import it into the new environment, and run your search and replace.
4. Smoke test the new environment using a hosts file entry, so you are testing the new server by its real domain before any public DNS changes.
5. Change the A, AAAA or CNAME records that point at the old host.
6. Confirm the certificate is valid on the live domain and that HTTPS redirects behave.
7. Leave the old site running and read-only, pointing at a copy of the database, until the low TTL has expired everywhere. It is your rollback.
8. Work the verification checklist below, then tell the wider team the move is done.

Decide the rollback trigger before the window opens, not during it. Something like: if checkout, login or mail delivery is broken and not fixed within 30 minutes, we revert the DNS record. Name the person allowed to make that call. Because you lowered the TTL, a revert reaches most users within about five minutes, which is exactly why the TTL work matters.

Verify, then keep watching

A page that loads is not a successful migration. Work through the same checklist every time: homepage and top landing pages return 200; forms send and the notification arrives; login and checkout complete; the sitemap and robots file are correct and not blocking; redirects from the old URL structure still resolve; the certificate chain is complete; email authentication records still pass; scheduled jobs have run at least once; analytics and conversion tracking are firing; and error logs are quiet.

Then keep watching for two weeks. Compare server error rates and response times against your pre-move readings. Check search console for new crawl errors and for a coverage report that suddenly excludes pages. Watch for bounced transactional email, which is the classic delayed failure after an IP change. Keep the old environment alive and read-only for at least a fortnight, then decommission it deliberately, after you have exported its final backup and revoked its credentials. Security and access questions around the old server deserve the same care as the new one, which is why we cover them under security and compliance.

How OlDevs helps

OlDevs has been building and moving production systems from Vancouver since 2014, and we run migrations the same way we run builds: one accountable team, a working demo every week, and clients who own all code, designs, accounts and IP at the end. A typical engagement starts with the inventory above, then a staging clone you can use yourself, then a scheduled cutover with a written rollback plan and a person on call. We handle the parts that are easy to underestimate, including cloud and hosting infrastructure, platform upgrades bundled sensibly rather than all at once, and the front-end and content work that often needs attention once the new environment is in place. Accessibility to WCAG 2.2 AA and bilingual EN and FR delivery are part of how we work, not add-ons.

If you have a hosting move coming up and want a second set of eyes on the plan, or you would rather hand the whole window to a team that does this regularly, request a quote. We reply to every enquiry within one business day.