DNS not prepared
TTLs left long, so traffic keeps hitting the old server for a day after you thought you were done.
[ Servers & DevOps / Server Migration ]
Change hosts without losing anything.
The application usually moves fine. What breaks is email delivery, the cron job nobody documented, and the redirect map that was never written. I plan for those before touching DNS.
Rehearsed first · Old host kept live · Fixed price
Rehearsedbefore go-live
Old hoststays up as fallback
Minutesof downtime typical
Fixedprice, no hourly creep
[ Why moves go wrong ]
The things that break, every time.
Six failure modes account for nearly every migration that ends badly.
Data written after the copy
Orders, signups and messages that landed on the old host post-snapshot, and were never carried over.
Email delivery collapses
Sender records not updated, so transactional mail silently starts landing in spam.
Forgotten background jobs
Cron tasks and queue workers that existed only on the old box, discovered when reports stop arriving.
Rankings drop
URLs changed or redirects missed, and organic traffic takes months to recover.
No way back
Old environment torn down immediately, so when a problem surfaces on day three there is nothing to fall back to.
[ How it works ]
Inventory, rehearse, switch.
01 — Day 1-2
Inventory
Everything on the current host cataloged: services, versions, cron jobs, workers, certificates, mail configuration and integrations.
02 — Day 3-5
Build & rehearse
The new environment built and a full dry run performed with real data, so we know exactly how long each step takes before it matters.
03 — Cutover
Switch & verify
Lowered TTLs, final sync, switch, then a verification checklist covering mail, payments, jobs and backups. Old host stays live until you are satisfied.
[ What actually changes ]
What moves, and what gets checked.
The verification checklist is the part most migrations skip, and it is the part that catches the problems.
The move
- Application files and code — with runtime versions matched, or upgraded deliberately with testing time.
- Database — replicated in advance where possible so the final sync is measured in seconds.
- Uploads and media — transferred with permissions and paths preserved.
- Cron jobs and queue workers — read off the old host directly, not from memory.
- TLS certificates and DNS — issued in advance, TTLs lowered days ahead of the switch.
Verification
- Email delivery — sender authentication records checked so mail keeps reaching inboxes.
- Redirect map — every changed URL mapped and tested before cutover, protecting search rankings.
- Payment and integration tests — live transactions verified end to end on the new host.
- Backup schedule — running and restored once on the new environment before handover.
- Rollback plan — written, agreed, and available for the whole stabilisation period.
[ Example engagement ]
Shared hosting to a managed VPS, no visible interruption.
A busy content site with mail, background jobs and thousands of indexed URLs. Rehearsed the whole migration on a staging domain first, then cut over in a low-traffic window.
Illustrative example of a typical engagement. Figures vary with the state of your systems and are not a guarantee of a specific outcome.
4 minof write freeze
0rankings lost
100%cron jobs carried over
7 daysold host kept warm
[ Free · no obligation ]
Get a migration plan first.
Tell me where you are hosted now and where you want to be. You get the approach, the realistic downtime window and a fixed price in writing.
[ Pricing ]
Pricing that fits your budget.
Tell me the number you have to work with. I'll tell you honestly what's achievable within it — and if it isn't enough, I'll say so before we start rather than halfway through.
Fixed project price
Scope agreed in writing, price agreed in writing, before any work starts. No hourly creep and no invoice you haven't already approved.
Monthly retainer
For ongoing work — maintenance, monitoring, updates and small changes. Month to month, cancel whenever, no minimum term.
Hourly for small jobs
For a single bug or a short task where writing a full scope would cost more than simply doing the work.
Budget too tight for the whole thing? I'll often suggest doing the highest-value part first and the rest later, rather than doing all of it badly.
[ Questions ]
Common questions.
How long will my site be down?
For most sites, minutes. The database is synced in advance and only a short write freeze is needed at the switch. Content sites can often move with no visible downtime at all.
Do you migrate email too?
I handle the DNS and sender authentication so delivery keeps working. Where mail is currently hosted on the same server, I will usually recommend moving it to a dedicated provider, because running your own mail server is rarely worth it.
What if the new host turns out to be worse?
The old environment stays live and reachable throughout the stabilisation period. If we need to go back, we go back, using steps written down before we started.
Can you move us between any two hosts?
Yes — shared hosting, VPS, dedicated servers and the major clouds. The process is the same regardless of provider.
Will my search rankings be affected?
Not if redirects and URLs are handled correctly, which is an explicit deliverable and verified before cutover rather than checked afterwards.
[ Related services ]
Related migration work.
Migration to AWSMove from shared hosting, a VPS or another cloud without downtime.WordPress MigrationMove hosts or domains without downtime or losing rankings.Server Setup & ConfigurationLinux servers built properly: web stack, TLS, backups, monitoring.Server Security HardeningLock down SSH, firewall, patching and access before it costs you.AWS Server SetupProduction-ready VPC, compute, database and CI/CD from scratch.WordPress Speed OptimizationFix Core Web Vitals and slow load times at the cause.
[ Let's talk ]
Tell me what's broken.
Describe the problem in a few lines and you'll get a real reply from the person who'd do the work — same working day, no discovery call required.