White paper — Cloud transformation: a roadmap for large groups

White paper · April 2026

Cloud transformation: a roadmap for large groups

Migrate less, transform better, pay the right price

"The question is no longer should we go to the cloud: most groups are halfway there, and it is precisely that mid-river position that costs the most. This book is written to get out of it, in one direction or the other, but by decision."

4 destinies

5 phases

6 drifts

For every application in the estate: replatform, buy, rebuild or leave, with the sorting grid

The wave-by-wave roadmap, from foundations to run, each phase with its exit threshold

The ones that cost group programs millions: the signal that betrays each, the move that corrects it

For executive committees, group CIOs and finance departments, with five briefed trade-offs, a cloud doctrine to copy, the committee's five numbers and a self-assessment.

Contents

Foreword 03 The five trade-offs your committee must settle 04 Three readings of this document 06 1 Mid-river Why group programs bog down · Where the cloud money goes · Three group profiles 07 2 Four destinies for every application The estate sorting grid · Legacy and the mainframe · Sovereignty and regulated data 11 3 The roadmap in five phases Foundations · Proving wave · Industrialization · FinOps from day one · The cloud run, each phase with its exit threshold 15

4 Six drifts worth millions The clockwork migration · The unpiloted bill · The powerless control tower · Skills rented for life · Multi-cloud on principle · The migrated zombie app 20 5 Teams, vendors, governance The platform team · Retrain rather than replace · Standing up to hyperscalers and integrators · The cloud doctrine to copy 24 6 Year 1 of the program The Q1-Q4 timeline · The executive committee's five numbers 28 Moving to execution 30 Appendix · The twenty-question self-assessment 31

The stance

The cloud is neither a destination nor a religion: it is an operating model, and it only pays back what you transform. Migrating an estate as-is means moving your technical debt into a more expensive building. This document sorts first, migrates second, and counts all the way.

Foreword

Year three of an industrial group's "Move to Cloud" program: 30% of the estate migrated, twice the budget consumed, and a crisis meeting whose agenda fits on one line: the cloud provider's monthly bill has just overtaken the cost of the old datacenter, which is still running, since 70% of the estate remains to migrate. Nobody underperformed: the teams migrated what migrated well, the integrator hit its milestones, the hyperscaler delivered its credits. The program itself was badly framed: a removal was bought, a transformation was needed.

We find this scenario, with variations, in most of the large groups we meet: neither at the start nor at the finish, but mid-river, where you pay for two infrastructures, two operating models and two sets of skills. This document is written to get out of it. Its conviction: a cloud transformation is won before the first migration, in the sorting of the estate, the team model and financial discipline, and it is measured in value transformed, never in servers moved.

A word on our position: we design, deploy and operate platforms for our clients, in the cloud when it is the right choice, elsewhere when it is not; we resell neither hyperscaler capacity nor licences. That leaves us free to write what follows: that some applications have no business in the cloud, that reversibility is negotiated before signature, and that the bill is steered like a P&L, not endured like a month-end fate.

How to use it. The chapters stand alone; page 6 offers three readings by role. In a hurry? The five trade-offs (p. 4-5), the roadmap (ch. 3) and year 1 (ch. 6) carry the essentials. And if only one thing should survive this read: the four-destiny sorting of chapter 2. It is what separates the programs that finish from the ones that bog down.

Enjoy the read, and may your next cloud meeting talk about value transformed, not servers moved.

Cédric Guittard

Anna Hoang

cedric.guittard@clarendis.com

anna.hoang@clarendis.com

for the Clarendis team · April 2026

The five trade-offs your committee must settle

A group cloud transformation is not one decision, it is five, often made by default, therefore badly. Here they are, briefed: the two paths, our position, and the chapter that equips it.

1 · Migrate everything, or sort first?

ch. 2

"100% cloud in three years" makes fine announcements and poor programs: it condemns you to migrate as-is, that is, to pay for technical debt at cloud rates. Our position: sort the estate into four destinies before any volume commitment. Part of the estate is better off where it is, and saying so early frees the budget for what genuinely transforms.

2 · The mover's speed, or the transformer's?

ch. 1, 3

Wholesale lift-and-shift goes fast, then costs dearly forever: oversized machines, licences rolled over, zero elasticity. Wholesale rebuilding transforms everything, and never finishes. Our position: replatform by default, rebuild what differentiates, move as-is only what is going to be switched off. Speed is measured in value transformed per quarter.

3 · One hyperscaler, or several?

ch. 4, 5

Multi-cloud "on principle" doubles the skills to build, the baselines to secure and the negotiations to run, for a reversibility that is mostly theoretical. Our position: one main provider chosen hard, real reversibility (infrastructure as code, exportable data, exit costs priced in the contract), and a second cloud only where a named requirement imposes it : regulatory, sovereignty, or a service unavailable elsewhere.

4 · Buy the skills, or build them?

ch. 5

Outsourcing everything goes fast the first year; then the group discovers it no longer knows how to operate its own system, and every change goes through a purchase order. Our position: the integrator to accelerate, never to own. An internal platform team from day one, the retraining of infrastructure teams as a worksite in its own right, and a dated skills-transfer contract with milestones that get billed if missed.

5 · The bill at the finish line, or cost inside every decision?

ch. 3, 6

In the old world, cost was decided every five years, when machines were bought; in the cloud it is decided every day, in every architecture and every environment left running. Waiting for the bill to care is steering by the rear-view mirror. Our position: FinOps is not a control team bolted on at the end. It is cost made visible to whoever creates it, from the first wave : every expense tagged and attributed, every team in front of its own meter.

What this document leaves aside, and why

