Server migrations rarely go wrong during the file copy. They go wrong around it: a TTL of 86,400 seconds that nobody lowered, a cron job that quietly stopped running, a certificate that will not renew. "No downtime" does not mean "no work." It means your visitors never see an error page, and the real interruption is a few minutes outside peak hours for the final write sync.
What "No Downtime" Actually Means
Three terms to settle before you touch the server. RTO is how long the service can be down: for a planned migration, the target is zero visible minutes for reads and a few minutes for writes. RPO is what you accept losing if the cutover fails — seconds with continuous sync, up to a full day with a single copy from the night before. The window is the announced slot, outside peak hours, when you are allowed to interrupt service.
A brochure site and an online store do not carry the same risk. On a brochure site, a 2 p.m. cutover goes unnoticed. On a store, every order placed during the cutover is an order someone reconciles by hand. Pick the window against traffic, not against your calendar.
Inventory: The List That Prevents Surprises
Inventory is the boring step that decides everything after it. A server that has been running for two years always holds something nobody remembers: a subdomain pointing at the old IP, a certificate pasted in by hand, a webhook registered with a vendor. List before you copy.
- Sites and virtual hosts — domains, subdomains, document roots, application configuration.
- Databases — engine, exact version, size, character set, accounts and grants.
- Scheduled jobs — system cron and application cron, with the user they run as: the quietest failure of all.
- The full DNS zone — A and AAAA, but also MX, SPF, DKIM, DMARC, CAA and third-party verification records.
- TLS certificates — which are issued automatically, which were installed by hand, and when each one expires.
- Secrets and integrations — API keys, SMTP accounts, outbound webhooks, IP addresses allowlisted at a partner.
- Volume — files, database, logs, and disk space actually in use.
The inventory earns its keep twice: to size the target, then as the checklist on cutover night. Add a "who was told" column.
Stage the Target Host, Then Rehearse
Order the new machine with headroom: a migration is the worst time to discover that 2 GB of RAM is not enough. All five NVMe plans below share the same foundation — KVM, one dedicated IPv4, unlimited bandwidth, root access, a management panel with web console, reboot, reinstall and DNS, automatic backups, a firewall with DDoS protection, 24/7 monitoring, support 6 days a week, and a 99.9% SLA on infrastructure — and differ only in resources. Delivery is quoted at under fifteen minutes.
| Plan | vCPU | RAM | NVMe | USD / month | MAD / month excl. VAT |
|---|---|---|---|---|---|
| VPS-1G Démarrage | 1 | 1 GB | 30 GB | $9.99 | 94.48 |
| VPS-2G Business | 1 | 2 GB | 40 GB | $19.99 | 189.06 |
| VPS-3G Performance | 2 | 3 GB | 50 GB | $34.99 | 330.93 |
| VPS-4G Avancé | 2 | 4 GB | 80 GB | $39.99 | 378.22 |
| VPS-5G Ultra | 3 | 5 GB | 100 GB | $49.99 | 472.80 |
Size on numbers, not instinct: peak memory in use, average CPU load, disk space consumed. A machine sitting at 3.5 GB of 4 GB does not automatically need the next plan; it needs to know what is consuming. Current pricing and the NVMe VPS specifications are online.
Three Passes Beat One
The first pass installs the stack and fixes version gaps: a database a major version behind, a missing extension, a module built against another kernel. The second serves the site on a password-protected test name, to confirm pages, forms and checkout respond. The third is the dress rehearsal: that is where you learn the copy takes twenty minutes, not five.
The Expensive Detail: Writes
Copying a database while it takes writes produces an inconsistent copy. A logical dump with a consistent snapshot is enough for a content site; as soon as a single order can be lost, continuous replication with a cutover measured in seconds is worth the extra work.
DNS, Cutover, and Rollback
DNS is the one piece you do not fully control: every resolver caches the answer for as long as the TTL allows. At 86,400 seconds, part of your audience still reaches the old machine a full day after the switch.
Lower the TTL Early, Never During
The night before — ideally forty-eight hours ahead — drop the records involved to 300 seconds and confirm propagation has finished. The IP change then propagates in five minutes instead of twenty-four hours. Do not touch MX, SPF or DKIM on the same day: if mail starts bouncing, you will not know whether the cause is DNS, the server, or the reputation of the new IP.
Cutover Day, in Order
- Freeze changes — tell users, and switch the site to read-only if the application allows it.
- Final sync — files, media, database. Time it: that is your real window.
- Stop the old service — web server and cron on the old machine, so you never have two writers.
- Repoint DNS — every record involved, in a single pass.
- Verify on the new host — key pages, forms, login, cart, outgoing mail, HTTPS redirects.
- Unfreeze and watch — re-enable writes and keep the logs open for an hour.
One detail that catches people out: the TLS certificate. If issuance was automatic, the ACME client has to be reinstalled and tested on the new host, or renewal will fail ninety days later, silently. That is why the old server stays powered off rather than destroyed.
A Rollback You Decide in Advance
A rollback plan is only useful with a numeric trigger: if a critical function — checkout, login, quote generation — is not working forty-five minutes after the DNS change, repoint to the old IP, still intact, and analyze the next morning. Repointing takes five minutes because the TTL was lowered, which is exactly why you lower it. The worst outcome is not a rollback; it is debugging at 2 a.m. with no fallback.
The First 48 Hours
The migration is not finished when the site answers. For two days, check six things: error logs, whether scheduled jobs actually ran, outbound mail deliverability, certificate renewal, one restored backup, and response times measured from outside. Distance matters: under 5 ms round trip from New York, 10 to 20 ms from Montreal. The Rabat datacenter is announced, not open: production is in New York.
FAQ
Can a migration be completely seamless?
For a read-only site, yes: both machines serve the same content and the DNS switch goes through cleanly. With writes — orders, forms, bookings — you need a final sync, so a window of a few minutes. The honest goal is an outage the visitor never sees, not zero seconds.
How Long Should It Take?
Duration follows data volume and the number of integrations, not the number of pages. A week is a normal rhythm: inventory, test replica, rehearsal, cutover. VPS delivery is quoted at under fifteen minutes, so the target host is never the bottleneck.
Should the Old Server Stay Online?
Keep it for a few days, powered off but intact: it holds the exact pre-migration state, which beats a backup nobody has tested. Destroy it only after a restore verified from the new machine.
What About Cron Jobs and Certificates?
They are the two most common oversights. Each job must be recreated under the right user and run by hand once; each certificate must be reissued on the new host, then its automatic renewal verified. An expiry ninety days out is invisible on cutover night.
Conclusion: The Migration Is Won Before Cutover Day
A clean cutover rests on three things: an honest inventory, a TTL lowered early, and a rollback decided in advance. The rest is execution. If the inventory is missing, start there — it is also the list that tells you which plan to order, and it keeps you from paying for capacity you never use. Plans and prices are on the Open Vista NVMe VPS page, with online ordering and delivery quoted at under fifteen minutes.