Short answer: you can move a UK website to a new host with no visible downtime, and most moves that go wrong do not go wrong at the copying stage. They go wrong because the domain was pointed at the new server before the new server was ready, or because nobody planned for the email. Copy everything first, test it on the new host while the old site is still serving visitors, lower your DNS TTL a week in advance, then switch — and leave the old account running until its traffic has dropped to zero.
A host move is not one event. It is a copy, a test, a DNS change and a decommission, and the risk sits almost entirely in the last two.
When you change where your domain points, the change does not reach everyone at once. Resolvers keep a cached copy of your records for as long as the record's time-to-live (TTL) allows, and go on serving that cached answer until it expires. Cloudflare's own explainer puts the ceiling at 86,400 seconds — 24 hours — and notes that most TTLs are six hours or less.
That window is why two visitors can see two different servers on the same afternoon. It is not a fault, and it is entirely predictable if you plan for it.
Your website and your mailboxes usually follow the same domain, so the moment you repoint the domain you have also repointed the mail. If the new mailboxes are empty, or the mail records were not set up first, messages sent during the switch land somewhere nobody is looking — or bounce.
Websites fail visibly and someone tells you. Email fails quietly, and you find out a fortnight later when a customer asks why you ignored them.
An SSL certificate is tied to the server holding it, not to the domain. Move the domain to a server with no certificate and every visitor gets a browser security warning, which looks worse than being offline. It has to exist on the new host before the switch.
Done in this sequence, a move has no window in which your site is unreachable.
This is the single highest-value thing you can do, and it is free. Google's own guidance for changing hosting is explicit: “Consider lowering the TTL to a conservative low value (for example, a few hours) at least a week in advance of the move.”
Drop the TTL early and the cache window on switchover day shrinks from a day to a couple of hours. Leave it high and you have committed yourself to a full day of split traffic.
Files, databases and mailboxes all get copied to the new server while the old one carries on serving the public as normal. Nothing here is visible to visitors, so there is no reason to rush. If your site is a shop or takes bookings, note the time of the final database copy — anything written after it needs copying again at switchover.
Test the new copy properly before the domain points at it: every template, the checkout or contact form, a real login, and the mailboxes. A staging hostname or a local hosts-file entry lets you browse the new server using the real domain name without changing anything publicly.
Google also warns about what gets left behind at this stage — a robots.txt disallow rule or a noindex tag from the staging copy going live with the real site, or a firewall that blocks Googlebot from reaching the new host. Both are quiet and expensive.
Only now do you change the nameservers or the A record. Keep both hosts running and watch the logs on each: traffic should tail off on the old server and climb on the new one over the next few hours. A short dip in crawl rate immediately after a move is normal and recovers on its own over the following days.
Shut the old hosting down only once its traffic has reached zero — not on the day you switch, and not because the billing date is coming up. The old account is your rollback; cancelling it early turns a recoverable problem into a restore from backup.
A website is read-only to its visitors: a request that hits the old server during the cache window simply shows the old site, and no harm is done. Mail is different — a message delivered to the old server sits in a mailbox you have stopped checking, and that failure is silent and not reversible by waiting.
Ask any host what their migration actually covers, and ask it in writing. A move that copies your website but leaves you to drag mailboxes across in a desktop mail client is not a migration, it is half of one.
On our side, migration is free on every plan and covers the site, the databases and every mailbox, with message counts verified on both sides before switchover. That step is worth insisting on wherever you go: a count that matches is evidence, “it looked fine” is not.
Both routes work. The honest difference is who carries the risk at each stage.
| Stage | Doing it yourself | Free UKBox migration |
|---|---|---|
| Files and databases | You copy and re-import; watch for PHP version differences | We copy and re-import, and fix mismatches |
| Mailboxes | Usually the hardest part; easy to lose folders or dates | Copied server-side, counts verified before switchover |
| TTL lowered in advance | Yours to remember, a week ahead | We tell you when to do it, or do it if we hold the DNS |
| SSL certificate | You install it on the new host before switching | Issued and renewed automatically, included |
| Testing before switchover | Yours | We test, you sign off |
| Timing of the switch | Yours | Out-of-hours slots available to minimise disruption |
| Rollback | Keep the old account running | Keep the old account running — same advice |
| Cost | Your time | £0 |
Prices as at October 2026, excluding VAT, with the inc-VAT figure shown alongside on the hosting plans page:
The first month is £1 on any monthly plan for new customers, and the standard price after that is held for three full years — written into clause 15.2 of our terms rather than promised in marketing copy. Every plan includes cPanel, LiteSpeed with LSCache, one-click WordPress, free SSL, Imunify360 and daily off-site backups, on our own hardware in London, Coventry and Maidenhead.
Our 99.9% uptime figure is a target, not an SLA backed by service credits. Standard support is best-effort extended hours — staff are typically about from 5am to midnight, seven days, with replies around ten minutes between 8am and 5pm — but it is not a guaranteed 24/7 call centre. If downtime genuinely costs you money, our Priority Support add-on at £49/mo +VAT exists for that.
“Unlimited” on the Business and Pro plans is bounded by our published Fair Usage Policy. And one figure we will not give you off the cuff: our hosting plans state daily off-site backups, but the page publishes no retention period, so ask us to put the current figure in writing before you move — and ask any host you are considering to do the same.
The copying is usually an hour or two for a typical small-business site. The part that sets the calendar is the TTL: lower it a week before, and switchover day itself is a couple of hours of split traffic rather than a full day.
Not if the new server is already serving a tested copy. During the cache window some visitors reach the old server and some the new one, and both work. Downtime happens when you repoint at a server that isn't ready.
You shouldn't, but this is where losses actually occur. Mailboxes must be copied and verified before the domain moves, and the old mail server should stay live for a few days afterwards to catch late deliveries.
No. If your URLs haven't changed there is nothing to submit — Google treats it as the same site at a new address. Just make sure no staging noindex tag or robots.txt block travelled across.
Yes, and you should check this before buying anywhere. We are rolling monthly with no contract, and a cPanel account moves anywhere — including away from us. We also publish our nameservers and the IPS tag you'd need on our nameservers and IPS tag page.
Our how switching works page sets out the whole process, timings included, and migration is free on every plan. If you'd rather someone looked at your current setup first, call 0330 088 2279 and we'll tell you honestly whether moving is worth it.
Sources: Google Search Central's Changing Your Web Hosting and SEO for the TTL recommendation and the staging-tag warnings, and Cloudflare's Common DNS issues for TTL ceilings and caching behaviour.
— The UKBox team
