A hosting migration can minimise downtime when the old service stays available while the new service is copied, tested and prepared for cutover. The safest process includes an inventory, an independent backup, a tested destination, a final data sync, a controlled DNS change, monitoring and a documented rollback path. No responsible provider can guarantee zero downtime for every site.
What changed in this guide?
- September 2026: The process now includes a final database and uploaded-file sync for changing websites.
- September 2026: DNS, email, SSL, scheduled tasks and rollback checks were separated into explicit steps.
What should you collect before a hosting migration?
Start with a complete inventory of the website and every service attached to its domain. A migration can copy the website correctly and still break email, scheduled tasks or third-party integrations if the inventory covers only files and a database.
- Website files, databases and application configuration
- Current PHP, Node.js, Python, database and web-server versions
- DNS records, including A, AAAA, CNAME, MX, TXT, CAA and verification records
- SPF, DKIM and DMARC records used by business email
- SSL/TLS certificates and the plan for issuing certificates on the new host
- Scheduled tasks, queues, webhooks and external API allowlists
- File uploads, object storage, caches and user sessions
- Current traffic patterns and a low-risk cutover window
How do you migrate hosting with minimal downtime?
1. Create and verify an independent backup
Create a backup that is independent of both the old and new hosting environments. Record how to restore the files and database, then test the restore process where practical. A backup that has never been restored is not a proven rollback.
2. Prepare the destination before changing DNS
Build the new environment while the existing website continues serving visitors. Match supported runtime versions, create databases, configure environment variables, install application dependencies, set file permissions, and prepare SSL/TLS issuance.
3. Copy the first version of the site
Copy the website files and database to the destination without sending public traffic there yet. Large sites may need an initial bulk copy followed by smaller incremental copies closer to cutover.
4. Test the destination privately
Test the new website before DNS changes by using a temporary hostname or a local hosts-file entry. Check public pages, login, forms, checkout, media, redirects, APIs, scheduled tasks, error logs and mobile layouts. Verify that the production domain will receive a valid certificate when traffic switches.
5. Lower DNS TTL in advance
Lower the TTL on records that will change before the migration window, ideally at least one existing TTL period in advance. A lower TTL can shorten how long compliant resolvers cache the old answer, but it cannot force every resolver or device to refresh immediately.
6. Perform a final data sync
Dynamic websites need a final sync immediately before cutover. Put a store or membership site into a short maintenance or read-only window, or use tested replication, so orders, accounts, uploads and form submissions are not split between two databases. Copy changed files and the final database state to the new host.
7. Change only the required DNS records
Update the website-routing records without replacing unrelated mail and verification records. Check A, AAAA and CNAME records for the website. Preserve MX, SPF, DKIM, DMARC and service-verification records unless the related service is also moving.
8. Monitor both environments and keep rollback available
Keep the old environment available during a defined observation window. Monitor HTTP errors, application logs, database errors, forms, checkout, authentication, email delivery and external integrations. Roll back the DNS change if a material issue cannot be corrected safely during the window.
What commonly causes downtime during a migration?
| Failure | Why it happens | Control |
|---|---|---|
| Missing recent data | The first database copy becomes stale while the old site remains writable | Run a final sync or short write freeze |
| Certificate warning | The destination cannot issue or serve a certificate for the production hostname | Prepare and verify the SSL/TLS path before cutover |
| Email stops | MX or sender-authentication records are replaced during a website-only move | Preserve MX, SPF, DKIM and DMARC records |
| Some visitors reach the old site | Resolvers still cache the earlier DNS answer | Lower TTL in advance and keep both environments available |
| Background work fails | Cron jobs, queues, webhooks or allowlists were not inventoried | Test every non-page dependency |
| No safe rollback | The old host was cancelled too early | Retain the old service until validation is complete |
How long does a hosting migration take?
A small static website may be prepared in a few hours, while a busy store or custom application may need several days of planning, testing and observation. The transfer time depends on data size, available bandwidth, runtime differences, DNS control, certificate readiness, application complexity and how often data changes.
DNS does not have one universal propagation time. Cached answers expire according to their TTL and resolver behaviour. The migration plan should therefore define readiness and rollback criteria instead of promising that all traffic will switch at a fixed hour.
What should be tested after the DNS change?
- Homepage, important landing pages and redirects
- Admin login, customer login and password reset
- Forms, transactional email, checkout and payment webhooks
- Database writes, file uploads and object storage
- Scheduled tasks, background workers and queues
- SSL/TLS certificate, HTTP-to-HTTPS redirects and security headers
- DNS answers from more than one resolver
- Error rate, latency and server resource use
Frequently asked questions
Can a hosting migration guarantee zero downtime?
No. Careful preparation can reduce disruption, but DNS caching, application writes, third-party systems and unexpected compatibility issues prevent a universal zero-downtime guarantee.
Should the old hosting service be cancelled immediately?
No. Keep the old environment available until the new site has passed functional checks and remained stable through the agreed observation window.
Does lowering TTL guarantee instant DNS propagation?
No. Lower TTL reduces the requested cache lifetime for compliant resolvers, but it cannot force all networks and devices to refresh at the same moment.
How do you avoid losing orders during migration?
Use tested database replication or a short maintenance/read-only window, then perform a final database and uploaded-file sync before the DNS cutover.
Can The Cloud Market help plan a migration?
Yes. Current managed-hosting plans publish their included migration allowances. The team first reviews the existing host, sites, mailboxes, DNS and SSL, then agrees on the cutover and fallback plan before changes are made.
Sources checked 26 September 2026: The Cloud Market managed-hosting plans and migration allowances, Cloudflare DNS TTL documentation, and Google Workspace email-authentication guidance.