Cloud Architecture & Migration
We design the architecture your workload actually needs, then move it there without asking your users to wait.
Plan a migration ↗
What does a cloud migration actually involve?
A cloud migration is mostly inventory and sequencing, not clever engineering. Before anything moves you need to know what’s really running, what talks to what, and which of it nobody has touched in three years. The lift itself is usually the short part; the discovery is where projects go wrong.
The design question underneath is how much you change while you move. A straight lift-and-shift is fast and cheap, but it carries your old inefficiencies onto a metered bill; re-architecting everything at once turns a two-month project into a year of it. We normally move first, prove the new environment, then modernise the two or three services where it genuinely pays.
What a migration engagement covers
Workload inventory
Every service, cron job, queue and database mapped with its dependencies. Nothing should be discovered for the first time on cutover night.
Target architecture
Network, compute and data design sized to your real traffic rather than your peak fear, with the reason for each choice written down.
Data migration plan
Replication running ahead of time so the final sync is minutes, not a weekend spent restoring a dump and hoping.
Infrastructure as code
The target environment defined in Terraform, so it can be reviewed, diffed and rebuilt instead of remembered by one person.
Cutover rehearsal
At least one full dry run into a staging clone, timed end to end, with the rollback path proven before the real thing.
Runbooks and handover
Written procedures for deploys, backups, scaling and the three most likely failure modes, walked through with whoever holds the pager.
How a migration runs
Audit what’s running
A week or two reading configs, traffic patterns and invoices to produce a dependency map and an inventory you can argue with.
Design the target
We size the new environment against measured load, price it before you commit, and mark what stays as-is versus what gets rebuilt.
Build it in parallel
The new environment goes up alongside the old one in code, with data replicating, while production carries on untouched.
Rehearse the cutover
A full dress rehearsal with a written runbook, a timer, and the rollback executed at least once so we know how long it takes.
Cut over and watch
DNS or traffic shifts in stages with the old environment kept warm for a fortnight. We stay on for the first month of real load.
Cloud Architecture & Migration FAQ
Most single-application moves land between $10k and $35k; a multi-service estate with databases and queues runs higher. We scope after the audit, in writing, and the audit is priced separately so you can stop there if the numbers don’t work.
The tools we build with
We favour platform primitives and portable tooling over anything that would need re-learning in two years or re-writing to leave.
Cloud platforms
AWS
GCP
Cloudflare
NginxInfrastructure as code
Terraform
Ansible
Docker
Kubernetes
HelmData & state
PostgreSQL
MySQL
Redis
ElasticsearchVisibility
Grafana
Prometheus
OpenTelemetry
SentryRelated work
Related reading
Outgrown where you’re hosted?
Send us what you’re running and where it lives. We’ll come back with a target architecture, a cutover plan, and an honest estimate of the bill afterwards.