A zero-downtime hosting migration means moving a website from one server or hosting provider to another while keeping the live site available to visitors. The safest method is to prepare the new hosting environment before changing traffic, test it privately, synchronize files and databases, then switch traffic only when the destination is ready.
The difficult part is not moving website files. It is keeping changing data synchronized while the old server continues handling visitors. A static website can often be migrated with a straightforward DNS cutover, while an ecommerce store, membership site or other database-driven application may require incremental synchronization, database replication or a carefully controlled write-freeze.
What Is a Zero-Downtime Hosting Migration?
A hosting migration normally involves moving some or all of these components:
- Website files
- Database
- Uploaded media
- Application configuration
- SSL certificate
- DNS records
- Cron jobs
- Background workers
- Email configuration
- Third-party integrations
A zero-downtime migration keeps the existing website operational while the new hosting environment is prepared.
The basic process is:
Live website → new hosting environment → initial migration → testing → final synchronization → traffic switch → monitoring → old host retained for rollback
The exact process depends on how much data changes while the migration is underway.
Why Hosting Migration Can Cause Downtime
There are several potential failure points.
DNS propagation
Changing an A record or nameserver does not instantly redirect every visitor. Different DNS resolvers may continue using cached information for some time.
Database changes
A database copied at 10:00 will not automatically contain an order, registration or article created at 10:05.
File changes
New images, documents and uploads can appear on the old server after the initial migration.
Configuration differences
The new host may use different versions of PHP, databases, web servers, extensions or security settings.
Background processes
Running scheduled jobs on both servers can create duplicate emails, payments, reports or other operations.
The migration therefore needs to address availability and data consistency separately.
1. Audit the Existing Hosting Environment
Before moving anything, document what the website depends on.
Check:
- Hosting account
- Domain registrar
- DNS provider
- Website files
- Database
- CDN
- SSL/TLS
- Cron jobs
- Background workers
- External APIs
- Payment providers
- Analytics
- Backups
- Security tools
This prevents the common mistake of moving the website while overlooking an important dependency.
For example, email may remain with a separate provider and should not be accidentally redirected to the new web host.
2. Create and Verify Backups
Create a complete backup before beginning the migration.
At minimum, consider:
- Website files
- Database
- Uploaded content
- Configuration
- Application-specific data
- Email, if hosted locally
Do not assume that a backup is usable simply because the hosting control panel says it completed.
Where practical, verify that the backup can be opened or restored.
A migration should always have a recovery path if the destination fails.
3. Lower DNS TTL Before the Move
DNS records have a TTL, or Time to Live, that influences how long resolvers cache DNS information.
Reducing the relevant TTL before the migration can reduce the time some visitors continue resolving the old server after the cutover.
A commonly used preparation is a TTL of around 300 seconds, changed in advance rather than immediately before the migration.
However, TTL is not a guaranteed propagation timer. DNS behavior depends on caching and resolver infrastructure.
Do not plan the migration around the assumption that every visitor will switch exactly five minutes after a DNS change.
4. Set Up the New Hosting Account
Build the destination while the current website remains online.
Configure the required:
- Operating system
- Web server
- PHP, Node.js, Python or other runtime
- Database
- Extensions
- Firewall
- File permissions
- Environment variables
- SSL/TLS
- Caching
- Monitoring
Try to reproduce the production environment as closely as practical.
If the new host requires a different software version, test compatibility before the cutover.
5. Migrate the Website Files
Transfer the website files to the new host.
For a CMS, this may include:
- Core files
- Themes
- Plugins
- Media
- Uploads
- Configuration files
- Custom code
The initial copy is not necessarily the final copy.
If visitors or administrators can create files while the old website remains live, those changes need to be synchronized again before traffic moves.
6. Migrate the Database
Export the existing database and import it into the new environment.
Then configure the application to connect to the destination database.
Check:
- Database host
- Database name
- Username
- Password
- Port
- Character set
- Required extensions
Test real database operations rather than simply confirming that the homepage loads.
7. Test the New Website Without Changing DNS
Before moving public traffic, test the destination privately.
Depending on the hosting environment, you might use:
- Temporary hostname
- Staging domain
- Hosts-file override
- Preview URL
- Private routing
Check the functions that matter to actual users:
- Navigation
- Forms
- Login
- Registration
- Search
- File uploads
- Downloads
- Checkout
- Payments
- Email notifications
- API integrations
- Administration
For an ecommerce website, test a transaction workflow rather than only checking the storefront.
8. Compare the Old and New Environments
Look for differences in:
- Software versions
- Database versions
- PHP extensions
- File permissions
- Configuration
- Environment variables
- Redirects
- SSL
- Scheduled tasks
- Application dependencies
A website that visually resembles the old one can still have important infrastructure differences.
9. Plan for Data That Changes During Migration
This is the most important part of zero-downtime hosting migration.
Suppose the initial database copy occurs at 12:00.
Between 12:00 and the final cutover:
- Customers place orders.
- Users register.
- Administrators publish content.
- Customers upload files.
Those changes must reach the new environment.
There are three main approaches.
Short write-freeze
Temporarily prevent database changes while the final synchronization occurs.
This is often the simplest solution for smaller websites.
Database replication
Keep the destination database synchronized with the production database while the migration is underway.
This is more appropriate for high-write applications where even a short write interruption is problematic.
Dual-write architecture
Temporarily write changes to both environments.
This can support sophisticated migrations but introduces considerable complexity around transactions, retries, duplicate data and failures.
It should not be implemented casually.
10. Synchronize Uploaded Files
Databases are not the only source of changing data.
A website may continuously receive:
- Images
- Documents
- Product files
- User uploads
- Generated content
Perform an incremental or final file synchronization immediately before cutover.
For larger applications, shared object storage can allow both environments to access the same files during the transition.
11. Control Cron Jobs and Background Workers
Running both servers simultaneously can create duplicate processes.
For example, both servers might execute a job that:
- Sends invoices
- Processes orders
- Sends emails
- Generates reports
- Processes queues
- Deletes records
Identify all scheduled and background tasks before migration.
During the transition, make sure each task has a clearly defined active environment.
12. Protect Email and DNS
If email is hosted separately, do not accidentally change its MX records.
Before the migration, document:
- A records
- AAAA records
- CNAME records
- MX records
- TXT records
- SPF
- DKIM
- DMARC
- Subdomains
If you are changing only the website’s destination, you may only need to change the relevant web record.
If you are also moving DNS management, the entire DNS zone needs to be recreated correctly.
13. Perform the Final Synchronization
Once testing is complete, prepare the production cutover.
A typical sequence is:
- Confirm the backup.
- Stop nonessential deployments.
- Confirm monitoring.
- Synchronize changed files.
- Synchronize database changes.
- Confirm data consistency.
- Control background jobs.
- Verify the destination.
- Change traffic routing.
- Monitor immediately.
The exact sequence depends on whether the application uses a write-freeze, replication or another synchronization method.
14. Change DNS or Traffic Routing
For a conventional website, this usually means changing the relevant DNS record to point to the new server.
For larger infrastructures, traffic can potentially be shifted gradually using a load balancer, reverse proxy or CDN.
A gradual migration can look like:
100% old → 90/10 → 50/50 → 10/90 → 100% new
This gives the team an opportunity to detect problems before all traffic reaches the new environment.
15. Monitor Immediately After Cutover
Do not consider the migration finished after changing DNS.
Monitor:
- HTTP status codes
- Application errors
- Database errors
- CPU
- Memory
- Disk usage
- Response times
- Traffic
- Login failures
- Checkout failures
- Email delivery
- API errors
- Background jobs
Also test the website from multiple networks where practical.
Different DNS resolvers can switch to the new destination at different times.
16. Keep the Old Host Online
Do not immediately cancel the old hosting account.
Keeping it available provides a rollback option while DNS changes propagate and the new environment is monitored.
For a critical website, the old environment should remain available until you have sufficient confidence that the new environment is functioning correctly.
17. Have a Rollback Plan
Decide in advance what would cause you to return traffic to the old environment.
Potential triggers include:
- Critical application errors
- Broken checkout
- Missing data
- Database corruption
- Failed authentication
- Payment problems
- Major API failures
- Significant email problems
A rollback procedure should be simple enough to execute under pressure.
Zero-Downtime Hosting Migration Checklist
| Stage | What to verify | Why it matters |
|---|---|---|
| Preparation | Architecture, dependencies and backups | Prevents overlooked services and provides recovery |
| New host | Software, database and configuration | Ensures application compatibility |
| Initial migration | Files and database | Creates the destination environment |
| Testing | User journeys and integrations | Finds problems before public traffic moves |
| Synchronization | Recent files and database changes | Prevents stale or missing data |
| Cutover | DNS or traffic routing | Moves visitors to the new host |
| Monitoring | Errors, performance and transactions | Detects problems quickly |
| Rollback period | Old host remains available | Provides a recovery path |
When Zero Downtime Is Not Necessary
Not every website requires a sophisticated migration.
A small informational website with no accounts, transactions or frequently changing content may be safely migrated during a short maintenance window.
In that situation, a simpler process can be preferable:
Backup → transfer → test → brief maintenance → final synchronization → DNS change → verification
The goal is not to eliminate every possible second of interruption regardless of cost.
The goal is to choose a migration process appropriate to the website’s traffic, data, technical architecture and business requirements.
Using a Managed Hosting Migration Service
Managed hosting can simplify parts of the migration process, particularly for common platforms such as WordPress.
For example, SiteGround provides migration tooling for eligible WordPress websites alongside manual migration options. These tools can reduce the amount of manual file and database work, although the destination should still be tested for DNS, email, payments, integrations, scheduled tasks and other application-specific requirements.
If you are evaluating a new host as part of your migration, you can also review the latest SiteGround hosting offers to compare available hosting and migration features.
The Most Important Part of a Zero-Downtime Hosting Migration
A hosting migration succeeds when the new environment is ready before production traffic reaches it.
The safest sequence is therefore straightforward: prepare the destination while the old site remains live, make the new environment behave like production, synchronize changing data, switch traffic deliberately, monitor the result and retain the old environment until rollback is no longer needed.
For a simple website, that may require little more than careful DNS planning and a final file synchronization. For an ecommerce or high-traffic application, maintaining data consistency may require replication or more advanced traffic routing. The right solution is the one that protects both availability and data integrity without introducing unnecessary complexity.