The hyperscaler comparison (their services converge; your criteria, locations, compliance, negotiated pricing, are specific to your case), the tool catalogue (it expires in eighteen months), and the ideological cloud-versus-datacenter debate (the right answer is a portfolio, not a camp). What remains is what does not expire: the sorting, the order of phases, cost discipline, the team model.

The question that settles everything else:for this application, what does the cloud change for the customer or for the P&L, and how will we see it in a year? An application with an answer is a transformation worksite; an application without one is a removal, and a removal can wait, or never leave.

Three readings of this document

Depending on the chair you occupy at the committee, the same document does not read in the same order, nor with the same question in mind.

Executive committee

The five trade-offs (p. 4-5) → ch. 1 → ch. 6. Mid-river will tell you where your program stands and what staying there costs; year 1 gives you the five numbers to demand every quarter.

35 minutes. The question: where does the money go?

This week: ask for the total monthly cloud + datacenter cost and its twelve-month trend. If nobody can produce it in one meeting, trade-off 5 is your emergency.

Group CIO

Ch. 2 → ch. 3 → ch. 5. The four-destiny sorting is your framing tool; the five phases, your program plan; the teams chapter, your HR and procurement file. It decides whether the group will know how to operate what it builds.

Full read. The question: in what order?

This week: put the four-destiny question to your ten most expensive applications. The result always surprises, and structures everything else.

Finance department

Ch. 1.2 (where the money goes) → ch. 3.4 (FinOps) → ch. 4 (the drifts). You will find the three typical waste items, the cost-attribution model, and the six drifts, four of which read directly off the bill.

30 minutes. The question: who steers the cost?

This week: ask what share of cloud spend is tagged and attributed to a named team. Below 80%, nobody steers; people observe.

Your program is already bogged down

Ch. 1 (locate the bog) → ch. 4 (name the drift) → ch. 2 (re-sort what remains). Recovering a program does not mean starting over: it means re-sorting the backlog with the four-destiny grid, and often removing a third of it.

The recovery path

Chapter 1

Mid-river

1

Why large groups' cloud programs bog down a third of the way across, where the money really goes, and three group profiles to locate yours before resuming the march.

1.1 Why it bogs down: the mechanics of the river

Group cloud programs almost all follow the same curve. Year one: euphoria. The easy applications migrate quickly, the provider's credits soften the bill, the milestones are green. Year two: the pace breaks. What remains are the applications that talk to the mainframe, those whose vendor no longer exists, those nobody dares touch. Year three: mid-river. Two infrastructures paid in parallel, two operating models, teams torn between the old world they must maintain and the new one they must learn. This is when committees ask "where are we?", and the honest answer is: at the most expensive point.

The cause is almost never technical. It lies in the order of decisions: a volume target was set ("80% of the estate by 2027") before the estate was sorted, the integrator was chosen before the team model, the consumption commitment was signed before anyone knew how to consume. Every decision taken out of order gets paid for mid-river. That is where this chapter begins, because that is where most of our readers are.

This book's reversal: the way out of the river is not to migrate faster, it is to shrink what remains to migrate. Removing from scope what has no business there (ch. 2) shortens the bridge faster than any integrator reinforcement.

1

1.2 Where the cloud money goes: the three leaks every bill hides

The cloud bill of a mid-river group almost always contains a quarter to a third of avoidable spend, not through negotiation, but through hygiene. Three leaks dominate, and each can be measured in a few days with the provider's own tools:

Typical share of avoidable spend (mid-river group, reconstructed from our case files)

Inherited oversizing (machines copied as-is)

~12%

Forgotten environments (tests, demos, finished projects)

~8%

Licences and options rolled over unexamined

~6%

Orders of magnitude observed on our recovery cases. Your split will differ, rarely the total. The exact measurement is the phase 4 exercise (ch. 3).

These leaks share one origin: in the cloud, spending no longer has a physical guardrail. In the datacenter, the machine ordered in excess was visible: it had to be received, plugged in, given a rack. In the cloud, it gets created in three clicks, bothers nobody, and bills forever. The guardrail must therefore be rebuilt elsewhere: in the mandatory tag, the per-team budget, the automatic shutdown of environments, the whole discipline of phase 4.

The double-edged argument: that avoidable quarter is the best news in the file. It is program self-financing asleep inside the bill. But it can only be recovered once: recovering it without installing the discipline that keeps it from returning is bailing without plugging.

1

1.3 What the cloud really changes, and what it does not

The sales pitch promises agility, innovation and savings; the field delivers something else, precious, but only if named exactly. What the cloud really changes: lead time (an environment in minutes instead of weeks, the most under-exploited gain and the first of the five numbers in ch. 6), elasticity (paying for the peak only when it happens: decisive for seasonal loads, indifferent for flat ones), managed services (databases, queues, AI: years of engineering rented by the hour), and cost visibility (every euro attributable to a team and a use, if the discipline to read it is installed).

What it does not change: a badly designed application remains badly designed, more expensive even, since its defects bill by the hour; a siloed organization remains siloed, the cloud just gives it more modern silos; a security debt remains a debt, exposed faster, since everything sits one DNS entry from the public network. Hence the rule that structures chapter 2: the cloud amplifies what you bring to it. You only send what you have decided to transform, or what is already sound.

Where the cloud almost always wins

Where you should put the pen down and calculate

Variable or seasonal loads, new digital products, analytics and AI, disaster recovery, anything that lives in standard SaaS, and development environments, first beneficiaries of the minutes-long lead time.

Flat, heavy 24/7 loads (pay-as-you-go compute costs more than the amortized machine), massive datasets that leave often (egress fees add up), stable legacy that will be switched off in three years, and everything regulation assigns to a territory.

The word this document will no longer use: "migration". A successful group program contains migrations, SaaS purchases, rebuilds, shutdowns and assumed stays. The right word is portfolio, and it is managed as one: by dated trade-offs, not by slogan.