You own a cloud estate you did not fully design
I do not know what I do not know. I need to understand what we have. I need something I can show the board.
- An outage revealed a single point of failure nobody had documented.
- An audit, a customer security questionnaire or a regulatory obligation asked for evidence about resilience and controls.
- The cloud bill grew faster than the business.
- A funding round, acquisition or major customer needs diligence on the platform.
- A migration is being planned, and somebody sensibly wants the target designed properly.
- A new leader inherited the estate and needs an objective picture of it, fast.
- The cloud provider or a reseller suggested a review.
Most estates grew organically. That is the normal case, not the exception.
Greenfield
Implementing the Well-Architected Framework and a landing zone from the start, so the estate is designed correctly before workloads arrive.
Brownfield
Audit what is actually running, discover the workloads and systems nobody wrote down, build a plan, then implement — inside the existing estate rather than by building a new one and migrating to it.
Retrofitting into a live estate with real traffic and real constraints is harder than designing greenfield, and it is what most clients actually need.
Findings by risk, then three, six and nine month horizons
Horizons rather than products — they are shaped per client. A sequenced plan with named owners is something you can take to leadership. A list of two hundred findings is not.
Scoped either to the estate or to one system, across AWS, Azure or Google Cloud.
The judgement about which twenty findings out of two hundred actually matter for this business.
Sized and sequenced to a target state, so the work survives contact with an existing roadmap.
Which items are ours and which belong to your engineering teams — named, not implied.
A significant share of this is your work, and we would rather say so here
Ours: the infrastructure and platform side
We build our half. We also own the review, the plan, the sequencing and the guidance throughout.
Yours: application-level change
Making a service stateless, decoupling components, spreading across availability zones, changing how data is stored or how failure is handled. That is application engineering, and it belongs to the teams who own those services.
Not part of this engagement
We do not re-architect your applications for you here. App Modernisation exists for clients who want help with that specifically.
A page that implies a turnkey fix wins engagements that then disappoint, because the constraint is your roadmap rather than our capacity.
And we stay for the whole plan
The industry default outcome of a Well-Architected review is a document, and those documents go nowhere for a reason: the findings land as unscheduled work on teams who already have a roadmap, with no sequencing, no sizing and no owner. We turn them into horizons, name who owns each item, build the infrastructure and platform parts ourselves, and stay alongside your teams for the application work. The claim is that the plan is realistic and that we are still there in month seven.
They are not the same framework
A team fluent in one cloud's framework will quietly apply its assumptions to the others, and a multi-cloud client can tell. These are the vendors' own facts, with their sources.
AWS, plus a dedicated Well-Architected Tool where findings are recorded as high risk issues and progress is tracked through milestones.
Source: AWS Well-Architected
Azure. Its landing zone guidance is a documented reference architecture with infrastructure-as-code templates rather than a single managed service, so more of the work is assembly.
Source: Microsoft Learn
Google Cloud, named differently again — plus cross-pillar perspectives for specific domains such as AI and machine learning, and financial services.
A review from your cloud provider
Often free, and genuinely useful. The honest distinction is that it ends at the findings: the provider does not sequence the work, does not build anything, and the recommendations sit inside their own platform.
A large consultancy
Will produce a thorough report. Frequently a different team, or no team, does the remediation.
Self-assessment
The provider tooling is free and a competent team can work through it. What is usually missing is not the checklist but the judgement about which findings matter, and the capacity to close them.
Do nothing
Until an incident or an auditor forces it.
The questions we get asked
We had one done and nothing changed.
Usually true, and the diagnosis matters more than a promise: nothing changed because the findings arrived as an unsequenced list of work for teams who already had a roadmap. The three, six and nine month horizons exist to fix exactly that.
How much of this is our work rather than yours?
A significant share of it. Infrastructure and platform remediation is ours. Application-level changes, which is where a lot of Well-Architected findings lead, belong to the teams who own those services. Saying so here costs a few leads who wanted turnkey and saves every one of those engagements from disappointing later.
Our cloud provider will do it for free.
They might, and it is genuinely useful. The distinction is remediation: they end at the findings, and we stay through the delivery period.
Isn’t it just a checklist?
The framework is a checklist. The engagement is the judgement about which findings matter for this business, and the work to close them.
Our environment is too messy to assess.
That is the usual starting point, and the reason the brownfield path exists.
We’re not big enough for this.
There is no real size floor here. One important workload justifies a review.
Will this turn into a compliance audit?
No. A Well-Architected review is not a SOC 2 audit, a HIPAA attestation or a regulatory sign-off. It can materially help you prepare for one, and that is a different thing.
Book a Well-Architected review
Scoped either to the whole estate or to one system. What makes the plan fundable is that it arrives sequenced, sized and with owners named.
- Findings prioritised by risk
- A three, six and nine month plan to a target state
- An honest split of which items are ours and which are your engineering teams’
- Us building the platform side, and staying through the delivery period