Server hosting migration: avoiding downtime and data loss
Four hours of downtime can mean several thousand euros in lost revenue for an SMB or mid-market company. Here's how to switch servers without ever interrupting the service.
- A TTL lowered to 5-10 minutes makes the DNS switchover almost instant
- Continuous replication before go-live day guarantees a new server that is up to date to the minute
- An identical staging environment avoids discovering bugs in production
- A prepared rollback lets you revert to the old server in under 5 minutes if there's a problem
Why downtime is expensive for SMBs and mid-market companies
Every minute of downtime has a real cost: visitors head to your competitors, orders in progress are lost, form submissions don't come through. Prolonged downtime also damages trust: a visitor who sees an error starts doubting the company's stability. Google also penalizes unavailable sites by temporarily lowering their ranking, which prolongs the negative effect even after things are back to normal.
Strategy 1: DNS switchover with a lowered TTL
One to two weeks before the migration, lower the TTL to 5-10 minutes. Wait two days for all the DNS servers worldwide to register it. On migration day, change the A record: propagation becomes almost instant, reducing the practical downtime window to a few minutes. Restore a normal TTL a few hours after the switchover.
Strategy 2: multi-layered replication before the switchover
A fast DNS switchover is useless without an up-to-date copy of the data. Combine three layers: automated daily backups, a full server snapshot three days before the switchover, and continuous replication of the database and files to the new server during the preceding days. A few hours before the switchover, the new server becomes an almost perfect replica, lagging by less than a minute.
Strategy 3: an intermediate testing environment
Duplicate the entire site onto an identical test server, with a temporary subdomain. Test the speed, the forms, database access, browser compatibility, the redirects and the SSL certificates. For a complex application, run full regression tests on the critical user flows before considering the switchover.
Go-live day: execution and real-time monitoring
Schedule the switchover for an off-peak hour. Stop non-critical processes, run one last backup, and check that replication is up to date. Change the A record, wait two minutes, then test in a private browsing window. Actively monitor the site for at least 48 hours with a monitoring tool; keep the old server running for a week before decommissioning it, so a rollback in under 5 minutes remains possible in the event of a critical problem.
This level of preparation is part of every website creation and redesign project, for a switchover that carries no risk to your business.
Common pitfalls to avoid
Generate 404s and duplicate crawling between the old and new site.
A large database can take hours to copy in full.
Don't upgrade PHP or MySQL on the very day of the migration.
Keep it running for at least a week after the migration.
Frequently asked questions
How long should I keep the old server running?+
At least a week, to allow a fast rollback if a problem is discovered late.
Is a rollback really fast?+
Yes, in under 5 minutes if the old server stays active and the TTL is still short.
What time should I schedule the migration?+
At the quietest hour of your traffic, often at night or on a Sunday morning.