You can migrate your hosting without downtime by following one key principle: replicate all your files and databases on the destination server before changing your DNS, then make the switch in minutes.
Most migrations fail because people point the domain to the new host before everything is ready. This guide shows you a proven, safe workflow to avoid that mistake entirely.
Why Downtime Happens (and How to Prevent It)
Downtime during a migration occurs when DNS already points to the new server but files or the database are incomplete. Visitors arrive to a broken site or a blank screen.
The solution is simple: keep the origin server fully active and functional until the destination server is 100% operational and verified. Only then do you flip the DNS.
Step 1: Prepare the New Hosting Before Touching DNS
This is the most important step. The new server must be completely ready before you change anything on your domain.
- Create the destination hosting account with the same plan or better than your current one.
- Copy all files via FTP/SFTP or the file manager. Include hidden files like
.htaccessand.env. - Export the database from phpMyAdmin or with
mysqldumpand import it on the new server. - Update the configuration file (e.g.,
wp-config.php) with the new database credentials.
Step 2: Test the Site on the New Server Without Changing DNS
Before touching DNS, verify the site works correctly on the destination. You have two main methods:
Method A: Local Hosts File
Edit the /etc/hosts file (Linux/Mac) or C:\Windows\System32\drivers\etc\hosts (Windows) and add a line pointing your domain to the new server's IP. Only you see the new site; the rest of the world still sees the origin.
Method B: Hosting Provider's Temporary URL
Many providers assign a provisional URL like mydomain.hostingprovider.com or a direct IP. Use it to confirm the site loads, forms work, and there are no database errors.
Run through this checklist before proceeding:
- Homepage loads without errors
- Images and static assets display correctly
- Contact forms and checkout work
- Admin area is accessible
- SSL/HTTPS is active on the new server
Step 3: Sync Last-Minute Changes
If your site is dynamic — an online store, active blog, or membership portal — new changes will happen between when you copied the files and when you change DNS: orders, registrations, comments.
To minimize this gap:
- Enable maintenance mode briefly on the origin site just before the DNS cutover. This freezes dynamic content.
- Run a final database export at that moment and import it on the destination.
- If you use WordPress, plugins like WP Migrate DB can sync tables incrementally.
If you need professional help with this synchronization, the team at elenlace.com can handle the full migration without your business losing a single order.
Step 4: Change DNS and Lower the TTL First
Here's the trick almost nobody uses: reduce your DNS records' TTL to 300 seconds (5 minutes) at least 24-48 hours before the cutover. When you change the A record, propagation happens in minutes instead of hours.
| Action | When to Do It |
|---|---|
| Lower TTL to 300s | 24-48 h before cutover |
| Verify site on destination | 1-2 h before cutover |
| Final database sync | 15-30 min before cutover |
| Change A record to new IP | Cutover moment |
| Verify propagation and SSL | Immediately after |
| Restore TTL to 3600s | 24 h later (once stable) |
Use dnschecker.org to verify DNS propagation and confirm that regions around the world are resolving to the new IP.
Common Mistakes That Do Cause Downtime
- Forgetting to copy the
.htaccessfile (causes 404/500 errors on Apache). - Not transferring SSL certificates or not issuing new ones on the destination server before the cutover.
- Canceling the origin hosting before DNS propagation is complete.
- Not updating absolute URLs in the database (a common WordPress issue when changing IP or domain).
Find more infrastructure and performance best practices in the performance category of our blog.
Key Takeaways
- Replicate files and the database on the destination server before changing DNS.
- Test the site from the new server using the local hosts file or the temporary URL.
- Reduce DNS TTL to 300 s at least 24-48 h before the cutover to speed up propagation.
- Run a final database sync right before the cutover and briefly enable maintenance mode.
- Keep the origin hosting active for at least 48 hours after the cutover in case you need to roll back.
Want someone to handle the migration for you without the risk? Contact elenlace.com and our experts will guarantee a migration with zero downtime and no data loss.
FAQ
How long does DNS propagation take when switching hosting?
With a standard TTL of 3600 s it can take up to 24-48 hours worldwide. If you reduce the TTL to 300 s at least 24 hours in advance, propagation happens in 5-10 minutes for most users.
Can I migrate an ecommerce site without losing orders?
Yes. Enable maintenance mode just before the DNS cutover, run a final database export, import it on the new server, then change the DNS. Maintenance mode typically lasts fewer than 15 minutes.
What if something goes wrong after changing DNS?
If the TTL was still low, you can revert the A record to the origin server's IP in minutes. That's why it's critical not to cancel the origin hosting until at least 48 hours after the migration is confirmed stable.
Do I need a plugin to migrate WordPress?
No. You can do it manually with FTP and phpMyAdmin. However, plugins like All-in-One WP Migration or Duplicator simplify the process, especially when rewriting URLs in the database.
Compare providers
Other providers and guides worth comparing:
