CLOUD AND INFRASTRUCTURE
Cloud migration without a big bang
The cutover weekend is the most dangerous way to migrate. Slices are slower on paper and faster in practice.
SERVICE 01
Infrastructure that stops being the reason things are slow.
Migration, architecture and cost work on systems that are already carrying real traffic. The goal is usually not elegance — it is a platform your team can operate on a Tuesday afternoon without holding its breath.
THE PROBLEM
The bill grows faster than the traffic, and nobody can say which part
Infrastructure problems are rarely one big thing. They are a decision made under deadline three years ago, a service that was never decommissioned, an instance sized for a launch that did not happen, and a query nobody has looked at since it was written.
The common failure is jumping straight to a rewrite or a migration without measuring first. That tends to move the problem somewhere more expensive, and it costs a quarter to find out.
WHO IT IS FOR
Who cloud and infrastructure is designed for
Teams with a cost problem
The cloud bill is climbing and the finance conversation is getting harder to postpone.
Teams with a reliability problem
Incidents cluster around the same few services and the fixes keep not sticking.
Teams planning a migration
You know you need to move, and you want to know what it actually involves before committing.
Teams without a platform person
Nobody owns infrastructure, so it is whoever last touched it, which is nobody.
WHAT IT INCLUDES
What this work may cover
Not every engagement covers all of it. The shape depends on what you are deciding.
Architecture review
What the system is, what it depends on, and where the single points of failure actually sit.
Cost analysis
Where the money goes, broken down far enough to act on rather than to worry about.
Migration planning
What moves as-is, what gets rebuilt, what gets switched off — and in what order.
Delivery
Doing the work in reversible slices, with your engineers, not in parallel to them.
Observability and runbooks
Monitoring that tells someone something useful at 3am, and documentation that matches reality.
THE FRAMEWORK
How the work is sequenced
- 01
Inventory
What exists, what talks to what, and what nobody has owned for a while.
- 02
Measure
Cost, latency and failure data, before anyone proposes anything.
- 03
Rank
Fixes ordered by impact against effort, including the ones that are a config change.
- 04
Deliver in slices
Each one reversible on its own, so a bad week stays a bad week.
- 05
Hand over
Runbooks, alerting and a walkthrough with the people who will carry the pager.
ILLUSTRATIVE EXAMPLE
A SaaS product whose infrastructure bill doubled while revenue grew by a third
A constructed example to show the shape of the work, not a client case study.
- 1
Tag and attribute spend properly — about a week, and often the single most useful thing.
- 2
Find the three line items that account for most of the increase.
- 3
Fix the cheap ones first: oversized instances, forgotten environments, missing lifecycle policies.
- 4
Decide whether the expensive one justifies architectural work or just a bigger cache.
- 5
Leave a cost dashboard and an alert so the next drift gets caught in a week, not a year.
RELATED READING
Worth reading alongside this
CLOUD AND INFRASTRUCTURE
The cheapest fix is usually configuration
Before the architecture conversation, check the settings. A surprising share of production pain is a default nobody changed.
WORKING TOGETHER
How to brief a consultancy
The brief determines the outcome more than the firm does. Bring the problem, not the solution.
QUESTIONS
Common questions about this work
Which cloud do you recommend?
Usually the one you are already on. Multi-cloud and migration-between-clouds are expensive answers that most organisations do not need, and the switching cost rarely gets recovered.
Can you guarantee a cost reduction?
No. We can tell you what is driving the bill and what each fix is likely to be worth, and that estimate improves a lot after the measurement phase. Anyone promising a percentage before looking is guessing.
Do we have to stop feature work?
Usually not entirely. Sequencing the work so delivery continues is part of the planning, and it is a constraint we would rather hear in week one than week six.
Start with a measurement, not a migration
A short assessment tells you which problems are worth money and which are worth ignoring.