Cloud
Decide what runs where, before anything moves.
Most cloud regret traces back to an architecture decision taken under deadline pressure. Consulting is where we take that decision apart with you — what moves, what gets rebuilt, what stays where it is, and what each of those costs to run.
- Target architecture
- Landing zone
- Well-Architected review
- Migration sequencing
- Cost model
- Multi-cloud
- Governance
- Exit plan
What we hear
The conversations that start a consulting engagement.
Three teams, three clouds, and nobody owns the bill.
CIO
The architecture diagram is two years old and nobody trusts it any more.
Head of Platform
I need a plan the board will sign off, not a vendor pitch.
IT Director
Four ways it shows up
Which question you are actually asking.
Consulting covers a lot of ground. These are the four shapes the work usually takes, and they need different people in the room.
Which platform, and why
A reasoned choice between AWS, Azure and Google Cloud — or a deliberate decision to run more than one — argued from your workloads, your team’s existing skills and your commercial agreements, not from a partner tier.
Closing the gap to where you are going
Where the current stack will not carry the next two years, we say which parts and what replaces them. Useful when the pressure to modernise is real but the sequence is not yet obvious.
A sequenced plan, not a wish list
For estates at the start of the journey: what moves first, what it unblocks, what has to happen in parallel, and where the plan should be allowed to change.
Making what you already run cheaper
For estates already on cloud: right-sizing, commitment coverage, storage tiering, idle and orphaned resource recovery, and the architecture changes that take cost out permanently rather than for one quarter.
What you get
Documents your team can act on without us.
Every engagement ends in artefacts, not a presentation. You own all of them whether or not we do the delivery work.
- Target architectureDiagrams plus the decision record behind them — what was considered, what was chosen, and what would make that choice wrong later.
- Landing zone designAccounts and subscriptions, network boundaries, identity, logging and policy guardrails, defined as code rather than as a checklist.
- Migration sequenceOrdered by risk and by what it unblocks, with the dependencies and the rollback for each wave written down.
- Cost modelWhat you spend now against what the target costs to run, including commitments, data transfer and the period where you are paying for both.
- Governance and guardrailsWho can provision what, tagging and cost attribution, and the controls your security and audit functions will ask for.
- Named risksThe parts we are least confident about, what would resolve them, and what we would do if the assumption turns out to be wrong.
What it should produce
Five things that change downstream.
Deployments that stop being events
Environments defined as code, so a release is routine rather than scheduled.
Applications modernised, not just moved
Re-platforming where it pays for itself, lift-and-shift where it does not.
Governance your auditors accept
Policy, tagging and attribution in place before the estate grows, not retrofitted after.
Security designed in
Identity, boundaries and secrets handled in the architecture rather than patched at the edges.
A bill you can explain
Cost attributable per team and per workload, so optimisation has an owner.
Selected work
What changed, in the client’s terms.
Three recent engagements from this practice.
A two-week paid pilot
Fixed price, on a real piece of your backlog. You keep the output whether or not you continue.