Tell us what you are running. We will move it.
Files, databases and mailboxes, copied and compared against the originals, running on a temporary address for you to click round before a single record changes. The switch happens at a moment you choose, not one we choose.
Start a migrationHow it runs
The host, the control panel it uses, what the site runs on, and credentials you can revoke afterwards. Read access is enough for most of it.
What the site actually needs — runtime versions, extensions, cron jobs, how big the database is, how much mail there is. Anything awkward is said here, not discovered halfway.
Files, databases and mailboxes are copied to us while your current host carries on serving. Mail is compared message by message rather than assumed to have arrived.
The site runs on a temporary address and you click round it. Log in, submit a form, load the pages you know are fragile. Nothing points at us yet.
DNS and the MX record change when you say so — usually a quiet evening rather than a Monday morning. Lowering the TTL the day before turns the wait from hours into minutes.
Anything that arrived at the old host during the changeover is brought across, so nothing is sitting in a mailbox nobody checks any more. Then you close the old account, in your own time.
What comes across
The whole of it, in the state it is in now — not a fresh installation you then have to fill back up.
- The site and its files Document root, uploads, permissions and the application as configured, not a clean install of the same software.
- Databases Copied whole, with their users and grants recreated on our side. Connection strings are the one thing that changes, and we change them.
- Mail, as it stands Folders, flags, read state and dates — arriving as they were rather than approximately as they were. Verified message by message rather than counted.
- DNS records Your zone rebuilt record for record, including the ones that are easy to miss: SPF, DKIM, DMARC, the MX for a mail service you forgot you used, and the verification TXT records.
- Certificates Not copied — reissued. Every site and every mail domain gets its own, renewed from then on without you.
What does not, and why
Four things a migration cannot quietly bring with it. Better said here than found on the day.
- Mailbox passwords Your old provider holds them hashed and cannot hand them back. Mailbox passwords are set fresh and given to you to pass on, and each person changes one server name in their mail app at the same time.
- Your domain registration It stays exactly where it is. A migration changes which nameservers answer for the domain, not who it is registered with — and the site and the mail keep working while that is true.
- Anything only your old panel did A proprietary feature of the control panel you are leaving has nowhere to land. We check what you are actually using for one before you order rather than after.
- A problem the site already has If it is slow because of what it does, or broken in a way that predates us, moving it moves the problem. We will say so when we see it.
Mailboxes moved and then checked message by message on the test that qualified our IMAP migration tool. All thousand matched before the tool was offered to anybody.
An internal test migration, not a customer count.
Said up front
What tends to go wrong.
None of this is unusual and none of it is a reason not to move. It is a reason to know about it on the day you decide rather than the day it happens.
Resolvers that ignore the TTL
Some caches hold a record longer than they were told to. That is why mail arriving at the old host during the changeover is swept across afterwards rather than assumed to have stopped.
A database big enough to need a window
Past a certain size a copy cannot be instantaneous and still be consistent. We agree a window with you rather than discover one at two in the morning.
Hard-coded addresses
Applications that have the old hostname written into the database or the configuration. Found during the rehearsal, when fixing it costs nothing.
A runtime version that is not here
An old PHP or an extension your application needs. We check what your site actually loads against what your node serves before you order.
Mail apps on other people's devices
We can move the mailboxes; we cannot reach your colleagues' laptops and phones. You get the settings to send round, and it is one server name each.
A registrar login nobody has
The single most common delay. The nameserver change happens where the domain is registered, so find out who holds that account before you pick a date.
Frequently asked questions
How much downtime is there?
For the website, none that a visitor notices: both copies are serving while DNS moves between them, so a request reaches one or the other. For mail, none either — anything delivered to the old host during the changeover is collected and brought across afterwards.
How long does the whole thing take?
That depends on how much there is and how quickly your current host hands it over, so we will give you a figure once we have looked rather than before. The part you have to be present for is the cutover, and that is an evening.
What does it cost?
We tell you before we start, not after. Moving a site and its mailboxes is part of setting your account up. Something genuinely unusual — a bespoke stack we would have to rebuild, or a database large enough to need a maintenance window — is described and priced before you order.
Do I have to move my domain as well?
No, and most people do not. Changing the nameservers is enough, and it is a change you make at your existing registrar. The domain can stay where it is indefinitely.
Can you move just the email, and leave the site where it is?
Yes, and the reverse. They are separate records pointing at separate places, so they can move separately — or on separate evenings, which is often the calmer plan.
What do you need from me?
Access to the current host, access to wherever the DNS is edited, and a list of the mailboxes with which of them still matter. Credentials you can revoke are fine, and preferred.
What if it does not work?
Your old host is untouched throughout, which is the point of rehearsing rather than switching. Until you close that account, pointing the records back is the same change in reverse.
I am moving several client sites at once.
Say so at the start and they are planned as a set rather than one at a time, and tell us whether the clients should be told by you or by nobody. Reseller plans are sized for exactly this.
Tell us what you are running.
The host it is on, roughly how many sites and mailboxes, and anything you already know is awkward. We will come back with what moves, what does not, and how long it takes.
Start a migration