Websites
WordPress, Laravel applications, static sites and the odd thing nobody can name any more. Files, database, uploads and redirects.
Migrations
Moving is wherethings get lost.
A move looks like copying files. It is really a dozen things that have to arrive together: the domain, the DNS records, the mail routing, the certificates, the database, the redirects, and every service that verifies itself through your DNS.
What we move
Servers
Off shared hosting, off an old VPS, off the machine in the cupboard. Rebuilt current rather than carried over with its problems.
Mailboxes with their history, shared mailboxes, aliases and groups, between Microsoft 365, Google Workspace and Migadu.
Domains and DNS
Registrar transfers, and DNS moved with every record accounted for, including the ones nobody remembers adding.
Whole platforms
When the site, the mail, the domain and the server all move at once, and the order matters more than the speed.
Away from us, too
If you ever leave, you get the accounts, the data and a handover. Your setup is not our lock-in.
How a move actually runs
- Inventory firstEverything that exists, not everything that was mentioned. Subdomains, mail records, verification records for other services, scheduled jobs, the lot.
- Lower the time-to-liveDNS changes take as long as the old records tell the internet they do. Shortening those values days in advance is what makes the changeover quick.
- Build and copyThe new home is built and the content, database and mailboxes are copied while the old one carries on serving.
- Rehearse on a private addressPages, logins, forms, checkout. Used properly, by people, before anything public changes.
- Cut over at a sensible hourRecords change, both systems stay live, we watch traffic arrive at the new one and mail keep flowing.
- Verify from the outsideNot "it looks fine from here". Checked from the internet: pages, redirects, certificates, forms, and a real test email in and out.
- Retire the old one, laterWhen you are happy, not on launch day. Until then it is the rollback.
Learned the hard way, so you don't have to
Where moves go wrong.
These are the specific failures we plan around. Every one of them is common, and every one of them is avoidable with an afternoon of preparation.
- The website moves and the email stops, because the mail records lived in the DNS that got replaced.
- A service that verified itself through a DNS record goes quiet weeks later, and nobody links the two events.
- The old host is cancelled on the day of the move, so there is nothing to go back to.
- Nobody lowered the time-to-live, so the changeover lasts a day instead of a few minutes.
- The certificate doesn't follow the site and every visitor is warned off on launch day.
- Redirects are forgotten, and years of search rankings point at dead pages.
Questions we get asked
How much downtime should we expect?
For a normal website and mailbox move, the aim is none that a visitor or a sender would notice. That is what the preparation buys: the old system keeps serving until the new one is answering.
How long does a move take?
The work is usually days rather than weeks; the changeover itself is short. What stretches a project is waiting for access to accounts nobody can find the login for, so starting that search early is the single best thing you can do.
Do you deal with our old provider?
We can, where you authorise it. Some providers will only talk to the account holder, in which case we write down exactly what to ask them for.
What about our search rankings?
Addresses stay the same wherever possible, and where they change we map old to new with permanent redirects so the rankings follow.
More detail on the service itself: Infrastructure Migrations, or for mailboxes specifically, Email & Migrations.
Thinking about moving?
Tell us what you are on now.
Even if the answer is "no idea, someone set it up in 2014". Finding that out is the first part of the job anyway.