Where this came from

These are the conversations we keep having.

Every team, stack and history is different. Our job is to help you find where you are, plan the route, and get you there.

Most estates sit at several of these at once. If you have already run a program and it did not land, you are probably not at stage one.

Eight stages

Cloud adoption

01/08

We never agreed what this is for

Stage one · Strategy

Agreeing what the move is actually for, in terms someone can be held to.

You are probably here if
  • Cloud spend was approved without a stated outcome other than "We need it" or "it will save us money"
  • Different teams give you different answers about why
  • The business case has not been opened since it was signed off
  • You cannot measure if it is working out for you.

What usually goes wrong. The case gets written for the approval meeting and then filed. Six months in, nobody can say whether a decision is on-plan, because the plan was never in a form you could check anything against.

You are past this when. One page names the outcome, the number, the date and the owner. You have a clear mandate, with teams that can speak to that mandate and measure themselves against the KPIs established.

What you need to think about
  1. 01

    What done looks like

    A date, a number, and a name against it.

  2. 02

    Why cloud

    A stated reason for moving, building or running here that holds up when someone asks it in a board meeting.

  3. 03

    What it is not for

    The workloads that stay put, written down early, so the list stops growing.

  4. 04

    Who signs off

    One executive who can say no. Programs with two sponsors have none.

What comes nextStage two, where the inventory tests whether the case survives contact with the estate.

See how a program gets defined
02/08

Nobody can tell me what we run, and why we run it.

Stage two · Discovery

Building the single list of what you run, what it costs and who owns it.

You are probably here if
  • Nobody can say how many subscriptions you have without going to look
  • Resources exist that no current employee claims
  • Your last inventory was a spreadsheet... it has aged

What usually goes wrong. Teams ask for resources to be built by a ticket, the SLAs for the team executing on the ticket are about resolution time, not right sizing or right scoping the solution. This results in big servers, many servers, and very rarely financial stewardship. The estate is always bigger than the org chart. Resource Groups and resources opened for a project that ended. Resources whose owner left two reorganisations ago. Most teams cannot produce this list on demand, which is why week one of any engagement goes into building it.

You are past this when. Every subscription, resource and owner is documented in one place, and it refreshes itself. Your tagging can be trusted, and confidently shows ownership.

What you need to think about
  1. 01

    Every subscription

    Not the three someone remembered, including the ones nobody claims.

  2. 02

    Who owns each thing

    A person, not a team. Teams do not answer tickets.

  3. 03

    What talks to what

    Dependencies set the migration order and are what nobody has written down.

  4. 04

    How to make owners care

    Chargeback may not be the answer, but showback and accountability usually travel together.

What comes nextStage three, whether the people you have can run what you are about to build.

See what the assessment reads
03/08

We are planning for a team we do not have

Stage three · Capability

Comparing what the plan needs your people to do against what they do today.

You are probably here if
  • The team runs VMs well and has never run a cloud platform
  • Changes get made by hand in the portal, because that is the route everyone knows
  • Training is budgeted as a line item rather than as time
  • The team operates entirely through tickets, and nobody spends time looking for the patterns and the common cases.

What usually goes wrong. The gap gets treated as a training problem and answered with a course. What closes it is doing the work beside someone who has done it before, on your own estate, which is slower to start and the only version that holds. The DORA 2025 finding is the blunt form of this: a new tool does not fix a team, it amplifies what is already there.

You are past this when. You have not heard "that is how we have always done things" for several months. Your team is confident enough to propose new innovative solutions. Your team can break things safely. Your team is confident in the roadmap and understand how they will bridge the gap. The people who will run this have built part of it, and the plan has been resized to what they can operate.

What you need to think about
  1. 01

    What the plan assumes

    The skills the design takes for granted, written down before anything gets built.

  2. 02

    Click-ops is a symptom

    If the portal is the only route anyone knows, the pipeline will not get used.

  3. 03

    Learning on your own estate

    A course teaches the concept. Doing it here teaches the estate.

What comes nextStage four, the structure new work lands in.

Talk to us about the team you have
04/08

Every team builds it a different way

Stage four · Landing zone

Deciding the structure new workloads land in: management groups, policy, identity, network, SKUs, Tagging conventions.

You are probably here if
  • Teams do not deploy with pipelines and standard resource definitions.
  • There is no default that makes the right thing the easy thing
  • Policy exists as a document rather than as a control

What usually goes wrong. The landing zone gets built, then quietly bypassed, because the fast path around it is the one that ships. Six months later the exceptions are the architecture. You have 30 different versions of a VM running. 20 different database deployment models. A net new File Share.

