Forced to Switch Hosts? How to Move Your Website to the EU With Near-Zero Downtime

Update, 19 September 2026: every Maxinodes plan now includes mailboxes on your own domain. This article has been updated to match.

• Save your own copies first
• What a typical move looks like
• Your mailboxes move too
• 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 the plan is coming up for renewal, 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 and the database to a private staging address on our servers, and set up your mailboxes here; the mail itself moves in its own order, described below. 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, and if your mail lives at the old host, it has already been copied into the new mailboxes. 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 and at least a week after the mail has moved.

Most moves are finished within a day of us getting access. Larger or more tangled sites take longer, and we say so up front.

Your mailboxes move too#

Every plan includes mailboxes on your own domain, so your mail can move with the site, and moving it is part of the free migration. From another cPanel host the mailboxes come across with the rest of the account in one transfer, passwords, forwarders and filters included. From anywhere else we create the mailboxes here and copy the mail over IMAP, which needs each mailbox's password, or a reset.

Mail can't be staged like the site, so it follows its own order: the mailboxes are created and tested here, the mail is copied, the MX record or the nameservers switch, a final copy catches whatever arrived in between, and the old mailboxes stay open for a week. One trap is worth knowing. If the old host ran your mail under a name inside your own domain, such as mail.yourcompany.com, switching the nameservers sends incoming mail to us at once, so the mailboxes here must exist first. If it used a name of its own, your mail stays with the old host after the switch and stops when that hosting is cancelled. We check which case yours is before anything switches. Mail already at Microsoft 365 or Google Workspace stays where it is: we copy its records to our nameservers.

Contacts and calendars don't travel over IMAP, and we don't move them separately either, so export those yourself while the old account still opens.

If you'd rather put your mail on Microsoft 365 or Google Workspace, for shared calendars, Teams or shared drives, we move it there instead: an IMAP copy brings your mail and folders across, and we set up SPF, DKIM and DMARC on the new DNS records. If those mailboxes need to stay inside the EU, say so when you first write; the region is usually chosen while the account is being created, so it's worth confirming rather than assuming. Options and prices are on the 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, on hardware we run ourselves — which is usually the part your own customers ask about. What your privacy policy then has to say depends on your whole stack rather than on your host alone, and we went through how to work that out 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 if you manage the server side yourself, Managed if we do. Current prices for every plan and billing term are on the pricing page. Pay monthly or for 12 or 24 months, cancel renewal whenever you like, and there's a 30-day money-back guarantee if the move doesn't work out for you.

Update, 17 September 2026: the paragraph above used to quote plan prices and say that we never offer discounts. Our pricing has changed, so we took both out. A 12 or 24-month plan can now start at a discounted price for its first term, once per customer on a new order, and then renews for the same term at the renewal price shown when you order. If a renewal will cost more than you last paid, we email you at least 30 days before it. Current prices are on the pricing page.

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.