You rarely choose a web host twice for the same site. Sooner or later you change anyway: the server struggles at peak hours, support stops answering, the renewal invoice has doubled, or an audit shows that server response time is holding every page back. The decision should then rest on verifiable criteria, not on a sales page and an introductory price.
The pattern repeats on most small-business moves. The purely technical part usually goes well; it is the peripheral omissions that cost days of visibility. A DNS record left behind, a mailbox nobody migrated, a certificate that did not follow, an incomplete database export.
What follows is what to verify before signing with a new provider, then the switching sequence that keeps search performance stable.
What a migration actually covers
Migrating is not copying a folder. The real scope has six blocks, and each one needs a named owner before the day itself:
- the site files: code, theme, plugins and media;
- the database or databases, with their character sets and collations;
- email accounts, aliases and history — the item most often forgotten, and the one that generates the most calls the next morning;
- scheduled tasks, automated jobs and connections to third-party services;
- TLS certificates and the web server configuration;
- the complete DNS zone, including MX, SPF, DKIM and DMARC records.
If one of those blocks is not mapped, the migration still happens. You simply discover the gap in production, at the worst moment.
Technical criteria to check before you sign
Real resources, not advertised ones
On shared hosting, "unlimited" never refers to processing power. Ask in writing for the values that concern you: memory allocated to PHP, maximum script execution time, concurrent PHP processes, disk input/output quotas, database entries. A brochure site will not notice; a catalogue with thousands of references will. If support cannot answer, assume the answer is "not much".
PHP version and update cadence
This is the simplest indicator of how current an infrastructure is. According to the official PHP supported versions calendar (consulted on 11 September 2026), PHP 8.2 is in security support only until 31 December 2026, PHP 8.3 until 31 December 2027, PHP 8.4 until 31 December 2028 and PHP 8.5 until 31 December 2029. Earlier branches, PHP 8.1 included, no longer appear on the list: they receive no fixes at all. A host that does not offer the two most recent branches, or that charges for a version change, is behind.
HTTP/3, TLS and certificate handling
HTTP/3 is no longer a curiosity: W3Techs recorded it on 40.7% of the sites in its panel in September 2026 (W3Techs survey, scope: sites tracked by the publisher, measured daily). The gain shows up mainly on unstable mobile connections. Ask whether it is on by default or only on request.
On certificates, the constraint has changed in nature. The CA/Browser Forum has adopted a schedule reducing the maximum lifetime of public TLS certificates: 200 days since 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029 (ballot SC-081v3, schedule confirmed by DigiCert). Manual renewal is finished. Require automated renewal, included in the price, and check that it also covers subdomains and aliases.
Backups, restores and a recovery plan
The useful question is not "do you take backups?" but "how long does a restore take, who triggers it, and have I tested it?". Three parameters to get in writing: frequency, retention in days, and where the copies are held — a backup stored on the same server as the site protects nothing. Check that you can restore it yourself, from the client area, without raising a ticket. And keep one full backup under your own control before you switch.
The contractual points people skip
As soon as the server processes personal data — and a contact form is enough — your host acts as a processor on your behalf. Under the UK GDPR and the EU GDPR alike, Article 28 requires the contract to set out security measures, record-keeping, breach notification, the assistance you can expect as controller, and what happens to the data when the contract ends.
| Point to check | Question to put to the provider | Risk if you skip it |
|---|---|---|
| Where the data sits | In which countries is the data hosted, backups and logs included? | Undocumented international transfers in your records |
| Sub-processor chain | Which sub-processors are involved, and how am I told of a change? | Incomplete Article 28 contract, liability left uncovered |
| Exit and portability | In what format and within what time do I get files, databases and configuration back? | No practical way out, or one charged at a premium |
| Domain name | Who is the registrant on record, and who holds the transfer code? | Loss of control of the domain in a dispute |
The EU Data Act, Regulation (EU) 2023/2854, has applied since 12 September 2025 and frames a customer's ability to switch data processing provider. Where your provider falls within its scope it works in your favour, but it does not replace a clear exit clause: have the export formats and the deadlines written into the contract.
On the domain name, the rule admits no exception: the registrant on record must be your company, with a contact address you own and read. If it sits in the name of an agency or a former supplier, sort that out before the migration.
Migrating without losing rankings: the sequence
A change of host with no change of URL is the most favourable scenario for Google. You still have to follow the order.
Seven days out: lower the TTL on your DNS records
Google explicitly recommends reducing the TTL of DNS records at least a week before the switch, so the new settings propagate faster through internet providers (Search Central documentation on a site move without URL changes). Go from 86,400 to 300 seconds, and raise the TTL again once the switch has settled.
Five days out: a full run-through on the new server
Copy the site to the new infrastructure and test it behind a temporary hostname, protected by a noindex tag or by authentication, so nothing stray is indexed. Check rendering, forms, payments, transactional emails and scheduled tasks. Above all, check that the new host's firewall does not block Googlebot: that is a classic cause of a post-migration drop. Record the starting position too — rankings, indexed pages, response times — since that baseline is what makes a later diagnosis possible. A technical SEO audit run before the switch serves that purpose well.
The day before: freeze the content
No publishing, no test orders, no product edits between the final export and the switch. Anything written on the old server after the export is lost. Warn the editorial team and, for a shop, pick a quiet window.
Switch day: DNS, redirects, checks
Remove the temporary blocks, in robots.txt and in the noindex tag, then switch the DNS records. Leave the old server online for several days: while propagation runs, some visitors and crawlers still arrive there, and a server shut down too early produces errors that do show up in the index. If the move also involves a change of URL — a new structure, a switch to HTTPS, domains merged — every old address needs a 301 redirect to its exact equivalent, and redirect chains have to be flattened. That is the case with a WordPress redesign, which is better handled as a project separate from the hosting move.
The following month: monitoring
Watch the server logs and the indexing status in Search Console. Google notes that a temporary drop in Googlebot's crawl rate just after a move is normal: it is not a warning sign in itself, and only becomes one if it persists beyond a few weeks. If pages start dropping out of results, work through the indexing checks instead of guessing. Then look at response codes, server response times and organic traffic. A dashboard fed by Search Console and your analytics tool shows at a glance whether the curve has picked up again, and that kind of ongoing traffic monitoring is worth keeping beyond the migration.
One week later: what to go back over
Are emails still delivered, and staying out of spam folders now that SPF and DKIM records are updated? Does the certificate cover every variant of the domain, with automatic renewal confirmed? Do the scheduled tasks run on time? Are the new backups genuinely running, and have you tested a restore? Is the old contract cancelled, after retrieving the final backup? Until all five answers are yes, the migration is not finished.
Common questions
Does changing host cost you positions in Google?
Not in itself. As long as the URLs stay the same and the pages respond normally, Google treats the operation as an infrastructure move. The losses people report come from peripheral errors: pages erroring during propagation, crawlers blocked by the new firewall, a staging noindex tag left in production. A temporary drop in crawl rate straight after the switch is expected.
How long does DNS propagation take?
It depends on the TTL set on your records, which is how long intermediate servers keep the old answer cached. With a TTL left at 24 hours, allow up to two days; lower it to five minutes a week beforehand and propagation is measured in minutes. Raise it back to its usual value once the move has settled.
Should you switch off the old hosting straight away?
No. Keep it online and working for several days: until propagation finishes, some visitors and crawlers still land there. Shut it down only when the logs show traffic to the old infrastructure has fallen to zero, and after a final full backup.
Which PHP version should you require from a new host?
Aim for a branch still in active support, and avoid any offer that stops at PHP 8.1, which no longer receives security fixes. Check that you can change version yourself from the client area at no extra cost, and test your site on the new version before the switch: some older plugins do not follow.
Who should own the domain name?
The registrant on record should be your company, with a contact address you own and actually read. If it is registered to an agency, a former employee or a supplier, you depend on them for any transfer and risk losing control of the site in a dispute.