Changing hosting provider is one of those jobs that sounds terrifying and turns out to be completely manageable once you follow the right order. The panic usually comes from one fear: the site going dark in the middle of the move. The good news is that you can migrate a website to a new host without downtime if you copy everything first, test it privately, and only switch DNS at the very end.
This guide is written for business owners and marketing managers, not sysadmins. No command line required. Follow the sequence below and your visitors will never see an error page, your emails will keep arriving, and your SSL padlock will stay green.
Why websites go down during a migration (and how to avoid it)
Almost every migration disaster comes from one of these four mistakes:
- Switching DNS before the new server is ready. Visitors get pointed to an empty folder or a default “It works!” page.
- Cancelling the old hosting too early. DNS changes are not instant worldwide, so part of your audience is still being served by the old server for hours or days.
- Forgetting email. Changing nameservers moves your MX records too, and mail starts bouncing while nobody notices.
- Ignoring SSL. A new server needs its own certificate. Without it, browsers throw a full-screen “Not secure” warning.
The fix is a simple principle: run both hosts in parallel. Old host stays live and untouched while the new one is built, tested and secured. DNS is the last domino, not the first.
What you need before you start
- Login to your current hosting control panel (cPanel, Plesk, or a custom dashboard) with FTP/SFTP and database access
- Login to your domain registrar (where the domain was bought, which is not always where it is hosted)
- Login to your new hosting account
- A list of every email account on the domain and their passwords
- A computer with admin rights, so you can edit the hosts file
- A quiet time slot, ideally mid-week, early morning, never a Friday afternoon
The 10-step zero-downtime migration sequence
Step 1: Inventory what you actually have
Write down, in a single document: the CMS and version (WordPress, Joomla, PrestaShop, custom PHP), the PHP version, the database name and size, the total disk usage, every subdomain, every scheduled task (cron jobs), every third party service that pings your server (payment gateways, booking systems, API integrations) and any IP address currently whitelisted somewhere.
Also note your current DNS records. Log into your DNS zone and copy the full list: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC, domain verifications for Google, Microsoft, Facebook). This list is your safety net. Most “the site is back but email broke” incidents are just a missing TXT record.
Step 2: Lower your DNS TTL 48 hours before the move
TTL (Time To Live) tells the internet how long to cache your DNS records. The default is often 14400 seconds (4 hours) or 86400 seconds (24 hours). If you change your IP with a 24 hour TTL, some visitors keep hitting the old server for a full day.
Go into your DNS zone and set the TTL of your A records (and CNAMEs) to 300 seconds (5 minutes). Then wait at least as long as the old TTL value before doing anything else, so the short value propagates everywhere.
| TTL value | Meaning | When to use it |
|---|---|---|
| 86400 | 24 hours | Normal operation, stable site |
| 3600 | 1 hour | One week before a planned migration |
| 300 | 5 minutes | 48 hours before cutover, and during the move |
| 300 to 86400 | Back to normal | One week after a successful migration |
Important nuance: lowering TTL only works if you keep using the same DNS provider and only change the A record. If you plan to change nameservers instead, the old nameservers are cached at the registry level and TTL matters less. That is why we recommend the A record method described in Step 9.
Step 3: Take a full backup of files and database
Never migrate from a live copy alone. Take two backups: one to migrate with, one to archive and never touch.
- Files: connect via FTP/SFTP or use the File Manager, and download the entire web root (usually public_html, www or httpdocs). Include hidden files such as .htaccess. If the site is large, create a .zip or .tar.gz on the server first, then download the single archive: it is far faster and avoids missing files.
- Database: in phpMyAdmin, select your database, click Export, choose the Quick method and SQL format. For databases over roughly 100 MB, use a compressed export or ask your host for a dump.
- Emails: if your mailboxes live on the old server, export or download them, or at minimum make sure they are configured in IMAP so a local copy exists.
Store both backups off-server: your computer plus a cloud drive. A migration without a verified backup is not a migration, it is a gamble. This discussion raises a few points we skipped.
Step 4: Build the site on the new server
On the new host, create the hosting account for your domain, then:
- Upload the files into the new web root and unzip them
- Create a new database and database user, and note the credentials
- Import the .sql file through phpMyAdmin
- Update the configuration file with the new database name, user and password (wp-config.php for WordPress, configuration.php for Joomla, app/etc/env.php for Magento, .env for Laravel)
- Match the PHP version to the old server first. Upgrade PHP after the migration is confirmed stable, not during it.
- Recreate cron jobs and any custom server settings
Many hosts offer a free migration service or a plugin that does this copy for you. Use it if available, but still do Steps 5 to 7 yourself.
Step 5: Recreate email accounts before touching DNS
This is the step everyone skips and everyone regrets. If your email is hosted on the same server as your website, create every mailbox on the new server now, with the same addresses and enough quota. Set up forwarders, aliases and autoresponders identically.
If your email is with a separate provider (Google Workspace, Microsoft 365, or a dedicated mail host), your job is different but just as important: copy your MX, SPF, DKIM and DMARC records exactly and make sure they exist in the new DNS zone before you switch. Changing nameservers without copying MX records is the classic way to lose a day of incoming mail.
Step 6: Test the new server privately with your hosts file
This is the trick that makes zero downtime possible. Your computer’s hosts file lets you resolve your domain to the new server IP while the rest of the world still sees the old one. You browse the real domain name, on the new server, with nothing changed publicly.
Where the hosts file lives
| System | File path | How to edit |
|---|---|---|
| Windows 10 / 11 | C:\Windows\System32\drivers\etc\hosts | Open Notepad as Administrator, then File > Open |
| macOS | /etc/hosts | Terminal: sudo nano /etc/hosts |
| Linux | /etc/hosts | sudo nano /etc/hosts |
What to add
Add two lines at the bottom of the file, replacing the IP with the one your new host gave you:
203.0.113.45 yourdomain.com203.0.113.45 www.yourdomain.com
Save the file, then flush your DNS cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS) and restart your browser. You are now browsing the new server at your real domain name.
What to test while you are in this private preview
- Homepage, 5 to 10 key inner pages, blog archive and a single post
- Contact forms: submit one and confirm it arrives
- E-commerce: add to cart, checkout up to the payment step, test coupon codes
- Login areas: admin panel, customer accounts, member zones
- Images, PDFs, downloads and media uploads
- Search function and filters
- Multilingual versions and redirects
- Any page using an API (maps, booking, live chat, payment)
When you are finished, remove the hosts file lines. Leaving them in place is how people end up debugging a “broken” site that is actually fine for everyone else.
Step 7: Install SSL on the new server before the cutover
SSL is issued per server, not per domain, so the new host needs its own certificate. You have two clean options:
- Pre-issue via DNS validation: most hosts can issue a Let’s Encrypt or commercial certificate using a DNS TXT record, which works even though the domain still points to the old server. This is the smoothest path.
- Issue immediately after cutover: if only HTTP validation is available, the certificate can only be issued once DNS points to the new host. Do it within the first minutes of the switch, and keep the browser tab ready.
Also check that HTTPS redirection and HSTS settings match the old configuration. If the old site forced HTTPS and the new one does not, you create mixed content and redirect loops.
Step 8: Freeze content and do a final sync
A few hours before the switch, stop publishing, stop taking manual orders changes, and tell your team not to touch the site. Then:
- Put the old site in a read-only state if your CMS allows it
- Export the database one final time from the old server
- Re-import it on the new server, overwriting the earlier import
- Re-sync any files uploaded since the first copy (new images, new PDFs, new invoices)
For a busy online shop, this freeze window is the only real “pause” in the whole process, and it should last minutes, not hours.
Step 9: Switch DNS, the right way
You have two options. They are not equal.
| Method | How it works | Downtime risk |
|---|---|---|
| Change the A record only (recommended) | Keep your current DNS provider and nameservers, edit only the A record to the new server IP | Very low. With a 300 second TTL, propagation is usually complete in 5 to 30 minutes, and MX records are untouched |
| Change the nameservers | Point the domain to the new host’s nameservers, which loads a brand new DNS zone | Higher. Ignores your TTL, takes up to 24 to 48 hours, and replaces every record including MX and TXT |
If you must change nameservers (some hosts require it for their control panel to work), then recreate the full DNS zone on the new host first, including MX, SPF, DKIM, DMARC and all verification TXT records, and only then update the nameservers at your registrar. Never switch nameservers into an empty zone.
Make the change, then immediately check propagation with a tool like dnschecker.org or by running nslookup yourdomain.com from a few networks.
Step 10: Keep the old hosting alive for 7 to 14 days
Do not cancel anything yet. During propagation, part of your audience is still served by the old server, so both copies must work. Keeping the old plan for one to two extra weeks costs a few euros and buys you:
- A guaranteed rollback (just point the A record back)
- A safety net for emails that were still delivered to the old mailbox
- Time to discover the one broken page nobody tested
Only cancel once your analytics show all traffic hitting the new server and a full week has passed without an incident. onlineornot.com walks through the specifics.
Pre-migration checklist
| # | Task | Done when |
|---|---|---|
| 1 | Full DNS zone exported and saved as a document | Every A, CNAME, MX and TXT record is written down |
| 2 | TTL lowered to 300 seconds | At least 24 to 48 hours before cutover |
| 3 | Complete file backup downloaded | Archive opens correctly on your computer |
| 4 | Database exported | .sql file is not 0 KB and contains your tables |
| 5 | Files uploaded and database imported on new host | No import errors reported |
| 6 | Config file updated with new DB credentials | Site loads from the new server |
| 7 | PHP version matched | Same major version as the old host |
| 8 | All mailboxes recreated or MX records copied | Count matches the old server exactly |
| 9 | Site tested via hosts file | Forms, checkout and logins all pass |
| 10 | SSL certificate issued or ready to issue | Certificate visible in the new control panel |
| 11 | Cron jobs recreated | Same schedule and commands |
| 12 | Content freeze announced to the team | Everyone confirmed by message |
Post-migration verification checklist
Run this list within the first hour after the DNS change, then again 24 hours later.
In the first hour
- Homepage loads over HTTPS with a valid padlock and no mixed content warning
- www and non-www both resolve and redirect to your preferred version
- Admin login works and you can save a change
- Contact form submits and the message arrives in the inbox
- Send a test email from the domain to an external Gmail or Outlook address, and reply back to confirm two-way delivery
- Check the mail headers of the test message for SPF and DKIM pass results
- E-commerce: complete one real low value test order end to end, including payment notification
- Check the server error log on the new host for 500 errors
- Run a crawl with a free tool to catch broken links, missing images and unexpected 404s
- robots.txt is not blocking crawlers (staging setups often add a Disallow rule, and it can be copied over by mistake)
- Sitemap.xml loads and returns real URLs
Within 24 to 72 hours
- Analytics show normal traffic levels with no sudden drop
- Search Console shows no spike in crawl errors, and the new server responds to the URL Inspection tool
- Page speed is equal or better than before, tested on mobile and desktop
- Scheduled tasks have actually run (newsletters, backups, feed imports, invoice generation)
- Automated backups are configured and have completed at least once on the new host
- SSL auto-renewal is enabled
- TTL raised back to 3600 or 86400 seconds
- Third party services updated if they whitelist your server IP (payment providers, ERP, SMTP relay, CDN, firewall)
- Old hosting cancelled only after all of the above is green
Special cases worth knowing
WordPress specifics
If you also change the domain during the move, never edit URLs by hand in the database: serialised data will break. Use a search and replace tool such as WP-CLI or a dedicated plugin. If the domain stays the same, no URL rewriting is needed at all, which is one more reason to separate “change host” and “change domain” into two distinct projects.
Also disable caching, redirect and security plugins during the test phase, then re-enable and reconfigure them after the cutover. Old cache files pointing to old paths cause most of the post-migration weirdness.
Do you also need to transfer the domain?
No. Your domain and your hosting are two separate services. You can keep the domain at your current registrar forever and simply point it at any host. Transferring the domain adds risk and delay to a migration, so if you want to do it, do it a month before or a month after, never on the same day.
If you do transfer, remember the ICANN rules: a domain cannot be transferred within 60 days of registration or of a previous transfer, and registrant contact changes can also trigger a 60 day lock.
High traffic or e-commerce sites
For shops that take orders around the clock, add two refinements: put the store into maintenance or catalogue-only mode for the final database sync, and check for orders placed on the old server during propagation. Some merchants run a daily export from the old host for the first 48 hours to catch stragglers.
Common mistakes to avoid
- Cancelling the old hosting the same day (you lose your rollback and your files)
- Switching nameservers before recreating MX and TXT records
- Forgetting hidden files such as .htaccess and .env during the file copy
- Leaving the hosts file entries in place after testing
- Upgrading PHP, the CMS and the host all at once, so you cannot tell what broke
- Migrating on a Friday or the day before a campaign launch
- Not testing a real email send and receive after the cutover
FAQ
Can you really migrate a website to a new host without downtime?
Yes. Because both servers can hold a working copy of your site at the same time, the only moment anything changes for visitors is when DNS resolves to the new IP. If the new server is fully tested and both hosts stay active during propagation, nobody sees an error page. The only realistic pause is a short content freeze while you sync the final database.
What is zero downtime migration?
Zero downtime migration means moving a service from one infrastructure to another while it stays continuously available. In web hosting terms, it means building and validating the site on the new server first, running both environments in parallel, and switching traffic over with a short DNS TTL so the transition is measured in minutes rather than hours.
How long does DNS propagation take?
With a TTL of 300 seconds set 48 hours in advance and only an A record change, most visitors see the new server within 5 to 30 minutes, and virtually everyone within a few hours. If you change nameservers instead, expect up to 24 to 48 hours because the change happens at the registry level and ignores your record TTL.
Will changing hosting hurt my SEO?
Not if the URLs, content and redirects stay identical. Google cares about what the page returns, not who serves it. Keep the same URL structure, keep the same HTTPS configuration, avoid a noindex or Disallow left over from staging, and make sure the new server is fast and stable. A faster host usually helps rankings slightly rather than hurting them.
Do I have to move my email too?
Only if your mailboxes are hosted on the same server as your website. If you use Google Workspace, Microsoft 365 or another external mail provider, your email is independent: just make sure the MX, SPF, DKIM and DMARC records are identical in the DNS zone you end up using.
Do I need to buy a new SSL certificate?
Not necessarily. Free Let’s Encrypt certificates are included with most hosting plans and can be issued on the new server in minutes. If you paid for a commercial certificate, it can usually be reinstalled on the new server using the same certificate and private key files.
Can I do this myself or should I get help?
A small brochure site with a handful of pages is realistically a two hour job for a careful non-technical owner. A large e-commerce store, a multisite install, a custom application or a setup with dozens of mailboxes is worth delegating. The cost of a professional migration is almost always lower than the cost of a day of lost orders.
Ready to move?
The whole secret to a migration without downtime is order of operations: copy, test, secure, then switch. Lower your TTL early, back up twice, preview through your hosts file, confirm SSL and email, and keep the old server running as your parachute. Follow the two checklists above and the move becomes a routine maintenance task rather than a stressful gamble. The piece Migrate a Website Without Downtime makes a good next read.
If you would rather have it handled end to end, with the pre-migration and post-migration verification done for you, get in touch with our team and we will plan the cutover around your quietest hours.