You are past this when. A new workload lands compliant by default, and the team building it can see why.

What you need to think about
  1. 01

    Management groups and policy

    The rails a new workload lands inside without anyone deciding to.

  2. 02

    Identity first

    Who and what can act, settled before there is anything to act on.

  3. 03

    An expressway

    A fast, consistent, secure and opinionated route that enforces the standard and takes less thought than going around it.

What comes nextStage five, who and what can reach it once it exists.

See who builds it and who owns it after
05/08

Access only ever gets added

Stage five · Access

Working out what every person, service and agent can reach today, and cutting it back to what someone will defend.

You are probably here if
  • You cannot answer “who can reach production” without asking someone
  • There are service principals nobody will delete, because nobody knows what breaks
  • People have left, their accounts are gone, and the access they were granted is not

What usually goes wrong. Granting access is a ten-minute ticket. Taking it away is a decision someone has to sign, and the only reliable way to find out what breaks is to break it. So permissions accumulate for years, and what any one account can reach stops being something anyone can describe.

You are past this when. Every standing permission has a named owner and a stated reason, and the ones that had neither are gone.

What you need to think about
  1. 01

    Standing access

    Permanent rights are the ones that get inherited. Anything permanent needs a reason you would say out loud.

  2. 02

    Machine identities

    They outnumber your people, they never leave, and their credentials rarely rotate.

  3. 03

    Auditing

    Can you see what an account actually used, and what has not been touched in a year?

  4. 04

    What an assistant would inherit

    An agent runs as something. This stage decides how far that something can reach.

What comes nextStage six, moving the work in dependency order.

See what the access assessment reads
06/08

Everything moves. Nothing gets retired.

Stage six · Migration

Naming what moves, what gets rebuilt and what gets switched off, and finding the dependencies before the cutover finds them.

You are probably here if
  • The migration list keeps growing and nothing has come off it
  • Cutover dates slip because a dependency surfaced in the final week
  • Everything is being lifted as-is, because rebuilding needs a decision nobody will own

What usually goes wrong. Lifting is the default because it requires no decision. Rebuilding and retiring both need someone to say no. So the estate arrives intact, including the parts that should not have come, and the savings the business case promised were sitting in the parts nobody retired.

You are past this when. Every workload is on exactly one of three lists, the order follows the dependency map, and the cutover has been rehearsed.

What you need to think about
  1. 01

    Move, rebuild, retire

    Three lists, every workload on one of them. The third is where the business case was.

  2. 02

    The order

    Set by what depends on what, discovered before the cutover rather than during it.

  3. 03

    The day itself

    Rehearsed, with the rollback written down and the people who will be awake for it in the room.

What comes nextStage seven, finding out before your customers do.

Ask us what you would retire first
07/08

We hear about outages from customers

Stage seven · Operations

Getting monitoring to the point where it tells you something before a customer does.

You are probably here if
  • You have heard about an outage from a client first
  • Alerts fire constantly and the team has learned to ignore them
  • Nobody can list your tier-one services from memory

What usually goes wrong. Alert volume everyone has learned to ignore, and coverage that looks complete precisely because the gaps do not alert. Muting gets treated as tuning. The honest test is not how many monitors exist. It is how many have ever led to someone doing something.

You are past this when. Every tier-one service has an owner, a target, and an alert that has changed a behaviour.

What you need to think about
  1. 01

    What tier one actually is

    An owner, a target, and an alert somebody has acted on.

  2. 02

    Alerts nobody acts on

    Muting is not tuning. Count the ones that changed a behaviour.

  3. 03

    The gaps that do not alert

    Silence looks like health right up until it does not.

What comes nextStage eight, explaining the bill and handing the platform over.

See the observability health check
08/08

The bill grows and nobody can say why

Stage eight · Cost and ownership

Making the bill explainable by team, and handing the platform to people who can run it.

You are probably here if
  • Finance asks who spent this and the answer takes days
  • Spend grows faster than usage and nobody can say why
  • The platform still depends on one or two individuals, or on an outside firm

What usually goes wrong. Untagged spend has no owner, so nobody argues to cut it and it compounds quietly. And the handover arrives as a document instead of something your engineers execute. The team that cannot explain the bill is almost always the team that does not own the platform.

You are past this when. The bill splits by team without manual work, and your engineers run the platform unaided.

What you need to think about
  1. 01

    Where the money goes

    By subscription, service, team and environment, on a schedule.

  2. 02

    What has no owner

    Untagged spend nobody argues to cut. It compounds quietly.

  3. 03

    Running it without us

    The handover is something your engineers execute, not a document they receive.

  4. 04

    Are the commitments being used?

    Whether the savings plans and reservations you already bought are actually being drawn down.

