Inventory, plan, rehearse, cut over and verify. We migrate websites, applications, databases and email with a rollback plan for every step.
A migration fails when it is treated as copying files. The risky parts are what you forgot: a cron job, a hard-coded IP address, an email setup, a certificate, DNS caching. We start with an inventory of everything the system actually does, then rehearse the move before touching production traffic.
We handle cPanel account moves, VPS-to-VPS migrations, moves from physical or hosted servers to the cloud, and application moves onto AWS. Free website migration is included with our hosting plans. Larger application migrations are scoped to the project. See Case Study 1 and Case Study 4.
WordPress and other sites, with files, databases and configuration.
Account transfers between cPanel/WHM servers, including email and SSL.
Node.js, Python, PHP and containerised applications, with their dependencies.
Servers and applications moved onto EC2, ECS or Fargate with infrastructure as code.
MySQL, MariaDB and PostgreSQL moved with consistency checks.
Mailboxes and DNS records moved in the right order so mail keeps flowing.
| Approach | What changes | Best when |
|---|---|---|
| Rehost | Same application, new server | You want a fast move with minimal change |
| Replatform | Move to a managed database or containers | You want less operational work without a rewrite |
| Refactor | Redesign for cloud-native services | The application itself needs to change |
| Retire or retain | Switch off or leave in place | Not everything should move |
The aim is to do the slow work early and leave a short, rehearsed window for the final switch. For databases that cannot tolerate a write freeze, we use replication or AWS Database Migration Service to keep source and target in sync until cutover.
# 1. Lower the DNS TTL a few days before cutover (for example to 300 seconds)
# 2. Initial sync while the old server is still live
rsync -aHAX --numeric-ids --info=progress2 /var/www/ user@new-server:/var/www/
# 3. At cutover: pause writes, run a final delta sync, dump and restore the database
mysqldump --single-transaction --routines --triggers appdb | gzip > appdb.sql.gz
# 4. Point DNS at the new server and verify before decommissioning the old oneInventory the application, data, email, DNS, scheduled tasks and dependencies.
Choose the strategy, the cutover window and the rollback criteria.
Set up the new environment, ideally as code.
Copy data, test the new environment and fix what the rehearsal finds.
Switch traffic in the agreed window.
Confirm everything works end to end, then decommission the old environment.
Something else on your mind? Message us and an engineer will answer.
Ask a QuestionOften none to a few minutes for read-heavy sites. For write-heavy databases there is usually a short write freeze, and we agree the window with you in advance.
Not if mailboxes and MX records are moved in the right order. We test delivery before and after the switch.
Yes, including from shared hosting and other cPanel servers.
The old environment stays intact until the new one is verified, so rollback is usually a DNS change.
Tell us what you are moving and where to, and we will outline a plan.