The risk in a server migration lies not in the move itself but in starting without a way back. A properly planned migration is measured in minutes of downtime; an unplanned one is measured in hours, because when something breaks there is nowhere to return to.
Short answer: can a server migration be done without downtime?
Yes — downtime can be confined to DNS propagation, and with the right preparation that window shrinks to minutes. Two conditions make this possible: lowering the DNS TTL 24–48 hours beforehand, and fully testing the new server before it receives live traffic. Keeping the old server running for at least a week afterwards also keeps rollback available at any moment.
Pre-migration inventory: what are you actually moving?
- Web files: application code, theme, plugins and user-uploaded files — the most commonly forgotten item.
- Database: including version, character set and collation settings.
- Email: mailboxes, forwarding rules, autoresponders. If the domain moves, MX records are critical.
- DNS records: A, MX, TXT (SPF/DKIM/DMARC), CNAME. Verification records are frequently overlooked.
- SSL certificates: must be reinstalled or reissued on the new server.
- Scheduled tasks (cron): they do not appear on the new server by themselves.
- Configuration: PHP version and settings, .htaccess rules, directory permissions.
- External integrations: payment, shipping, accounting or e-invoicing services — some use IP allow-lists and must be told the new address.
That last point matters especially: changing servers changes your IP. An integration with IP restrictions stops working silently after migration, and this is usually discovered on the first order.
DNS and TTL: the single setting that decides your downtime
The record pointing your domain at a server is cached by DNS resolvers worldwide for a defined period called TTL (Time To Live). If TTL is 14400 seconds (4 hours), some visitors will keep reaching the old server for up to four hours after you switch.
The fix is simple but time-sensitive: 24–48 hours before the move, lower TTL to 300 seconds. Propagation then completes within minutes at cutover. Once everything is verified, TTL can be raised again.
What happens if you skip it? During the switch some visitors reach the old server and some the new one. On a site taking orders, that means orders written into two different databases — the most expensive mistake in a migration.
The 12-step migration plan
| # | Step | When | Critical point |
|---|---|---|---|
| 1 | Build the inventory | T-7 days | List external integrations and IP restrictions |
| 2 | Prepare the new environment | T-5 days | PHP/database versions must be compatible |
| 3 | Take a full backup | T-3 days | Verify it can actually be restored |
| 4 | Copy files and database | T-2 days | First copy; live traffic still on the old server |
| 5 | Lower TTL to 300s | T-2 days | Skipping this stretches downtime into hours |
| 6 | Test on the new server | T-1 day | Test via the real domain using a hosts entry |
| 7 | Install SSL, cron, email | T-1 day | Certificates and scheduled jobs are installed, not moved |
| 8 | Freeze writes | T-0 | Essential for systems taking orders or forms |
| 9 | Final sync | T-0 | Transfer only what changed |
| 10 | Point DNS to the new server | T-0 | The cutover moment |
| 11 | Verify | T+0–2 hours | Use the checklist below |
| 12 | Keep the old server a week | T+7 days | Rollback ability and stray-data checks |
Why a write-freeze window is necessary
Between copying the data and completing DNS propagation, visitors still reaching the old server keep transacting there. Those transactions are lost unless carried over.
On a static brochure site this is not an issue. But on any system with orders, forms, memberships or stock movements the freeze window is mandatory. In practice: schedule the move for a low-traffic hour, display a maintenance notice during it, and keep the window as short as possible.
The rollback plan
- Decision criterion: under what condition do you roll back? (For example: "if the payment flow is not working within 30 minutes".)
- Rollback method: point DNS back to the old IP. With a low TTL this also takes minutes.
- Data reconciliation: how any records created on the new server will be carried back.
This is why the old server stays up for a week. The cost is one week of service; the return is that a migration never becomes a crisis.
Post-migration verification list
- Do the homepage and inner pages load, and are page sizes normal?
- Do forms work and send email? This is the most frequently broken function.
- Has the payment flow been tested end to end?
- Is the SSL certificate valid, and are there mixed-content warnings?
- Do redirects (www/non-www, http→https) behave correctly?
- Has email sending and receiving been tested? Do SPF/DKIM records cover the new IP?
- Are scheduled tasks running?
- Do external integrations accept the new IP?
- Is search engine access open — a blocking rule left over from staging may have travelled with you.
- Has backup been configured on the new server?
That third-from-last item deserves attention: blocking search engines on staging environments is common practice, and when the setting reaches production by accident the site silently disappears from search. The effect is noticed weeks later.
Netişlem expert view: the three mistakes we see most
First, TTL never lowered. Everything else may be technically correct, but with a high TTL the cutover stretches over hours during which two servers are live at once. On sites taking orders, that means lost data.
Second, email forgotten. The site moves, works, everyone relaxes — then outgoing mail starts landing in spam because MX or SPF records were never updated. This surfaces days later, usually through a customer complaint.
Third, shutting the old server down immediately. The old service is cancelled to save cost, and then a small omission noticed afterwards — an unbacked folder, a configuration file — becomes unrecoverable.
What these share is that none is visible at the moment of migration. That is why we recommend running the verification list not once in the first hour but repeatedly throughout the first week.
Frequently asked questions
How long will my site be down during migration?
If TTL was lowered in advance and the new server was tested, downtime is limited to minutes — and on static sites there may be none. Almost the only cause of long outages is skipping DNS preparation.
Will my search rankings be affected?
If URL structure and content stay the same, a correct migration is not expected to harm rankings. Risk comes from three places: prolonged downtime, redirect errors, and a search-engine blocking rule carried over from staging. All three are prevented by the verification list.
Does my email move automatically?
No. Mailbox contents must be transferred separately, and MX and verification records updated. Keeping the old mail server running for a period is recommended so that mail arriving mid-transfer is not lost.
Should I migrate on a weekday or weekend?
What matters is not the day but your lowest-traffic window. It should also be a time when the people who can intervene are reachable — the middle of the night is quiet, but support is thin then too.
Should I migrate myself or use a service?
For a simple static site, migration is manageable. But once databases, email, payment integrations and scheduled tasks are involved, the cost of an error can far exceed the cost of the service. The measure is not technical difficulty but what a failure would cost your business.
Conclusion
The secret to a seamless migration is not working quickly but building a reversible plan. Lower TTL in advance, test before going live, freeze writes, and keep the old server for a week. With those four in place, migration stops being a risk and becomes routine maintenance.
If you would like us to plan and carry out your migration, get in touch. You can also review our free migration support, corporate hosting and managed server solutions.