What comes nextCloud is a journey, now it is time to see how you can improve further, build faster, build better. If AI is the next question, it starts at stage one on the other journey.

See the FinOps assessment
Seven stages

AI adoption

01/07

People are already using it

Stage one · Shadow AI

Finding out which AI tools are already in use, by whom, and with what data.

You are probably here if
  • You have not asked, or you asked and got a suspiciously tidy answer
  • Someone has expensed an AI subscription
  • A policy exists but nobody has checked whether it is followed
  • People's emails suddenly have far fewer spelling mistakes

What usually goes wrong. By now, everyone has tried their hand at ChatGPT or Claude or CoPilot. Staff solved their own problem months ago with a browser tab and a company document. Customer information being formatted as a sales report can be productive, but it also violates your data processing agreements signed years ago. Banning it moves it somewhere you cannot see. The first real task is an inventory, not a policy.

You are past this when. You have a list of what is in use, who uses it, and what it is being fed.

What you need to think about
  1. 01

    What is already in play

    An inventory, not a policy. A ban only moves it out of sight.

  2. 02

    What is being pasted in

    Company documents into a browser tab is the common case, not the edge case.

  3. 03

    Who is paying for it

    Expense reports find the shadow stack faster than an IT audit does.

What comes nextStage two, choosing where it would actually pay.

Tell us what is already running
02/07

We are saying yes to everyone's idea

Stage two · Use cases

Choosing the few uses worth funding, and deciding now how you will measure them.

You are probably here if
  • Every department has an idea and none has a number attached
  • Pilots are funded on enthusiasm rather than on a case, and on a realistic read of what your team can do. ChatGPT to training models on your own data is a longer step than it looks
  • Nobody has said what would make a pilot a failure

What usually goes wrong. Use cases get chosen by who asked loudest. The ones that pay are boring, sit in a back office, and belong to somebody who did not attend the workshop.

You are past this when. A shortlist, each with a named owner, a baseline and a condition for killing it.

What you need to think about
  1. 01

    Where the work actually is

    The processes with volume and rework, not the ones with a sponsor.

  2. 02

    What gets measured

    Chosen now. Reconstructed later, it usually cannot be done at all.

  3. 03

    What stays manual

    Written down, so the line exists before somebody tests it.

What comes nextStage three, what an assistant would be able to see.

Talk to us about what to say no to
03/07

It will find what we forgot we shared

Stage three · Reach

Checking what an assistant would be able to surface, before you switch it on.

You are probably here if
  • You are being asked to roll out Copilot and are unsure what it will find
  • SharePoint permissions have never been reviewed at scale
  • Sharing links were created years ago and never expired

What usually goes wrong. An assistant does not create an oversharing problem. It makes a decade of accumulated permissions queryable in plain language. That is where most rollouts stall, and they stall on access nobody reviewed rather than on the assistant itself.

You are past this when. You know what it can reach, and the oversharing you cannot defend is closed.

This one has a prerequisite. It stalls without the cloud journey, stage 6: Access only ever gets added.

What you need to think about
  1. 01

    What it surfaces on day one

    Every document the asking user can technically reach.

  2. 02

    Oversharing you inherited

    A decade of sharing links, now searchable in plain language.

  3. 03

    Data classification has to be automatic

    The days of a human classifying each artifact by hand are gone. They did not work then and they will not work against this. It needs tooling, and the tooling needs to be model-backed.

  4. 04

    Who reviews before switch-on

    A named owner per site, with time in their week to do it.

What comes nextStage four, whether the data behind it can answer.

See what the access assessment reads
04/07

Every data request turns into a project

Stage four · Data

Testing whether the people and systems that need the data can actually get to it.

You are probably here if
  • Every data request turns into a project
  • The number you trust lives in a spreadsheet, not the system of record
  • Pilots stall waiting on access rather than on the model

What usually goes wrong. This is the stage almost nobody names and the one that stops the most work. Not data quality, not modelling. Plain access. And it does not improve as organisations mature, which is the part that should worry you: the companies furthest along report it at the same rate as the ones just starting.

You are past this when. The team that needs the data can get it without raising a ticket.

This one has a prerequisite. It stalls without the cloud journey, stage 3: Nobody can tell me what we run.

What you need to think about
  1. 01

    Can the team get to it

    Without a project, a ticket, or a favour.

  2. 02

    Where it actually lives

    The system of record, versus the spreadsheet people trust.

  3. 03

    What to fix first

    One unblock, sized, rather than a modernisation programme.

