The migration finished. The workloads moved. The Cloud Business Office (CBO) signed off the milestones, the steering committee thanked the program team, and the executive sponsor moved on to the next portfolio priority. Eighteen months later, the returns the business case projected have not appeared. Throughput improved during the migration; it has flattened since. Cost is higher than the pre-migration estimate, not lower. New capabilities the platform was supposed to enable are scoped as separate programs and delivered on the same eighteen-month cycle the migration ran on.
This is not unusual. It is the typical pattern for organisations whose primary cloud migration completed between two and four years ago. The platform is working. The governance around it is producing diminishing returns.
The Cloud Business Office is a transition instrument, not a permanent body
A Cloud Business Office is a transition instrument. AWS, which originated the term, defines it as a cross-functional body that “establish and agree bold objectives and principles” and acts “to encourage the enablement of the workforce to adopt Cloud at scale” (Allen, 2018). Its constituent representatives across security, legal, procurement, risk, operations, business lines, HR, and architecture are seated together because cloud adoption requires aligned decisions across functions that do not usually decide together. The body removes blockers, sets standards, and arbitrates between competing demands during a period of rapid structural change.
AWS is also explicit about when the CBO ends. Jonathan Allen’s foundational article notes that the Cloud Business Office “should continue until the ‘right time'”, specifically when the organisation has achieved material cloud workloads and a strong migration cadence with reduced need for blocker removal (Allen, 2018). The office is, by design, temporary.
What tends to happen instead is that the Cloud Business Office persists. The meetings continue. The reporting line stays in place. The CBO that governed the transition continues to govern the platform, and the structural features that made it the right instrument for adoption become the wrong instrument for operation.
Three CBO structures that enabled migration now block ongoing value
Feature #1: Project-shaped funding
The first is the funding model. CBO oversight is structured around projects: scoped initiatives, with start and end dates, business cases approved against milestones. The Project Management Institute defines a project as “a temporary endeavor undertaken to create a unique product, service, or result” (Project Management Institute, 2021). That definition was correct for the migration. Moving workloads is a temporary act with a defined end state. It is wrong for the platform that resulted. A cloud platform creates value through continuous evolution. Workloads are tuned, new services are adopted, security posture is improved, cost is optimised, and capabilities are extended in response to what the business learns from running on it. Each of these is ongoing and structurally incompatible with project-shaped funding. Mik Kersten named the mismatch directly in his work on the Flow Framework, framing the structural shift from project-centric to product-centric delivery as the central decision facing technology organisations after their major build phase (Kersten, 2018).
Feature #2: Practice-area teams
The second is the team structure. A Cloud Business Office and the Cloud Centre of Excellence (CCoE) that often sits underneath it organise people by practice area: security, networking, FinOps, platform engineering, governance. The practice-area model is correct during adoption, because the work to be done is the work of standing each practice up. It is the wrong model for operation. Value from a running platform is delivered when product teams can request a new capability and receive it as a versioned, supported service, rather than filing a request that is routed through five practice areas, each with its own queue, each treating the request as a project. This is the same structural failure pattern that affects any operating model built around technical affinity rather than value flow.
Feature #3: Project-completion metrics
The third is the measurement regime. CBOs report against adoption KPIs: workloads migrated, percentage of estate in the cloud, compliance with security baselines, training completed. These are the right measures for a transition. They are not measures of value. AWS makes the distinction explicit in its prescriptive guidance: “the CCoE is not a Cloud Operating Model. It is a cross-organizational leadership function that supports successful cloud adoption across the enterprise through alignment, enablement, and automation” (Amazon Web Services, n.d.). The Cloud Operating Model measures different things, organises people differently, and funds work differently.
Project funding blinds the CBO
None of this surfaces while it is happening. The Cloud Business Office continues to function, papers continue to flow, KPIs continue to be met. What appears eighteen months after migration close is a quieter pattern. Every new capability needed by the business is scoped as a separate project, funded through a separate business case, and delivered on a separate timeline. The platform that was meant to compound value is being managed as though it were still a build.
What makes this hard to identify from inside is that nothing is failing. The CBO still works as designed. The KPIs still get met. The reports still go to the right committee. The people on the transition office are capable and acting in good faith. The constraint is not in their effort. It is in the lifecycle. The office that governed the transition is still in place after the transition has ended, doing what it was designed to do, in a context where what it was designed to do is no longer what produces value.
The decision the post-migration CIO now faces is governance redesign, not initiative selection
If the diagnosis holds, what the cloud platform needs is not a new initiative funded through the existing governance. It needs a different governance lifecycle. The question stops being “what should the Cloud Business Office approve next?” and becomes “what is the body that funds and holds accountability for the platform as a continuously improving product, and where does that body sit?” These are different questions with different structural answers, and the answer almost always involves shifting from delivery-mode to product-mode operation.
That reframe carries cost over time. Each cycle that the platform continues to be managed as a portfolio of projects compounds two losses. Capability that could have been built into the platform sits as separately-funded initiatives, and the practice-area teams optimised for adoption continue to be measured against adoption metrics that no longer move. After two or three planning cycles, the platform is structurally trapped, visible only as a cost line, not as a source of compounding return.
The point is not that the Cloud Business Office was the wrong instrument. It was the correct instrument for the period in which it operated. The lifecycle of the instrument and the lifecycle of the asset it brought online are not the same. The asset continues. The instrument that brought it online does not have to. Treating post-migration governance as a question of redesign rather than continuation is the decision; letting the Cloud Business Office drift into a permanent fixture is the cost of not making it.
The diagnostic question is concrete enough to apply this week. What proportion of the cloud platform’s capability roadmap for the next twelve months is being scoped as projects routed through the Cloud Business Office, and what proportion is being delivered by a product-funded team accountable for the platform as a whole? If the first number is substantially larger than the second, the CBO that ran the migration is still running the platform, and the value the platform was supposed to create is being decided by the wrong governance lifecycle.
Senior leaders inherit the redesign decision
- The Cloud Business Office has a defined endpoint in AWS’s own doctrine: material workloads in cloud, stable migration cadence, reduced need for blocker removal. If that threshold has been crossed and the CBO is still convening, it is operating past its design life.
- Cloud value problems eighteen months after migration are usually governance lifecycle problems. The platform is rarely the constraint; the office funding the platform is.
- Project-shaped funding and practice-area team structures are correct for adoption and wrong for operation. A platform that creates value through continuous evolution cannot be funded in eighteen-month tranches.
- The CIO’s decision is not which cloud initiative to fund next. It is whether the CBO that funds initiatives is still the right body to hold the platform.
- The diagnostic is concrete: what proportion of the next twelve months of cloud capability is being delivered as projects versus as continuously-funded product work? The ratio reveals the lifecycle problem.
References
- Allen, J. (2018, December 30). Creating the Cloud Business Office. AWS Enterprise Strategy.
- Amazon Web Services. (n.d.). Strategy for the Cloud Operating Model: Introduction. AWS Prescriptive Guidance.
- Kersten, M. (2018). Project to product: How to survive and thrive in the age of digital disruption with the Flow Framework. IT Revolution Press.
- Project Management Institute. (2021). A guide to the Project Management Body of Knowledge (PMBOK guide) (7th ed.). Project Management Institute.
