Moving in
A move we have already rehearsed
Your store keeps serving customers at your current host the whole time. We copy everything, check that it works, and only then move the address — visitors never see a gap. Free on every plan, including the cheapest.
The last one, in numbers
One operation, one night. These are the figures from our own takeover of another host's platform — not a brochure estimate.
- 406
- hosting accounts moved
- 1 665
- mailboxes, every message intact
- 610
- databases restored
- 1,3 TB
- of sites and databases copied
What it looks like from your side
Three steps, and two of them are ours. You are not asked to export anything, freeze anything or pick a date when your shop can be down.
You tell us where it lives
Access to the current host, or just the domain if you would rather we work it out. If you do not have the credentials any more, that is a common case and we have handled it before.
We copy and verify
Sites, databases, mailboxes with all their messages, cron jobs, certificates. Your store carries on selling at the old host the entire time — nothing is switched off to make the copy.
We move the address when it works
Only after the copy answers correctly on our servers do we change the DNS. If something is wrong, the old host is still serving and nobody has lost anything.
The receipt
We check every address afterwards, one at a time
A migration that reports success is not the same as a migration that worked. After the last one we requested all 753 domains from both the old server and ours and compared the answers by hand.
| Verdict | Domains |
|---|---|
| Identical responsebyte-for-byte the same page | 585 |
| Started working herebroken at the old host, fine on ours | 40 |
| Already broken before the movenot caused by us, and not fixed by us either | 83 |
| Different contentsize differed by more than 30% — each one reviewed | 35 |
| Real regressionsall four found and fixed | 4 |
We quote the four that went wrong on purpose. A migration report with no failures in it is not a report, it is a brochure — and the only reason the other numbers mean anything is that this one is in the table with them.
What actually goes wrong
The things a backup file does not carry
Every item below cost us a real incident on a real migration. They are in our checklist now, which is the only honest reason to claim we will not repeat them.
Mail does not live in the home directory
Copying a customer's home folder misses the mail store entirely, and the account looks complete. One domain arrived with 1 mailbox instead of 110. We now compare mailbox counts on both servers before anyone calls it done.
Object cache does not travel
Redis instances are not in a hosting backup. Hundreds of sites came across still pointing at ports that no longer existed — every page still returned 200, just slowly. We rebuild the cache layer and verify by key count, not by HTTP status.
PHP settings pinned in .htaccess
A handler or extension named in the old server's config does not exist on the new one, and the site answers 403 or 500 — with no clue why. We resolve the version per domain before the switch, not after the first complaint.
Restored accounts start their cron jobs
The moment an account is restored it begins running its scheduled tasks, so the same job runs on both servers until the address moves. Anything that sends mail or charges a card does it twice. We suspend them until cutover.
A green report is not completeness
On our own migration a script reported "386 OK, 9 errors" against a queue of 394 — while the server actually held 403 accounts. One live customer with 93 GB fell out on a size limit and was never reported as an error. We compare the two servers' states, never the script's own opinion of itself.
Bring your store over
Tell us what you are running and where. If it is a case we have not seen, we will say so rather than find out on the night.