What comes nextStage five, the line between suggesting and acting.

Start with the estate list on the cloud journey
05/07

We have not said where it needs a human

Stage five · Guardrails

Drawing the line between what the system suggests and what it is allowed to do.

You are probably here if
  • A pilot works and nobody has written down what it may do unsupervised
  • “Human in the loop” is stated, but no named person has the time
  • You could not prove afterwards that a boundary held

What usually goes wrong. Guardrails get designed after the pilot works, which is the wrong order and the expensive one. The useful question is not what the model can do. It is what you are willing to let it do unsupervised, and how you would know if it went outside that.

You are past this when. The line is written per process, enforced in the system, and observable.

What you need to think about
  1. 01

    Suggest or act

    One line, written down, per process.

  2. 02

    Who approves what

    Human in the loop means a named human with time in their day.

  3. 03

    How it gets checked

    A guardrail you cannot observe is a hope.

What comes nextStage six, what you would let run without a person in the loop.

Ask us where a person stays in the loop
06/07

I cannot tell what it did or why

Stage six · Agents

Giving anything that acts on its own an identity, permissions and an owner.

You are probably here if
  • Something automated runs under a person's account
  • You cannot tell from a log whether a person or software acted
  • Nobody is certain who would switch it off

What usually goes wrong. Agents inherit a person’s access because that is the quickest way to make them work. Then nobody can tell, after the fact, whether an action was taken by a colleague or by software running under their name. The two questions to be able to answer are who did this, and should that have been allowed.

You are past this when. Every agent has its own identity, least-privilege access, and an owner who has used the off switch.

This one has a prerequisite. It stalls without the cloud journey, stage 6: Access only ever gets added.

What you need to think about
  1. 01

    Its own identity

    Not a person’s account, or nobody can tell who did what.

  2. 02

    Its own permissions

    Scoped to the task, revoked when the task ends.

  3. 03

    The off switch

    Someone owns it and has used it in a drill.

What comes nextStage seven, whether any of it paid.

Start with access on the cloud journey
07/07

I cannot show what we got for it

Stage seven · Value

Producing a number that survives a board conversation.

You are probably here if
  • You are asked what the AI spend returned and the answer is anecdotal
  • No baseline was taken before the pilots started
  • Renewals are approved without a result

What usually goes wrong. Most organisations believe it is working and cannot show it. The gap between the two is where budgets get cut. Measurement designed in at stage two is cheap; measurement reconstructed at stage seven usually cannot be done at all.

You are past this when. One number, tied to a line in the business, that finance recognises.

What you need to think about
  1. 01

    The number for the board

    Tied to a line in the business, not to hours saved in the abstract.

  2. 02

    What stopped

    Cost avoided is easier to defend than value created.

  3. 03

    What gets cut

    Pilots killed on a checkpoint, rather than quietly renewed.

What comes nextNothing after this one. If the answer was no, the honest next step is back to stage two.

Talk to us about the number you need
Why two

AI foundations usually rest on mature technology practices.

That runs from data governance, security and cost management through to a team enabled and responsible enough to experiment safely and meaningfully. Where a foundation is missing, we would rather say so early than bill you to find out.

How we work

Three models of engagement.

Whether you know where you are or want help working it out, each model brings its own team.

Advisory

Fixed fee, fixed duration

Discovery and assessment. We read the estate and hand back a ranked register: a dollar value, an effort grade and a named owner per item, plus an agreed first action before we leave the room.

Forward deployed

Day rate, embedded

One of ours inside your team. On your board, in your standups, with commit rights and an opinion. You are buying judgement in the room, not a report about the room.

Build and deploy

Program definition, then delivery

We define what gets built and in what order, build it alongside your people, and treat the handover as the acceptance test. If your engineers cannot run it without us, it is not finished.

You already have a partner.

Most estates this size do, and we are not here to replace them. We are usually brought in for a defined piece of work an incumbent is not set up to do, alongside the people already running the platform. The handover at the end goes to your team, or to them.

The offer

Where we start depends on where your biggest problems are.

Four ways to begin, depending on which problem is loudest.

  • Azure FinOps AssessmentWhere the money goes and what to cut first. Two weeks, fixed fee, every subscription in scope, and a ranked register with a dollar value and a named owner per item.
  • Observability Health CheckWhether you will know before your customers do. Two weeks, fixed fee.
  • Azure Governance and Access AssessmentWho can reach what, and what an assistant would inherit. Policy, roles and identity, handed back as a ranked action plan.
  • Azure Build and SupportWho builds the platform and who owns it after. A program definition first, then embedded delivery.
Talk to us