On this page
What a server migration involves
Moving to a new server looks like copying files. In practice, the risk is in everything you did not know was there: a cron job that sends invoices, a mail forwarder, a service installed years ago, a database that must be dumped separately, or grants that disappear when data is restored. Server migration is the careful process of finding all of it, moving it and switching over without losing data.
We treat a migration as a project with a plan, a rehearsal, a cutover window and a rollback option, rather than a weekend of trial and error.
Common reasons to migrate
- Moving from shared hosting to a VPS or cloud server for performance or control.
- Changing providers to reduce cost, move closer to your users or get better support.
- Replacing an old server running an operating system that no longer receives updates.
- Consolidating several scattered servers, often for an agency with many client sites.
- Moving a SaaS application from a single server to a more resilient setup.
What’s included
- Inventory of applications, databases, cron jobs, services, mail, certificates and DNS.
- Full backup of the source server, including separate database dumps.
- New server built and hardened to match or improve on the old one.
- Staged synchronisation of files and data, with a final sync at cutover.
- Database restore with users, permissions and grants verified.
- DNS cutover with TTLs lowered in advance.
- Testing plan covering key pages, logins, payments, email and scheduled jobs.
- Rollback plan and the old server kept running until you sign off.
Our migration process
- Discover: inventory everything running on the source server and agree what moves.
- Prepare: build the new server, back up the old one and lower DNS TTLs.
- Rehearse: perform a trial migration and test the application on the new server using a hosts-file override.
- Cut over: during an agreed window, pause writes, run the final sync and switch DNS.
- Verify: test key functions from outside and watch logs and monitoring closely.
- Decommission: only after you confirm, retire the old server, keeping a final backup.
Tools and platforms
We migrate between Hostinger VPS, DigitalOcean, Hetzner, AWS, Google Cloud, Azure and other providers, and from shared hosting and control panels. Typical tools include rsync for files, native dump and restore for MySQL, MariaDB and PostgreSQL, Docker for repackaging applications where useful, and Cloudflare or your DNS provider for a fast, controlled cutover.
What affects timeline and cost
A single website with one database is a short project. Time grows with the number of applications and domains, database size, email hosted on the same server, undocumented services, control panel differences and how small the acceptable downtime window is. You will pay both providers for a short overlap period while both servers run.
Every migration ends with a short handover: what moved, where it lives now, what changed along the way and what was deliberately left behind. That record makes the new server easier to manage than the old one ever was.
The inventory checklist
Most migration problems come from something that was not on the list. Our inventory goes beyond the website files and covers the things that are easy to forget:
- Every website and application, with its runtime version and dependencies.
- Every database, its size, users and permissions.
- Cron jobs and systemd timers for every user, not just root.
- Environment files and secrets stored outside the application directory.
- Mailboxes, forwarders and scripts that send email through the local server.
- SSL certificates and how they currently renew.
- Firewall rules, allowed IPs and any integrations that whitelist the old server’s IP address.
- DNS records for every domain and subdomain pointing at the server.
- Background workers, queues and anything started manually that will not survive a reboot.
That last group of IP-based integrations is often overlooked. Payment gateways, partner APIs and mail providers may only accept traffic from your old server’s address, so they need updating before cutover or the new server will be silently rejected.
Common mistakes
- Wiping the old server before confirming everything on the new one works.
- Relying on a file backup that did not include a proper database dump.
- Forgetting cron jobs, mail forwarders or environment files that lived outside the web directory.
- Using a sync with delete options that overwrites server-only configuration files.
- Changing DNS without lowering TTLs first, so visitors are split between servers for hours.
Related: Backup Solutions, Domain Configuration and Application Deployment. See Cloud & Server Management, the cloud and server guide, or contact us.
Frequently asked questions
How much downtime should we expect?
For most migrations, downtime is planned and usually measured in minutes rather than hours. Some setups can move with no visible downtime at all.
Can you migrate our email too?
Yes, if it is on the same server. Mailboxes and mail records need their own plan so no messages are lost during the switch.
What happens if something goes wrong?
The old server remains intact, so we can point DNS back to it while the issue is fixed.
Can you migrate from shared hosting with a control panel?
Yes. We export sites, databases and mail from the panel and rebuild them on the new server.
Will our IP address change?
Almost always, yes. That is why we check for integrations, payment gateways and email providers that allow-list your IP, and update them before cutover.
Talk to us about server migration
Move to new hosting with minimal downtime and nothing left behind.