Cloud Migration

Migrations go wrong in predictable ways

Someone finds a service nobody documented, mid-cutover. A hardcoded hostname points at the old environment. DNS TTLs were never lowered, so half your users stay on the old system for a day. The rollback plan turns out to depend on something already deleted.

All of these are preventable, and none of them are architecture problems.

How we run them

We map dependencies first — including the informal ones, like a cron job on somebody’s laptop or a report that reads the production database directly. That map is usually the most valuable single artefact of the project.

Then we move in slices with a working result at each milestone, rehearse the cutover against realistic data, and keep the old environment ready to take traffic until you decide to switch it off. Lowering DNS TTLs a week ahead costs nothing and saves the worst kind of day.

Off a PaaS that got expensive

Heroku, Render, Vercel and friends are excellent until the bill outgrows the convenience. Moving off is mostly about replacing the invisible parts — managed Postgres, log drains, review apps, TLS — rather than the application. We price that honestly up front, including what you lose, so the decision is made on real numbers.