Migration help is part of every plan on this site. A person does the work rather than an importer script, and there is no separate fee: what the move costs is already inside the price of the plan. This page describes how one actually runs, what we need from you before it can start, and what downtime honestly looks like.
Written down because an improvised move is a move that loses something. You approve each step before the next one starts.
The person who builds your new environment is the person who runs the move and the one who signs the welcome email. There is no handover halfway through to somebody who has to read the notes for the first time on cutover night.
Six things. Gathering them takes an afternoon and saves the two conversations that otherwise happen at the worst possible moment.
SSH, SFTP or panel credentials for the current host, or a complete backup archive if the old provider will not hand over access. Read-only is enough for the inventory stage, and we say before we need anything stronger.
Access at the registrar or the DNS provider, or a named person on your side who can change records at an agreed time. If nobody can change a record on the day, the cutover waits for whoever can, so it is worth checking early.
All of the hostnames that should end up pointing at the new environment, including the quiet ones: a staging site, a mail host, a shop's API subdomain, an old campaign domain that somebody still links to.
Cron jobs, queue workers and scheduled scripts, with a line each on what they do and how often they run. They are invisible until the night something that should have run does not, and an invoice or a nightly export goes missing.
Tell us whether mailboxes live on the old host, with a separate provider, or should end up with us. Mail records are separate from website records, and moving one without thinking about the other is how mail quietly stops arriving.
Partner firewalls, API allow-lists, bank or payment integrations, external monitoring, and licences tied to the current IP. Tell us and we will give you the new address early, so it can be added everywhere before the switch rather than after it.
We do not promise zero downtime, and you should be careful with anyone who promises it for a service holding a database. Two copies cannot both accept writes during a move without somebody having to reconcile them afterwards, so at some point writing stops on one side and starts on the other.
What we do instead is make that moment short and put it where it costs you least. The dry run means the new environment is already built and tested before the window opens. The DNS time to live is lowered days in advance, so resolvers are no longer holding the old address. The final sync carries only the delta since the dry run. The window is agreed with you and placed in a quiet hour of your week.
A static site, a read-only site or a cache layer can usually move with no interruption at all. A shop taking orders, a database-backed application or a mail server has a short freeze, and you will know beforehand roughly how long it should be and what we do if it runs long.
What we will not give you is an exact number of seconds before the final sync has run. Until we have measured the delta on your real data, the honest answer is a range, and we would rather hand you the range than a figure we cannot stand behind at three in the morning.
And, just as usefully, the things that are not ours to move. Read the right-hand column before the window rather than after it.
| Item | What moves | What to check afterwards |
|---|---|---|
| Files | Document roots, uploads, media libraries and configuration, with permissions and ownership preserved. | Upload something new and confirm it lands where the application expects it. |
| Databases | MySQL, MariaDB and PostgreSQL, dumped and restored with users, grants and character sets. Application config is repointed at the new host. | Log in as an ordinary user and write something, then read it back. |
| TLS certificates | New certificates issued for the new environment before cutover. A commercial certificate can be reinstalled if you still hold the key. | That every hostname opens without a warning, the www variant included. |
| Cron and workers | Copied with their schedules and paths, and left disabled until cutover so that both sides never run the same job at once. | That the first night of scheduled jobs really ran, and produced output. |
| DNS records | The zone is rebuilt: A and AAAA, MX, CNAME, service records, and TXT including SPF and DKIM. | Mail delivery, and anything external that verifies a TXT record. |
| Mailboxes | Where mail lives on the old host, mailboxes and their contents are copied over IMAP with the folder structure intact. | That old mail is present, and that a test message arrives in both directions. |
Every plan includes help. What is included differs, because moving ten brochure sites and moving a container platform are not the same job. Full comparison
Sites included
Shared NVMe hosting for company sites and small shops
Plan detailsSites included
Tuned WordPress stack with staging, updates and caching
Plan detailsDNS cutover
Content delivery with edge caching, WAF and image optimisation
Plan detailsManifests reviewed
Managed Kubernetes cluster with registry, ingress and CI hooks
Plan detailsFull project
Isolated compute pool with private networking and 24/7 monitoring
Plan detailsA move you cannot undo is a gamble. The point of the grace period is that the decision stays reversible while the new environment proves itself under real traffic.
While the new environment is built and tested, nothing on the old one is stopped, deleted or reconfigured. It carries your live traffic right up to the moment the records change, which is the only visible event in the whole process.
The cutover happens when you say the dry run is right, not when a schedule says the date has arrived. If your testing finds something, we fix it in the copy and you look again. Nobody is pushed through a window to save a calendar entry.
After cutover the old environment stays reachable and untouched for seven days. If you want it kept longer, say so before the window and we will arrange it; otherwise it is released at the end of the week and you get a final copy of the data.
How a rollback actually works: because the old side was frozen at the final sync and never written to again, pointing the DNS records back at it returns you to a consistent system. The catch is anything written on the new side since cutover, which has to be carried back by hand. That is why a rollback is a conversation with you and not a reflex, and why the first hours after a switch are the ones we watch hardest.
An illustration of the process rather than a customer case. Names, sizes and dates are deliberately generic; your own move gets its own plan in writing.
The part that goes wrong in this example is the plugin licence, because reissuing it depends on a vendor rather than on us. That is exactly why it is flagged on day one instead of discovered in the window.
Most of a migration is a checklist, a terminal and somebody paying attention. The interesting decisions were all made during the inventory and the dry run, which is where we would rather spend your time than in the window.
Migration help is included on every plan. Tell us what you run today and we will tell you what the move looks like before you buy anything.
Current host, roughly how many sites and databases, whether mail is involved, and anything you already know is awkward. An engineer replies with the plan that fits and how the move would run.
Not sure which plan fits? Describe the project — traffic, stack, what you run today. We read every message and reply by email within 24 hours on working days.
