Migrating to a different hosting provider

Prepare and test the new hosting environment before sending visitors to it. Back up the website, protect existing URLs and search visibility, identify what happens to email and DNS, agree how new orders or enquiries will be handled, and keep the old service available until the move has passed its acceptance checks.

A hosting move can address a resource limit, missing capability or support requirement. It can also introduce problems if the files arrive but the database, mail records or recent transactions do not. Use this checklist to agree the work with your host or developer and record what must be working before you switch.

1. Define why you are moving

Write down the problem you want the move to solve. Examples include repeated resource limits, unsupported software, an unsuitable renewal cost or a maintenance responsibility your business cannot cover. A different hosting provider will not automatically fix an inefficient plugin, a broken form or a slow third-party service.

Check the destination against your requirements

Confirm the software versions, database support, storage, resource allocation and access your site needs. Ask who manages updates, backups and incidents. Our hosting decision guide provides a comparison of the main options.

Compare the full cost and operating scope

Include the renewal price, migration work, licenses, mailbox needs and any overlap between old and new hosting. Ask which custom configurations or repairs are outside the migration service. A clear scope is more useful than a promise to move everything.

Set a measurable outcome

Agree what success means: the required software runs, customer tasks work, recent data is present and the business knows who provides support. If performance is the reason for moving, compare the same pages and tasks under comparable conditions before and after the move. Do not assume that changing hosts will increase traffic or search rankings.

2. Map the website, domain and email

Make an inventory before requesting the transfer. Website hosting, domain registration, authoritative DNS and email can use different providers. Identify the account owner and the approved change for each service.

Component	What to record	What must work after the move
Website and database	Files, uploads, database, software, scheduled jobs and integrations	Representative pages and business tasks use the correct data
Domain registration	Registrar, business owner, renewal and account access	Ownership and renewal stay under the business’s control
DNS	Authoritative provider and the complete current record list	Website, mail and verification records remain correct
Email	Provider, mailboxes, aliases, forwarding and stored messages	Required accounts, message history and send/receive access work
HTTPS and URLs	Hostnames, certificates, redirects and important existing URLs	Valid HTTPS and the expected destinations
Forms and transactions	Delivery addresses, payment services, bookings and incoming data	New enquiries and transactions reach the intended systems

A registrar transfer changes who manages the domain registration; it does not copy website files or mailbox contents. Moving the website often needs only a DNS record change. If email stays with its current provider, preserve the records that support it.

For a move to InterProWebHost, review the current migration policy and obtain an agreed scope. Eligible website migration does not include mailbox migration under that policy. Email accounts, historical messages and any final mailbox synchronization need a separate assessment.

3. Back up and prepare a working preview

Keep a complete backup you can access independently of the old hosting account. For WordPress, this includes both the files and database. Also retain relevant configuration, redirect rules and DNS records. Have the operator demonstrate a restore in an isolated environment before relying on that backup for recovery.

• Confirm who has the required hosting, database, DNS and application access. Share credentials through the provider’s approved secure method.
• Prepare a compatible destination and copy the site using the supported migration process.
• Protect the preview with access controls and prevent indexing. A noindex setting alone does not make a preview private.
• Disable real customer emails, production payments and other actions that a copied site could trigger. Use controlled test integrations.
• Agree how the real hostname and HTTPS will be tested; a temporary preview URL does not prove both will work after the switch.

When the domain and URL structure stay the same, a WordPress move often does not need URL replacement, although database credentials and server configuration may change. If the domain or path changes, use a supported method that handles serialized data and preserves post GUIDs. Avoid a blind database find-and-replace. See the WordPress migration handbook.

4. Test the destination before changing DNS

Choose representative journeys rather than checking only the homepage. Record who tested each one, the expected result and what actually happened. Investigate failures before directing customers to the destination.

• Open key pages, an older article, images and downloads on desktop and mobile.
• Check navigation, search, login and any restricted content with suitable test accounts.
• Submit a controlled form enquiry and confirm it reaches the intended inbox or system.
• Test checkout, booking or membership tasks using the service’s supported test mode; check stock, tax and confirmation behavior where applicable.
• Verify HTTPS, redirects, scheduled tasks and required third-party connections.
• Confirm that backups and monitoring are configured for the destination, with alerts sent to the responsible person.

A migration provider’s basic checks and the business’s acceptance tests serve different purposes. The business or application owner needs to confirm that its own workflows, integrations and data are correct.

5. Protect your SEO rankings during migration

Preserving search visibility starts with keeping valuable pages available at the addresses people and search engines already know. Separate a hosting move from a redesign or content overhaul where possible, so unexpected changes are easier to diagnose. The aim is to reduce avoidable losses; no migration process can guarantee unchanged rankings.

Record a baseline before the move

Save a list of important URLs, including pages receiving organic traffic, enquiries or valuable backlinks. Export clicks, impressions and average position for key pages and queries from the Search Console Performance report, and record the date range. Average position is an aggregate, not a fixed rank for every search. Keep a copy of page titles, descriptions, content, internal links, structured data, canonical settings and existing redirect rules. Confirm that Search Console ownership verification and analytics tracking will survive the transfer.

Keep existing URLs, or map every necessary change

For a hosting-only move, retain the domain, HTTPS hostname and page paths. Transfer existing redirects, but do not introduce new redirects solely because the server changes. Google’s hosting-change guidance explains the checks for a move with unchanged public URLs.

If URLs must change, map each old address to its relevant replacement and use a direct permanent server redirect, normally 301 or 308. Avoid redirect chains and sending unrelated pages to the homepage. Update internal links, canonical URLs and the XML sitemap to the intended destinations. Keep redirects working for at least a year, including after retiring the old hosting. Follow Google’s URL-change migration guidance.

