You are not happy with your current host. The site is slow, support does not answer, or you have reached a dead end with your previous web designer. But most of the trouble in moving a website to a new host does not come from the move itself. It comes from the fact that, before starting, the site owner does not hold the keys to every door.
This guide has three parts: taking back control, the move itself with as little downtime as possible, and protecting SEO and monitoring after the migration. Whether you do the work yourself or hand it to a new support company, you need to know what to ask for and what to check.
Before anything else: what must be in your own name?
A website is not just a few files on a server. It is a set of accounts, and if any one of them stays with someone else, the migration is left half-done or something quietly stops working. Before you change your website support company, complete this list:
- The domain registrar account and the email address that account is linked to. If the recovery email belongs to your previous designer, the domain is still effectively in their hands.
- The hosting panel (cPanel, DirectAdmin or the host's own panel) and the user account with the hosting company itself.
- DNS management. Sometimes DNS sits on a service such as Cloudflare under someone else's account.
- The database and its access details.
- The source code or code repository for a custom-built site; for WordPress, the licenses for paid themes and plugins and the account they were bought with.
- The site's main administrator account, using your own email.
- Google Search Console and Google Analytics with Owner access, not just user access.
- Business email accounts and their passwords.
- The payment gateway account. Check whose email and mobile number are registered on it.
- The SMS provider account and its API key.
A simple rule: wherever the login uses the designer's email or mobile number, that asset is not yet fully yours.
Taking over the site from your previous designer: politely and in writing
Even if you are unhappy, start with a calm tone; a fight only slows things down. Send the request in writing (email or a messaging app that keeps a record) and include:
- An exact list of the access you need, following the previous section.
- A change of the accounts' recovery email to your own email.
- A complete, dated current backup (files and database).
- The technical details only they know: cron jobs, special server settings, external services connected to the site.
- A reasonable deadline and thanks for their cooperation.
If you have an open balance, settle it first; it is normal for a designer not to hand over code before being paid. After the handover, change every password yourself, remove extra users from the site and the hosting account, and generate new API keys.
If the domain is registered in the previous designer's name
This is the most dangerous situation. As far as the registrar is concerned, the owner of a domain is the person it is registered to, not the person who paid for it. The first step is a written request to transfer domain ownership; if they do not cooperate, your payment records and contract will help. The details, and the clauses that should be in the contract from day one, are in our article on the website design contract. Do not start the migration until domain ownership is settled.
Full backup, test restore and choosing a host
A backup that has never been restored is only a hope. You need two things: a complete copy of the files (including the uploads folder, configuration files such as wp-config.php or .env, and the .htaccess file) and a full export of the database. Keep the backup outside the current host and restore it once in a separate environment to make sure it is sound. See the routine for regular backups in the WordPress maintenance checklist. If you suspect the site is infected, clean it before the move, or you will carry the infection with you (hacked website recovery).
We explain how to choose a host separately in the domain and hosting guide. Three points specific to a migration:
- The PHP and database versions on the new host must be compatible with your current site; note the current versions on the old host.
- If your payment gateway only accepts requests from approved server IPs or locations, ask the payment provider before choosing a new host whether it will accept requests from that host.
- Do not cancel the old host at the same time as you buy the new one; you will need both for a few days.
Copy the files and database, then test before changing DNS
Move the files to the new host, create an empty database, import the export into it and update the connection details in the configuration file. Two things are often missed: the uploads folder must be writable, and the database character encoding (utf8mb4) must be kept, or Arabic and other non-Latin text turns into question marks.
Before a single visitor reaches the new host, look at the site there yourself. The best way is the hosts file: on your own computer you tell the system to send the domain to the new host's IP. That way only you see the site from the new server, on its real domain. The temporary address some hosts provide also works, but WordPress usually redirects you back to the main domain.
Test everything properly: inner pages, search, the contact form, login, the shopping cart and the admin panel. Fix every error here, not after the DNS change.
Lower the TTL in advance, then change DNS
TTL tells DNS servers around the world how long to keep a previous answer. If your TTL is several hours, after the IP changes some users will keep going to the old server for that long. So a day or two before the migration, lower the TTL on the A and www records to a short value such as 300 seconds, and raise it again once things are stable.
Make the change at a low-traffic hour. If you are changing the nameservers instead of the A record, the change usually takes longer to propagate; before doing it, recreate all the records in the new DNS.
Keep the old host alive for a few days
After the DNS change, keep the old host active for at least a few days: some users and mail servers still go to the old address, and if something goes wrong, going back is just one DNS change. If the site takes orders, close ordering on the old copy, or some orders will be saved in the old database and lost.
What usually gets left behind
Once the site is up on the new host, the job is not finished. These five items cause the most trouble.
SSL certificate
An SSL certificate is installed on the server and must be issued or installed on the new host too. A free automatic certificate is usually issued only after DNS points to the new server, so the browser may show a warning for a short time. If you have a paid certificate, get its files from the old host; otherwise ask the new host how to get a certificate before changing DNS.
Email and MX records: the classic forgotten piece
If your business email is on the old host, changing the nameservers can make email stop silently, and sometimes nobody notices for days. Before the migration, find out where your email is hosted; create the mailboxes at the destination and move old messages over with IMAP. Recreate the MX, SPF, DKIM and DMARC records exactly in the new DNS; an incomplete SPF means your email lands in your customer's spam folder. Then test both receiving and sending.
Cron jobs
Scheduled tasks live in the server settings and do not move when you copy files: newsletters, automatic backups, cancelling unpaid orders, inventory sync. Note the list on the old host and recreate them on the new one.
Payment gateway: callback URL and server IP
This can be critical for online stores. Some payment gateways accept transaction verification requests only from your server's registered IP. When the host changes, the IP changes, and a customer may pay while their order is recorded as "failed".
Before the migration, give the new host's IP to the gateway's support team so it is added to the allowed list. If the site address changes, also update the callback URL in the gateway panel. Then make a real purchase for a small amount. Details on gateways are in the payment gateway guide. Some SMS providers also restrict sending to specific IPs.
The site's own emails (SMTP)
Order confirmation, password reset and contact form emails are often sent with the server's own mail function, which may be disabled on the new server. It is better for the site to send through SMTP from a real mailbox; after the migration, test the contact form and password reset.
SEO: if URLs do not change, you do not need redirects
The main worry for most site owners is losing rankings. Changing host on its own changes nothing for Google: the same domain, the same URLs, the same content. In this case, a website migration without losing SEO mostly depends on the site staying healthy during the transition:
- Keep long outages and 500-series errors to a minimum; repeated errors reduce Google's crawling.
- Make sure
robots.txtis the same version as before, and that in WordPress the "Discourage search engines from indexing this site" option is turned off. - Measure the new server's speed and compare Core Web Vitals (for example, LCP within 2.5 seconds) before and after the migration.
If the domain or page URLs change
If you are changing the domain or the URL structure at the same time, every old URL needs a 301 redirect to its new equivalent; we explain how to prepare this map in our article on website redesign. If the domain has changed, once the redirects are in place use the Change of Address tool in Search Console (Google's official guide to site moves) and keep the redirects for a long time. A new domain also means your payment gateway registration, and any legal and trust requirements of your market, must be updated for the new domain.
Our advice: if you can, do not change host and domain at the same time; otherwise, if traffic drops, you will not know which one caused it.
Monitoring after the migration
For the first two weeks, check these regularly:
- Search Console: the pages report for server errors or "not found", and the crawl stats.
- Analytics: any sudden drop in traffic, orders or form submissions, and whether the analytics code still loads.
- Orders and payments: match them against the gateway report; a successful payment with no order means an IP or callback problem.
- Emails and automatic backups on the new host: do they actually work?
When all of this has been healthy for several days in a row, take a final backup from the old host and then cancel it.
Website migration checklist for a new host
Assign an owner to each row, and tick the last column only when the item has actually been tested.
| Step | Who | Checked? |
|---|---|---|
| Owner access to the domain panel and its recovery email | Business owner | ☐ |
| Handover of hosting, DNS, code, licenses, Search Console and Analytics | Business owner + previous designer | ☐ |
| Change every password and remove extra users | Business owner | ☐ |
| Full backup outside the host + test restore | Technical team | ☐ |
| Note the PHP version, cron jobs and DNS records | Technical team | ☐ |
| Register the new IP with the payment gateway and SMS provider | Business owner + technical team | ☐ |
| Lower TTL a day or two before the migration | Technical team | ☐ |
| Full test on the new host using the hosts file | Technical team + business owner | ☐ |
| Prepare SSL and the MX, SPF, DKIM and DMARC records | Technical team | ☐ |
| Change DNS and close ordering on the old host | Technical team | ☐ |
| Test purchase, test the contact form and emails, check robots.txt | Business owner + technical team | ☐ |
| Monitor for the first two weeks, final backup and cancel the old host | Both | ☐ |
Do the migration yourself or hand it over?
For a simple brochure site with no business email and no payment gateway, a migration is doable with this guide and help from the new host's support. But when an online store, a payment gateway, an SMS provider and business email are involved, every piece that gets left behind has a real cost: a lost order or an email that never arrives.
If you want to hand this work over, its scope and cost depend on the size and complexity of the site and should be defined in writing before you start. After the migration, the site also needs regular maintenance; MyTarh's support starts with an initial technical and security review, and the details are on our website care & maintenance services page. We do not promise "zero seconds of downtime" or "guaranteed rankings", because nobody can honestly promise that; what we offer is an orderly process that lowers the risk.
Summary
A website migration does not start in the hosting panel; it starts with taking back control of the domain, the accounts and the code. After that, a backup you have actually restored, testing with the hosts file, a short TTL, keeping the old host alive and paying attention to email, the payment gateway and cron jobs cover most of the risks. If URLs stay the same, SEO usually takes no damage.
Next step: fill in the list from the first section today and see which access is still not in your hands. If you are not sure where to start, book a free 30-minute intro call and we will go over your site's situation together.
Frequently asked questions
How much downtime does moving a website to a new host cause?
If the site has been tested on the new host in advance, the TTL has been lowered and the old host stays on until DNS has fully propagated, most users will not notice any real downtime. In the first few hours, some visitors may still see the old copy. Nobody can guarantee zero downtime, but this process keeps it to a minimum.
Does changing host affect SEO and Google rankings?
If the domain and page URLs stay the same, changing host on its own usually has no negative effect. What does harm rankings is long downtime, server errors, a slower site or accidentally blocking indexing in robots.txt. After the migration, follow the Search Console reports for two weeks so you spot any error early.
My previous designer will not hand over access. What should I do?
First settle any outstanding balance, then send a polite written request with an exact list of the access you need. If the domain is in your own name, you can point DNS to the new host from the domain panel and rebuild the site from a backup. If the domain is in the designer's name, domain ownership comes first, and your payment records and contract will help.
Why does payment go through after the migration but the order is recorded as failed?
The most common cause is that the payment gateway accepts transaction verification requests only from the server's previous IP. Give the new host's IP to the gateway's support team so it is added to the allowed list, and if the site address has changed, correct the callback URL in the gateway panel. Then make a test purchase for a small amount.
When should I cancel the old host?
When the site has run on the new host without errors for several days in a row, emails have arrived in both directions, a test payment has succeeded and the new host's automatic backup has run at least once. Before cancelling, take a complete final backup from the old host and keep it somewhere safe.