Forced to Switch Hosts? How to Move Your Website to the EU With Near-Zero Downtime
The old host is winding down, or the renewal invoice doubled, and the site has to move. Here is how a free migration to our EU servers runs in practice, and why your visitors won't notice it happening.
- Save your own copies first
- What a typical move looks like
- Email is a separate move
- Where the site lands
- What it costs
Most migration enquiries we get have a deadline attached. The old host has announced it's winding down, or this year's renewal invoice came in at double last year's price, and now a site, a database, a handful of mailboxes and a domain all need a new home before some date on a calendar. We've moved sites off Beget, Reg.ru, Hostinger, GoDaddy, Bluehost and a long tail of smaller panels. The copying itself is routine work for us. When a move does go wrong, the copying is rarely at fault. Usually the problem is something the owner didn't save while they still had access to the old panel.
Save your own copies first#
We do the actual moving, but before anything else happens, spend an evening downloading everything yourself. If the old host is closing, panel access can disappear earlier than the announced date, and a support ticket to a company in liquidation goes nowhere. What to grab:
- Site files: a full archive through the file manager, or over FTP.
- Database: a dump from phpMyAdmin, or whatever export the panel offers.
- Mailboxes: the list of addresses, their passwords, and any forwarding rules.
- DNS zone: an export if the panel has one; otherwise copy every A, MX, TXT and CNAME record into a text file.
- Registrar login: where the domain itself is registered, and the credentials for it. This is often a different company than the host.
People usually skip the DNS zone, and that's the export they end up needing. A verification TXT from some integration set up years ago, an MX pointing somewhere half-forgotten — once the panel is gone, reconstructing that from memory is guesswork.
What a typical move looks like#
No two migrations are identical, but a typical one runs like this.
It starts when you write and tell us about the site: what it runs on, roughly how big it is, where the mail lives. We come back with a plan and usually a couple of questions. The one thing we need from you at this stage is read-only access to the current host. Read-only means what it says: we copy files and databases out, and we change nothing and delete nothing on the old side.
Then we copy the files, the database and the email settings to a private staging address on our servers. Your live site doesn't notice any of this; it keeps serving visitors from the old host the whole time. When the copy is up, you get the staging link and click through it yourself. Try the contact form, log into the admin, run a test order if you sell anything. Whatever you find, we fix before going further. And if something was already broken on the old host, we say so before we start; fixing it is separate work from the move.
Cutover is the only moment that needs scheduling, and you pick the window. Tuesday at 3 a.m. or Sunday afternoon, whatever suits your traffic. By then every DNS record has been recreated on our side, so the switch itself is a small change at the registrar. Propagation takes a few hours worldwide, and during those hours both copies of the site are live, so a visitor lands on a working page whichever server their resolver still points at. We stay on call for 24 hours after the switch. Only then do you cancel the old hosting, on your own schedule, once you've confirmed nothing is still being served from there.
Most moves are finished within a day of us getting access. Larger or more tangled sites take longer, and we say so up front.
Email is a separate move#
Your email doesn't have to sit on the same server as your website, and a migration is a natural moment to separate the two. We move mailboxes to Microsoft 365 or Google Workspace: messages, contacts and rules come across, and we set up SPF, DKIM and DMARC on the new DNS records so your mail keeps landing in inboxes after the switch. If those mailboxes need to stay inside the EU, say so when you first write; we set the region when the tenant is created, and moving it later is awkward. Options and prices are on the business email page.
Where the site lands#
The servers are in the Netherlands. For a European audience that means short physical distance and faster page loads; on the legal side it means the site and its database stay inside the EU, with no transfer to a third country to explain in your privacy policy. We went through the jurisdiction question properly in where your data lives, and why it still matters.
For WordPress we switch on server-level caching as part of the move, so plenty of sites arrive faster than they left, and if your code needs an older PHP we match whatever version the old host ran. What makes a site fast in the first place, most of which is in your hands rather than the host's, is a longer subject; we went through it in why your website feels slow.
What it costs#
The migration is free on every plan, Self-Managed and Managed alike, with no setup fee. The full description of what's included is on the migration page.
After that you pay for the hosting itself: Self-Managed from €3.99 a month if you manage the server side yourself, Managed from €9 a month if we do. Monthly or annual, cancel anytime, and there's a 30-day money-back guarantee if the move doesn't work out for you. We don't do promo codes — nobody who signed up yesterday got a better price than you.
If your deadline is close, start with the downloads above today; everything else can run in parallel once we have access. We handle the whole process in English or Russian, whichever is easier for you. Tell us about your site and you'll have an answer the same day.