Search Console’s Change of Address tool is for eligible domain or subdomain moves. Do not use it for a hosting-only move, an HTTP-to-HTTPS change, a switch between www and non-www on the same domain, or a path change within the same site.

Check search access at launch and monitor afterward

• Remove temporary production restrictions. Check robots.txt, robots meta tags and X-Robots-Tag headers for unintended crawl blocks or noindex rules. Retain protection for staging and intentionally private pages.
• Inspect representative public URLs. Confirm the intended pages return HTTP 200 with usable content and valid HTTPS. Use Search Console URL Inspection to check Googlebot access; verify that firewall or bot rules do not block legitimate crawling.
• Check canonical and sitemap URLs. Canonicals identify the preferred page address. They should agree with the intended production URLs and internal links, with no temporary preview hostname left behind. Ensure the XML sitemap is accessible and reflects any URL changes.
• Compare before and after. Review equivalent date ranges for search clicks, impressions and average position, plus indexed pages, server logs and organic enquiries. Investigate unexpected 404s, server errors, lost content or tracking failures. Allow for reporting delays and normal fluctuations rather than treating one day’s change as proof of a ranking loss.

Google treats redirects and canonical annotations as signals for choosing the preferred URL; they do not guarantee a ranking. See its canonical URL guidance. Give the technical and SEO owners a shared issue list and an agreed review schedule after launch.

6. Plan the switch around new data

A store can receive orders while its database is being copied. A booking site can accept reservations, and a publishing team can upload content. Decide which environment may accept changes during each stage and how late changes will reach the destination. Complete the DNS and email plan and the rollback plan in the following sections before executing the switch.

1. Choose a change window. Name the operator, the person who authorizes the switch and the person who can stop it.
2. Agree the final copy. A quiet informational site may use an editing pause. A busy application may need a controlled write pause or application-aware synchronization.
3. Record what changed. Reconcile new orders, enquiries, uploads or other records that arrived after the initial copy. A final website copy does not necessarily synchronize mailboxes.
4. Complete the final checks. Confirm the destination has the agreed data and is ready to accept the intended activity.
5. Make the approved DNS change. Monitor both environments while cached records can still send visitors to the old server. Retain late-arriving data for reconciliation.

Do not allow two independent copies of a transactional site to take changes without a plan to reconcile them. The right approach depends on the application; a generic file transfer is not enough to settle conflicting orders or bookings.

7. Coordinate DNS and email changes

If your DNS provider is staying the same, change only the records required for the website move. If nameservers are changing, the replacement DNS zone must contain the necessary website, mail and verification records first. Follow the DNS provider’s instructions for DNSSEC when changing authoritative DNS.

Ask the DNS administrator whether lowering an editable record’s TTL in advance is useful. Existing cached values need time to expire, and local caches can delay the visible change. Changing a website record’s TTL does not guarantee instant nameserver propagation. Cloudflare’s TTL documentation explains the distinction.

Keep MX records, sender-authentication records such as SPF, DKIM and DMARC, and any required mail-related hostnames aligned with the actual email service. After the switch, test sending and receiving with an external mailbox, website-generated email, aliases and forwarding where used. Confirm message history and user access separately if mailboxes moved.

8. Agree rollback and final acceptance

Write the rollback plan before the switch: what failure triggers it, who decides, how long the decision window lasts and how recent data will be protected. Changing DNS back is only one part of recovery. If the destination has accepted orders or other writes, retain both data sets and reconcile them with the application owner before restoring an older database.

When the destination is working, check it from outside the hosting network and have the business owner sign off the important tasks. Confirm that any temporary payment, email or scheduled-job restrictions have been removed from the production environment and that its indexing settings are correct.

• Website journeys, HTTPS and important existing URLs work.
• Search access, canonical URLs and the sitemap pass the SEO checks, and any migration redirects will remain active after the old hosting is retired.
• Recent content, orders, enquiries and other data are accounted for.
• Email delivery, mailbox access and any agreed mailbox migration are verified.
• Backups, monitoring and ongoing support have named owners.
• The agreed observation and rollback period is complete, and the recovery copy is retained.

Cancel the old service only after these checks and after confirming that it no longer supplies required DNS, mail or another dependency. Keep the change record with your account information. Discuss your migration requirements with our team before booking a move, including the source platform, website size, mailbox needs and any custom work.

Frequently asked questions

Do I have to transfer my domain to change hosting?

Usually, no. Registration, DNS and website hosting can remain with different providers. Confirm who controls the DNS records and what needs to change; a registration transfer is a separate decision.

Will moving my website also move my email?

Not automatically. Website migration and mailbox migration have different requirements. Agree whether accounts, historical messages, aliases and a final synchronization are included before changing email records.

Can a hosting migration have zero downtime?

Careful preparation can reduce disruption, but uninterrupted service should not be assumed. DNS caches, final data transfer, application behavior and changes to mail or HTTPS can affect the switch. Agree the expected interruption and recovery plan for your actual setup.

How long should I keep the old hosting?

Keep it through the agreed verification and rollback period. Before canceling, check the website, recent data, email, DNS and backups, and confirm that no required service still depends on the old account. There is no single waiting period that fits every migration.

Will my article URLs and search rankings stay the same?

A hosting-only move can keep the same article URLs. Preserve their content, metadata and existing redirects, then verify crawl access, canonicals and the sitemap. If an address changes, redirect it to the relevant replacement. Follow the SEO preservation checklist and compare search performance after launch. Rankings can still fluctuate; a hosting move does not guarantee that they remain unchanged or improve.