You can switch hosting providers and keep your domain. The hosting provider stores and serves the website; the domain is the address visitors use. To make the transfer, create a working copy at the new hosting provider, test it, and modify the necessary DNS records when you're ready.
The homepage loads on the new server, but the form that receives requests, the email, and the data created during the migration still need to be checked. A hosting migration is only accepted after verifying these functions, not just by looking at the design.
The SEO risk isn't in changing providers themselves, but rather in the migration causing errors, blocks, incomplete content, or unintentional URL changes. If the URLs remain the same, you don't need to turn the project into a domain migration.
What you should identify before booking the destination
Note where the domain is managed, who handles DNS, where the mailboxes are located, and which systems send emails. These services are often provided by different providers. Don't assume that moving the website also moves the email or that a file backup includes the database.
Review site requirements: language version, extensions, database, storage, scheduled tasks, and external connections. Request compatibility confirmation from the target provider. A plan with more resources will not, by itself, fix a misconfigured application.
Make a backup and document how to restore it.
Save files and the database where applicable, as well as the configuration needed to rebuild the site. Keep the backup off the server you are replacing. Verify that the file opens and that the database contains the expected tables.
Define a point of return: who can restore, which backup they would use, and what new data would need to be reconciled. On an informational website, the risk of simultaneous changes might be small; in a store, every order created during the migration matters.
Try the copy without yet directing all traffic
Use the preview mechanism offered by your hosting provider or a controlled local resolution to test the domain against the new server. Avoid making an indexable copy of the site publicly available. If you use a temporary address, remember that some features depend on the live domain.
| Proof | What to validate |
|---|---|
| Cover and templates | Content, styles, images, and navigation. |
| Forms | Receipt and registration of an identifiable piece of evidence. |
| Purchase or reservations | Complete flow according to the available test mode. |
| Old URLs | Same routes and expected answers. |
| External services | Connections with CRM, logistics or payment systems. |
| Technical SEO | Directives, canonical, sitemap and internal links. |
Try both with and without a session. If the copy loads but doesn't submit forms, there's still work to be done. Review error logs before attributing the problem to the DNS.
Plan your DNS change without breaking your email
Determine which records need to be changed. Modifying the website's destination doesn't necessarily require replacing all name servers. If you're changing the entire DNS zone, first reproduce the records that are still needed, including those for mail and verification.
The TTL affects how long resolvers can retain a response. Adjusting it in advance can help manage the transition, but it doesn't guarantee that all users will switch servers at the same time. Keep both environments prepared during the coexistence period.
Google's documentation for hosting migrations recommends preparing and testing the new infrastructure before the change and monitoring the traffic still arriving at the source. Use that sequence as a framework, adapting it to your provider.
Control the data that changes during the transfer.
A copy taken on Monday may be outdated when released on Tuesday. Define an editing pause or final synchronization for posts, forms, and orders. In a store, avoid leaving two systems accepting transactions that you can't later reconcile.
Before the cutoff, record the last order and the final export time. Then review the operations in the transition window. This allows you to detect missing or duplicate items based on specific criteria, instead of relying solely on the fact that "the website is working.".
What to check after changing accommodations
Check domain resolution, HTTPS, critical pages, and a test transaction allowed. Confirm that no development environment protection remains blocking users or search engines. Verify that URLs, previous redirect rules, and measurement tags have been preserved.
If a page stops appearing in results after the move, separate the crawling and indexing status with our visibility diagnostic guide.
Observe server errors and performance using a comparable sample. If the new infrastructure performs worse in a template, investigate caching, queries, and resources. For specific performance optimization, see the guide for WPO and Core Web Vitals.
A common scenario: the web moves, but email lives elsewhere
Imagine your domain is registered with one provider, your website runs on another, and your corporate email uses a third. Your new hosting provider gives you nameservers, and someone suggests replacing them immediately. Before doing so, you need to know what the current domain contains and which services depend on it.
Prepare a clear and legible inventory of records and their function. Identify those that serve the website, those involved in email, and those that verify services. Keep a dated copy. There's no need to reveal secrets to the editorial team; however, the technical lead needs to know what to keep and why.
If only the website destination changes, modifying the corresponding records may be sufficient. If you change who manages the entire zone, prepare the new configuration before the service interruption. In both cases, test sending and receiving emails with the team once the transition is complete.
This example explains why "migration included" needs a written scope. Some services move files and databases; others also check DNS and email. Ask what is being checked, what requires third-party intervention, and what evidence you will receive upon completion.
What does a useful copy of WordPress contain?
A WordPress website combines files and a database, as well as external dependencies. Keeping only the images folder doesn't preserve posts, settings, or relationships. Keeping only the database also doesn't guarantee you'll have the themes and resources needed to rebuild it.
Document what was backed up and how it would be restored. Record relevant versions, resource locations, and settings that should not be publicly shared. Store credentials using the agreed-upon secure mechanism, without copying them to reports or coordination chats.
Test the restore process in the target environment or a controlled environment. The goal is to verify that the backup allows you to rebuild a working application, not just that the compressed file exists. If a dependency is missing, it's best to discover it before changing the traffic.
It includes a check of file permissions and tasks required for operation. A website might load the homepage but fail to upload media, generate documents, or run background processes. Select the tests based on what your site actually does.
How to rehearse without altering what customers see
Request a controlled preview of the target server from the technical team. This should allow you to test the application within the appropriate domain context and keep the copy out of unintended public access. Document the limitations of your testing method.
During the test, walk through a list of URLs for each template. Open the homepage, a long page, a form, and a route that historically redirected. If you have languages or subdomains, include them. Also, review downloadable files and resources that the user needs to complete an action.
Test the write functions separately: create a test record, receive it in the expected system, and verify that it doesn't generate erroneous communications. Identify the test data for later cleaning using the authorized procedure. A test without traceability can be mistaken for a legitimate request.
Save the test results and resolve any outstanding issues first. Do not accept a screenshot of the homepage as validation. The site must perform its critical functions at the destination, and the team must be aware of any remaining exceptions.
The problem of orders created while traffic changes
In a store, the time between the initial copy and the cutoff can result in new orders, stock changes, and customer accounts. If you only import the initial copy, these changes won't appear in the destination. The plan needs an explicit rule to reconcile them.
One operational option might be an agreed-upon pause and final synchronization window; another might require a more complex synchronization mechanism. The choice depends on the platform and the business. The important thing is to prevent two databases from accepting independent changes without later knowing which is the valid source.
Note the time of the last backup and the records that define the cutoff. Then compare the operations within the transition window. Include modifications to existing orders, not just new orders, if the business can edit them during that period.
If an incident occurs and you need to revert to the source, first preserve the changes made to the target. An infrastructure rollback does not automatically reverse the timeline. The rollback procedure should explain what happens to the data created during the public test.
What incidents to watch for during the first day
Organize a review by function: access, forms, email, purchasing, integrations, and measurement. Assign one person to coordinate the review to prevent multiple people from changing the same configuration simultaneously. Each issue should include the URL, time, steps taken, and expected outcome.
If some users reach the source and others the destination, consider the coexistence of DNS responses within the diagnostic process. If all users reach the destination but one section fails, investigate the application, routes, or resources. This distinction prevents repeatedly changing DNS settings to try to resolve a code issue.
Review server logs and compare them to real-world experience. An isolated bot error isn't as urgent as a recurring purchase failure. Prioritize by impact and frequency, documenting what was corrected and how it was verified.
Finalize the migration with a brief handover: current vendor, responsible parties, backup system, retained dependencies, and pending decisions. This document will be useful in case of a renewal, an incident, or a new equipment change.
When to close the previous hosting
Don't cancel it just because your team sees the new homepage. Confirm that traffic is reaching its destination, that no proprietary data remains at the source, and that email, tasks, and integrations don't depend on it. Keep the agreed-upon copies with restricted access.
If the domain or routing structure also changes, add a specific redirection and tracking plan. The project is no longer a simple infrastructure migration. Documenting this difference from the outset prevents incomplete budgets and surprises during launch.
If the site receives orders, forms, or email on the same domain, Plan your move with our team based on a verified copy and a reconciliation plan.
Sources and documentation consulted
Documentation consulted on September 27, 2026.
Frequently asked questions about changing hosting providers
Does changing my hosting provider change my domain?
Not necessarily. You can keep the domain and point the website to another server through its DNS settings.
Do I have to transfer the domain to the new provider?
It is not mandatory to transfer the hosting. Transferring the domain registration is a separate decision.
Is email lost when moving the website?
It may be affected if you modify records or cancel services it depends on. Identify where the email is running and preserve its settings.
Should I use Change of Address in Search Console?
A hosting transfer that keeps the same URLs is not a domain change. Do not use this tool as a substitute for infrastructure control.
