"Zero downtime" is a claim about your database, not about your files. Copying a web root to a new machine is trivial and always has been. The hard part is that the old database keeps accepting writes while you are copying it, and every one of those writes is an order, a comment or a signup that has to exist on the other side.
Everything else — DNS, TLS, cron, mail — is a checklist. This is the checklist, in the order the clock imposes, plus the part most guides omit: since September 2025 there is EU law about what your current provider has to do for you while you leave.
You cannot migrate server without downtime in the sense of zero seconds. You can get it down to the length of one database switchover, which for most sites is under a minute, and you can make that minute uneventful.
Two weeks out: lower the TTL
DNS records carry a time-to-live. A resolver that fetched your A record is entitled to keep serving it for the full TTL, and many will. If your TTL is 86,400 seconds, part of the internet will keep sending traffic to the old IP for a day after you change it.
So the first action is not a migration action at all: drop the TTL to 300 seconds, and do it at least one old-TTL period before the cutover. If the TTL is currently 24 hours, lowering it today means resolvers pick up the short TTL sometime in the next 24 hours, and only then are you free to move quickly. Lowering the TTL on the morning of the migration achieves nothing.
Raise it back afterwards, a day or two after the move, once traffic has settled.
If DNS is unfamiliar territory, what a DNS server is and setting DNS nameservers cover the mechanics.
What the EU Data Act now requires of your old provider
This is the part that changed, and most migration guides predate it.
Regulation (EU) 2023/2854 — the Data Act — applies from 12 September 2025. Chapter VI, "Switching between data processing services", covers Articles 23 to 31 and binds providers of data processing services offering customers in the EU.
The provisions worth knowing before you open a ticket with your current host:
| Provision | What it says |
|---|---|
| Art. 25(2)(d) | A maximum notice period for starting the switch that "shall not exceed two months" |
| Art. 25(2)(a) | A "mandatory maximum transitional period of 30 calendar days" during which the contract still applies and the provider must give reasonable assistance, maintain business continuity and keep data secure in transit |
| Art. 25(2)(g) | A data retrieval period of "at least 30 calendar days" after the transitional period ends |
| Art. 29(2) | Between 11 January 2024 and 12 January 2027, only reduced switching charges, capped at the provider's directly incurred costs |
| Art. 29(1) | From 12 January 2027, no switching charges at all |
Two practical consequences. Your old provider owes you assistance during the transition, not silence. And if you are being quoted a large egress or exit fee today, Article 29 caps it at their actual cost — and removes it entirely from 12 January 2027.
Move the files, then move them again
Copy while the old server is live. It does not have to be consistent yet.
Use rsync over SSH, which resumes and only sends differences — transferring files with rsync over SSH covers the invocation, and excluding files and directories matters more than it sounds: caches, logs and session directories are large, worthless and will slow the pass that has to be fast.
Run it at least twice. The first pass moves everything and takes as long as it takes. The second pass, immediately before cutover, moves only what changed since — typically seconds.
How long the first pass takes is a port question, not a disk question. Two terabytes is 16,000 gigabits, so on a 1 Gbps link it needs 16,000 seconds at theoretical line rate: about four and a half hours, in practice longer. The arithmetic is worked through in how much bandwidth a server needs.
The database is the only genuinely hard part
Two approaches, and the choice is about how long you can stop writes.
Read-only window. Put the application into maintenance mode, dump, transfer, import, switch. Simple, easy to reason about, and the downtime equals the dump-plus-import time — minutes for a small database, hours for a large one. Fine for a 2 GB store at 04:00. Not fine for 200 GB.
Replication. Set the new server up as a replica of the old one and let it catch up over hours or days while both run. At cutover you stop writes for a few seconds, confirm the replica has caught up, promote it, and point the application at it. This is what "zero downtime" actually means in practice: seconds, not zero.
Replication is more setup and much less risk on a large database. Rehearse the promotion on a copy before you do it for real.
The cutover
| Step | Typical duration |
|---|---|
| Announce a maintenance window (even if you do not use it) | — |
| Final rsync pass | seconds to minutes |
| Stop writes: maintenance mode, or read-only | |
| Confirm replica caught up, or run final dump and import | seconds to minutes |
| Promote the new database, point the application at it | seconds |
| Smoke test on the new server by IP or hosts file | 2–5 minutes |
| Change the DNS A record | propagation bounded by the 300s TTL |
| Re-enable writes | — |
| Watch logs on both machines for 24 hours | — |
Test before DNS, not after. Overriding your own hosts file to hit the new IP lets you exercise checkout, login and mail on the new machine while the world is still on the old one. If something is wrong, nobody found out.
What actually goes wrong
- Cron running in both places. The single most common way a migration sends duplicate invoices. Disable cron on the new server until cutover, and disable it on the old one immediately after.
- Hardcoded IPs. In application config, firewall rules, database grants, payment gateway allowlists and API whitelists at third parties. Grep the codebase; then grep the vendor dashboards.
- Mail. SPF records list sending IPs. A new IP that is not in SPF means order confirmations go to spam on day one. Update SPF before the move, listing both.
- TLS. Issue and install the certificate on the new server in advance. If you use Let's Encrypt with HTTP-01 validation, the renewal will fail until DNS points at the new machine — know that, and do not let it surprise you at renewal time.
- Sessions. Logged-in users on file-backed sessions get logged out. Harmless for a blog, a real problem mid-checkout. Move sessions to the database or a shared store first, or migrate at your quietest hour.
- The old server, deleted too early. Keep it running, and keep a backup of it, for at least a week. Article 25(2)(g) gives you a 30-day retrieval window; use it rather than racing to cancel.
Before and after
Take a full backup before you touch anything, and confirm you can restore it somewhere else. A backup you have never restored is a hypothesis. Off-site copies and how to size them are covered in offsite backup storage for servers, and NexonHost backup storage starts at €5 per TB a month as of September 2026.
If you would rather not run the cutover yourself, that is what infrastructure management is for — and the trade-offs of handing it over are set out in managed vs unmanaged server hosting. The destination hardware, if you are still choosing it, is on the dedicated servers page: Intel Xeon builds provision automatically in minutes, AMD EPYC builds carry a two-week estimated delivery, so order before you plan the window rather than after.
Sources
- Regulation (EU) 2023/2854 (Data Act), EUR-Lex. Articles 23–31 and Article 50. Retrieved 21 September 2026.
- NexonHost dedicated servers — provisioning and delivery estimates. Retrieved 21 September 2026.
- NexonHost backup storage pricing. Retrieved 21 September 2026.
