Migrating a website to a new host is one of those jobs most site owners keep putting off, not because it is hard but because of three big fears behind it: the site going down in the middle of a working day, lost email, and a drop in Google rankings. In reality, if you migrate a website to a new host in the right sequence, all three risks disappear. This guide lays out that professional sequence step by step: a full backup, lowering the TTL before anything else, moving files and the database, testing the new host with the hosts file trick, issuing SSL before the DNS change, managing the propagation window, and a post-migration checklist, so that visitors never notice the move.
Why an unplanned host change ends in downtime
Almost every horror story about changing hosts follows the same pattern: someone changed the DNS first and only then thought about everything else. From the moment the domain's record points to the new IP, some users reach a server that has no files yet, no database, or no valid SSL certificate. The result is hours of error pages, certificate warnings in the browser, and orders abandoned halfway through.
The professional sequence is the exact opposite: everything is built, tested and signed off on the new host first; the DNS change is the last step, not the first. In this order, at least one fully healthy server answers for your domain throughout the process, and "downtime" effectively drops out of the equation.
One more point before we start: this guide is about how, not where. If you have not chosen a destination yet, settle two bigger decisions first: Iran hosting vs foreign hosting, based on where your audience is, and shared hosting vs a VPS, based on your project's technical needs. A move to the wrong destination is still a move to the wrong destination, however cleanly it is done.
Step one when you migrate a website to a new host: a full backup
In this process the backup is your insurance policy: if any step goes wrong, you must be able to return to where you started, without debate and without stress. "Full" means all three parts of the site, not just the files:
- Files. The entire site directory, including the core, theme, plugins and, most important of all, the uploads folder. In cPanel the backup tool builds a complete archive; DirectAdmin has a similar option in its backup section. If you have SSH access, a compressed archive of the whole directory is faster and more reliable.
- Database. A full export with phpMyAdmin or the command line. For a WordPress site, the database is every post, user, order and setting; without it, the files are just an empty shell.
- Email. If your mailboxes live on the same host, their contents are part of your assets. Write down the list of addresses, their passwords and the size of each mailbox, and export the important messages; how to move them is covered later in this article.
Follow two golden rules as well. First, keep the backup outside the current host, on your own computer or in separate cloud storage; a backup sitting next to the site goes offline together with the site on the day you need it. Second, open the backup and test it: an archive that will not extract cleanly, or an SQL file cut off halfway, only gives you a false sense of security. We cover the tools and a retention strategy in detail in our Linux backup guide, and the official WordPress documentation has a separate page on backups.
Lower the TTL 24–48 hours before the migration
Every DNS record has a TTL (time to live): how long DNS resolvers across the internet may keep the answer without asking the source again. If the TTL on your site's main record is 24 hours, then after the IP changes some users will keep being sent to the old address for up to a full day, because the stale answer is still valid in the DNS caches along their path.
The fix is simple but takes time: before the migration, lower the TTL of the domain's A and CNAME records to a small value, say 300 seconds, and then wait for as long as the old TTL so that stale answers expire across the network. That is why this step has to happen 24–48 hours before moving day; if you lower the TTL at the moment of the switch, it has practically no effect on that switch. If you are not comfortable with records and TTL, read our guide to DNS records before this step.
Moving files and the database to the new host
Files
On the new host, add the domain without changing its DNS; hosting panels do not need the domain to point at them before they create an account. Then upload the files archive and extract it right there. Transferring one compressed archive always beats uploading files one by one over FTP: it is several times faster, and the risk of missing hidden files such as .htaccess, which the site's redirect rules and permalinks depend on, drops to practically zero.
Database
Create a new database and database user on the new host and import the SQL export. The database name and username will almost always be different on the new host, and forgetting to update these four values (database name, user, password and database host) in the site's configuration file, wp-config.php for WordPress, is the most common cause of an "Error establishing a database connection" page after a migration. If the site's domain is not changing, which is usually the case when you change hosts, you need no search-and-replace inside the database at all. That operation is only for address changes, and running it carelessly on serialized data is a source of breakage in its own right.
Create the same mailboxes, with the same addresses, on the new host. For the old messages you have two options: connect both servers at once in an email client over IMAP and drag the folders from the old account to the new one, or use the panel's own transfer tool if the source and destination belong to the same family. The key point is the authentication records: the new host generates its own DKIM key and needs a different SPF value. You must replace these records with the new values when you change the DNS; otherwise the site's email starts landing in spam folders the day after the migration. We explain how to create and verify these records step by step in our guide to fixing emails that go to spam.
If the source and destination are both cPanel or both DirectAdmin, it is simpler still: a full account backup, with files, database, email and DNS settings together, is restored on the destination and most of the manual steps above disappear. The details are in the cPanel documentation and the DirectAdmin documentation. At Mehran Host, too, the destination of a migration is usually one of these two panels; shared hosting is ordered with an invoice in Iranian currency, and the current list of plans is on our web hosting page.
Test the new host before the DNS change: the hosts file trick
This is the step that separates professionals from everyone else: test the site on the new host under its real address while the rest of the world still sees the old version. The tool is your operating system's hosts file, a local list that is read before any DNS lookup. Pin your domain to the new host's IP in this file, and only your browser goes to the new server:
# Linux / macOS: /etc/hosts (edit with sudo)
# Windows: C:\Windows\System32\drivers\etc\hosts (open the editor as administrator)
203.0.113.10 example.com
203.0.113.10 www.example.comReplace 203.0.113.10 with the new host's IP and example.com with your own domain, then close the browser completely and reopen it so that its DNS cache is cleared. Now browse the site like a demanding visitor: the home page, a few posts, search, the contact form, logging in to the admin area and, if you run a shop, a complete test purchase. Every error you find here is an error no user will ever see. When testing is done, delete those same lines from the hosts file. The exact format of the file and its rules are described in the hosts file documentation on man7.org.
Issue SSL before the switch, not after
A certificate error is the ugliest face of a sloppy migration, because the browser shows it to the user as a full-page warning. The catch is that automatic certificate issuance in most panels depends on the domain already pointing at that server, which has not happened yet while you are testing. You have two clean solutions. Either export the current certificate and its private key from the old host and install them in the new panel, so the same valid certificate answers at the moment of the switch and automatic issuance takes over later; or, if you have server and command-line access, issue a fresh certificate in advance with DNS validation, which does not care where the domain points. We cover the second method in detail in our guide to installing a free SSL certificate with Certbot. Whichever route you take, the test is the same: at the moment of the DNS change, the new server must answer with a valid certificate.
Changing DNS with zero downtime: managing the propagation window
Now that the new host is tested and has its certificate, point the domain's A records (and, where they exist, the www and subdomain records) at the new IP, and replace the MX, SPF and DKIM records with the new host's values. Because you lowered the TTL in advance, most users reach the new server within minutes; but "most" is not "all". Some DNS resolvers hold answers a little longer than they are allowed to, and some users sit behind networks with more stubborn caches. A realistic window for propagation to finish completely is a few hours, a full day at most. If the destination is a VPS and you are moving the domain's nameservers as well, the right order (create the zone before changing the nameservers, then check with dig) is covered in our tutorial on connecting a domain to a VPS.
During this window both servers receive visitors at the same time, and that calls for content planning. If a user who still reaches the old server posts a comment or places an order, that data lands in the old database and will not exist in the new version. The professional solution is a "freeze": from the moment you take the final database export until propagation is over, publish no new content, and if you run a shop, schedule the migration for the quietest hour of the week or pause ordering temporarily with a polite notice. For email, keep the old account open for a few days and check it once more over IMAP; messages that reached the old server during propagation have to be moved to the new mailbox by hand.
Post-migration checklist: SEO, email and forms
The day after the switch, instead of relaxing, work through this list once from top to bottom:
- The SSL certificate: check it from several devices and networks, such as a computer and a phone on mobile data; both the www and the non-www versions must open without a warning.
- Forms and transactional emails: actually try them, including the contact form, password reset and order confirmation. Mail arriving in the inbox rather than the spam folder means the new SPF and DKIM records are in place.
- Dynamic features such as search, the shopping cart, user login and file uploads: test them separately. Errors that depend on PHP settings or server modules usually show themselves here.
- Search Console: watch it for a few days. The page indexing report and crawl errors are the first place where invisible problems, such as pages that fail only for the crawler, come to light.
- Load time: compare it with the old location. If you moved to a better host, this is where it should show.
Now for the SEO worry. The good news is that Google has specific official guidance for moving a site between servers when page URLs do not change, and the only effect it describes as normal is temporary: a short-term dip in crawl rate that recovers within a few days. The golden rule follows from that: do not touch the URL structure. The address of every post, category and image must be exactly the same after the migration as it was before. If for some reason you must change the structure, for example by removing an old prefix from your paths, do not do it together with the migration. Finish and stabilize the server move first; then, as a separate step, implement a complete map of old-to-new URLs with 301 redirects so that each page's authority carries over to its new address. Two big changes at once means that when something breaks, you will not know which one is to blame.
Common host-migration mistakes, and the right way to handle each
The lessons of botched migrations, summed up in one table:
| Common mistake | Consequence | The right way |
|---|---|---|
| Changing DNS before the new host is ready | Real downtime and SSL errors for users | The DNS change is always the last step |
| Backing up only the files | A site with no content, users or orders | Files + database + email, with a test restore |
| Not lowering the TTL 24–48 hours in advance | A long propagation window and a drawn-out two-server period | Lower the TTL to 300 seconds two days before the move |
| Not testing through the hosts file before the switch | Errors discovered after users have already seen them | Test the whole site on the new IP from your own computer |
| Publishing content or taking orders during propagation | Data lost in the old database | Freeze content from the final export until propagation ends |
| Forgetting the MX, SPF and DKIM records | Outgoing mail in spam, incoming mail stranded | Replace the email records with the new host's values |
| Changing the URL structure along with the migration | SEO losses and confusion when tracing the cause | Migrate and stabilize first; change URLs separately with a 301 map |
| Canceling the old host immediately | No way back, and email in transit is lost | Keep the old host for one to two weeks after the move |
If we had to sum up this table in one sentence: do not rush, and do not change the order. For a typical site the whole process is a few hours of actual work spread over two or three days, and that spreading over several days is exactly what makes "zero downtime" possible. If your destination is cPanel or DirectAdmin shared hosting with an invoice in Iranian currency, see the current list of plans on Mehran Host's Iran web hosting page. The service is provisioned automatically once the invoice is paid, so you can prepare the destination account today without touching your current site.
Frequently asked questions
How long does it take to migrate a website to a new host?
For a typical site, plan for two to three days, of which only a few hours are hands-on work: preparing the account, moving the files and database, and testing. The process stretches over several days because the TTL has to be lowered 24–48 hours before the switch, and full propagation after the DNS change takes a few hours to a day. That stretched timeline is the real price of a migration with zero downtime.
Will my website go offline when I change hosts?
No, not if you follow the right order. The key is to make the DNS change the very last step: until then every user sees the healthy old version, and afterwards they reach the new version, already tested and running with a valid certificate. During propagation both servers answer at the same time, so there is never a moment without a ready server; you only need to pause new content and new orders during that window.
What needs to be moved when you migrate WordPress to a new host?
Three things: all the files, including the core, theme, plugins and uploads folder; a full export of the database, which holds the posts, users and settings; and the mailboxes, if they live on the same host. After importing the database on the new host, update the connection details in wp-config.php, the WordPress configuration file. As long as the site's domain stays the same, no search-and-replace inside the database is needed.
Does changing hosts hurt SEO?
No, not by itself. Google's official guidance for moving a site without changing page URLs treats only one temporary effect as normal: a short dip in crawl rate that recovers within a few days. Real damage comes from elsewhere: long downtime during the move, changing the URL structure at the same time without 301 redirects, or a new host that is slower. If the URLs stay the same and the move causes no downtime, all Google sees is a new IP address.
What happens to email on the old host during a migration?
It does not move by itself: you create the same mailboxes with the same addresses on the new host and copy the old messages over IMAP by connecting to both servers at once. Replace the MX, SPF and DKIM records with the new host's values when you change the DNS. Keep the old account open for a few days, because messages that reach the old server during propagation have to be moved to the new mailbox by hand.