Infrastructure Migration

I move the platform with a plan for downtime, the data, and the first week after cutover.

What I do

The move, with a cutover plan

I move what you run now, usually onto AWS, with a plan for the cutover.

Which room goes away

If two rooms are doing one job, I plan which one goes away and when.

A row check, not a hope

The database moves with a row check, not a hope.

What you get

A planned window

I name the window before we pick a night.

The first week after

The plan covers downtime, the data, and the first week after cutover.

Who can reach it during the move

The temporary path used for the copy should not stay open afterward.

After cutover

I watch the new side for a week: errors, cost, and the thing that got slower.

How the work goes

What moves, and the rollback

I write down what moves, what stays, and how we roll back.

The order and the window

You get the order, the window, and what we do if the cutover fails.

Check the data before traffic

I move it in the window, and check the data before traffic follows.

The first week

I watch errors and the bill for the first week, and fix what got slower.

Tools I use

These show up when they fit the job.

AWS Migration Hub logoAWS Migration Hub
Azure Migrate logoAzure Migrate
Google Cloud Migrate logoGoogle Cloud Migrate
VMware vSphere logoVMware vSphere
Terraform logoTerraform
Ansible logoAnsible
Docker logoDocker
Kubernetes logoKubernetes
CloudEndure Migration logoCloudEndure Migration
Carbonite Migrate logoCarbonite Migrate
Velostrata logoVelostrata
AWS Migration Hub logoAWS Migration Hub
Azure Migrate logoAzure Migrate
Google Cloud Migrate logoGoogle Cloud Migrate
VMware vSphere logoVMware vSphere
Terraform logoTerraform
Ansible logoAnsible
Docker logoDocker
Kubernetes logoKubernetes
CloudEndure Migration logoCloudEndure Migration
Carbonite Migrate logoCarbonite Migrate
Velostrata logoVelostrata

Situations I get called in for

Everything runs on one old server

The app, the database, the cron jobs, and the uploaded files share one VPS or one box in a rack. It has to move to AWS without losing any of them.

The database is too big for dump and restore

A full dump takes longer than any window you can accept. The data has to replicate ahead of time, so cutover only carries the last changes.

Moving between AWS accounts or regions

The workload grew up in a shared or personal account and now needs its own. Snapshots, keys, DNS, and IAM all have to cross that line.

The last attempt was rolled back

A cutover was tried, something broke, and the team went back. I find out what failed before we plan the next window.

What I check first

DNS TTLs, days ahead

Resolvers keep the old answer for as long as the old TTL says. I lower the TTL well before cutover, so the switch takes minutes and a rollback does too.

Replication and a row count

For a live database I use AWS DMS or native replication: a full load, then ongoing changes. MySQL needs row-based binary logging for that. Before traffic moves, I compare row counts and run DMS validation.

Snapshots and KMS keys

An RDS snapshot encrypted with the default AWS managed key cannot be shared with another account. If the data is crossing accounts, it needs a customer managed key first.

Hardcoded addresses and allowlists

A partner or payment provider may allowlist your old outbound IP. The new NAT gateway has a different Elastic IP. They need it before cutover, not after.

Jobs and files that must run in one place

Cron jobs and files written to local disk are easy to miss. During cutover each job runs on exactly one side, or it runs twice.

If the platform has to move, plan the first week after cutover.

Questions people ask