Cloud & Platform
Moving systems that
cannot afford to stop
Migration is a scheduling and data problem long before it is an engineering one. We plan in waves, cut over inside windows measured in minutes, and keep the old estate warm until the new one has survived a full month-end close.
Overview
Wave-planned migration of running systems, with a rollback path we have actually tested.
The seven Rs are a useful vocabulary and a poor plan. What actually decides a migration is dependency order, data gravity and who is available at 2am on a Sunday. We begin by building a dependency map from network flow data rather than from the architecture diagrams, which are usually two reorganisations out of date.
Applications are grouped into waves that can move together without half a transaction living in two places. Each wave gets its own cutover runbook, a rehearsal against production-scale data, a defined rollback trigger and one named person allowed to call it. Roughly one rehearsal in eight finds something the design review missed, which is the point of running them.
We are candid about rehosting. Lifting a workload unchanged onto cloud infrastructure rarely saves money by itself; it buys a deadline for the data centre exit and a platform on which refactoring becomes possible. Where a business case depends on immediate savings, we say so before the contract is signed, not in month nine.
- 11 min
- median cutover window across 40-plus production applications
- 1 in 63
- wave cutovers rolled back, each recovered inside its window
- 23%
- lower run cost after the first post-migration optimisation pass
Capabilities
What this covers
Six areas we staff properly. If your problem sits outside them, the honest note at the foot of this page says so.
Discovery and dependency mapping
Agent-based and flow-log discovery across servers, databases and integrations, reconciled against the CMDB. The output is a dependency graph, not an inventory spreadsheet with 400 unowned rows.
Wave planning and sequencing
Applications grouped by transactional coupling, change freeze calendars and team availability. Each wave carries an entry test, an exit test and a rollback trigger agreed in writing beforehand.
Database and data migration
Change data capture through DMS, Debezium or native replication, cutting over once replication lag sits under a defined threshold. Row counts and checksums reconciled before traffic moves.
Replatforming where it pays
Moving to managed databases, containerising stateful services, replacing bespoke schedulers with the platform's own. Scoped per application against a return, never applied across the estate as policy.
Cutover execution and rollback
Runbooks rehearsed at least twice and executed against a live decision log. Rollback stays available until the agreed soak period ends, which is normally one complete month-end cycle.
Decommissioning and exit
The part most programmes skip. Asset retirement, licence reclamation, contract termination dates and written confirmation that nothing in the estate still calls the old endpoint.
Deliverables
What you get
- Dependency graph and per-application disposition register
- Wave plan with sequencing, freeze windows and rollback triggers
- Cutover runbooks with rehearsal results and measured timings
- Data reconciliation reports for every migrated datastore
- Post-migration performance and cost baseline against the previous estate
- Decommissioning schedule with licence and contract termination dates
Stack
What we build it with
- AWS Application Migration Service
- AWS Database Migration Service
- Azure Migrate
- Debezium
- Oracle GoldenGate
- Terraform
- Ansible
- Kubernetes
- PostgreSQL
- Flyway
- Datadog
- Google Migrate to Virtual Machines
Process
How the engagement runs
Two-week increments against a written definition of done. You can stop at any increment boundary and keep everything built so far.
Instrumented discovery
Four to six weeks of measured discovery. Flow logs, agent data and interview notes are reconciled until the dependency graph stops changing week to week.
Disposition and business case
Each application receives a disposition and a cost model. Anything where the numbers do not work is flagged before it enters a wave, not after it has moved.
Pilot wave
A low-risk but genuinely representative wave moves first, including at least one database. Timings from this wave calibrate every estimate that follows it.
Production waves
Waves run on a fixed cadence, typically fortnightly. Each closes with a soak period and a retrospective that updates the shared runbook template.
Exit and decommission
Old infrastructure is powered down in stages rather than deleted. Licences are reclaimed and contracts terminated against a tracked schedule.
When this is the wrong engagement
If the estate is due for replacement by a package or SaaS product within two years, migrating it first spends the money twice, and retiring it is the cheaper path.
FAQ
Questions we get asked
- Should we refactor during the migration or after it?
After, in almost every case. Changing the runtime and the code at once means that when performance regresses you cannot tell which change caused it. The exception is an application that will not run on the target at all, and that one gets its own separate timeline.
- How long does a mid-sized estate take?
For 150 to 250 applications, plan on 14 to 20 months from discovery to data centre exit, with production waves running fortnightly. Discovery alone takes six weeks. Anyone quoting a fixed duration before seeing your dependency graph is guessing.
- What happens if a cutover fails at 3am?
The runbook names one person with authority to roll back and a hard decision point, usually 40 minutes before the window closes. Rollback is rehearsed as thoroughly as the forward path, and the old environment keeps running until the soak period ends.
- Can you migrate systems we have lost the source code for?
Sometimes. Rehosting a binary onto equivalent infrastructure often works; the risk is licence terms tied to hardware identifiers and undocumented file paths. We test these in a sandbox during discovery and give you a clear yes, no, or only with the vendor involved.
Related
More in Cloud & Platform
Cloud & Platform
Cloud Solutions
Landing zones, account structure and cost guardrails, designed before workload one.
Cloud & Platform
AWS Services
AWS engineering from Organizations and Control Tower down to Graviton instance sizing.
Cloud & Platform
Azure Services
Azure for organisations with Active Directory, auditors and an on-premises estate to keep.