The window was too short
Nobody timed how long the database copy actually takes, so the cutover ran past sunrise.
[ AWS & Cloud / Migration to AWS ]
Move to AWS without the weekend of terror.
Migrations fail on the details: DNS TTLs nobody lowered, a database that took longer to copy than the window allowed, a rollback plan that existed only in someone's head. I plan for all three and rehearse the cutover before it counts.
Rehearsed cutover · Written rollback plan · Fixed price
Rehearsedbefore the real cutover
Rollbackplanned and tested
Minutesof downtime, not hours
Fixedprice agreed upfront
[ Why migrations go wrong ]
The six failures I plan around.
Nearly every painful migration I have been called in to rescue failed for one of these reasons.
DNS was not prepared
TTLs left at 24 hours, so traffic kept arriving at the old server for a full day after the switch.
Data drifted during the copy
Orders placed on the old system after the snapshot, and lost forever at cutover.
No rollback plan
When something broke at 3am the only option was to fix forward, badly, under pressure.
SEO damage
Redirects missed, URLs changed, and organic traffic dropping for months afterwards.
Secrets left behind
Hardcoded credentials and cron jobs on the old box that nobody knew about until they stopped running.
[ How it works ]
Rehearse first. Cut over second.
01 — Week 1
Discovery
Everything on the current environment inventoried: services, cron jobs, background workers, certificates, integrations and the credentials holding them together.
02 — Week 2-3
Build and rehearse
The target environment built on AWS, then a full dry-run migration with real data. We time every step and fix what turns out to be slow.
03 — Cutover
Switch and verify
Lowered TTLs, final sync, switch, verification checklist. The old environment stays online and reachable until we agree the new one is stable.
[ What actually changes ]
What gets migrated.
The application is the easy part. These are the pieces that get forgotten and cause the incident three days later.
The move
- Application and runtime — matched versions, or a deliberate upgrade with testing time budgeted.
- Database — replicated live where possible so the final sync is seconds, not hours.
- File storage and uploads — moved to object storage with the paths rewritten correctly.
- Cron jobs and workers — inventoried from the old box, not from what people remember.
- Certificates and DNS — issued, validated and TTLs lowered days before the cutover.
Getting it right
- Full dry run — the entire migration rehearsed on real data before the real date.
- Written rollback plan — the exact steps and the decision point for using them.
- Redirect map — every changed URL mapped so search rankings survive the move.
- Post-cutover checklist — email delivery, payments, integrations, background jobs, backups.
- Old environment kept warm — nothing decommissioned until you say the new one is stable.
[ Example engagement ]
Legacy VPS to AWS, cut over in minutes.
An application on an ageing single server with manual backups, moved to a multi-AZ environment. Database replicated live so the final switch needed only a short freeze.
Illustrative example of a typical engagement. Figures vary with the state of your systems and are not a guarantee of a specific outcome.
9 minof write downtime
0records lost
100%redirects preserved
1rehearsal before go-live
[ Free · no obligation ]
Get a migration plan before you commit.
Tell me what you are running now. You get a written plan with the approach, the realistic downtime window and a fixed price.
[ 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 much downtime will there be?
For most applications, minutes rather than hours — the database is replicated in advance so only a short write freeze is needed at the switch. Sites that can tolerate read-only mode can often cut over with no visible interruption at all.
Can you migrate from another cloud provider?
Yes. Moves from other major clouds, VPS providers and shared hosting all follow the same process. The provider changes; the discipline does not.
Will our search rankings be affected?
Not if the URLs and redirects are handled properly, which is an explicit part of the work. A redirect map is built and verified before cutover, not improvised afterwards.
What happens if something goes wrong?
We roll back. The old environment stays running and reachable throughout, and the rollback steps are written down and agreed before we start, along with the point at which we would use them.
Do you migrate email as well?
Mail is usually best moved to a dedicated provider rather than run on your own servers. I will handle the DNS records and the sender authentication so delivery does not break during the move.
[ Related services ]
Related migration work.
Server MigrationMove hosts without losing data, email or search rankings.AWS Server SetupProduction-ready VPC, compute, database and CI/CD from scratch.WordPress MigrationMove hosts or domains without downtime or losing rankings.AWS Cost OptimizationCut your monthly bill 30-60% without re-architecting.Server Security HardeningLock down SSH, firewall, patching and access before it costs you.DevOps ConsultingDeployment, reliability and process for teams without a DevOps hire.
[ 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.