M.6Bloom · AnNot started

How long, what it costs, and how to staff it

Reading depth

What you'll learn

Give a driver-based range (≈12 months for a very large estate, less for smaller ones), expect much custom code to be dead and retirable, and fund a small protected capacity with named owners rather than a one-off push.

  • Duration is a driver-based range, not a fixed date — anchor ~12 months for a very large (~4M-LOC) estate, less for smaller or cleaner ones.
  • The biggest sizing surprise is usually upside: much custom code is dead and can be retired, not migrated.
  • The cost lever leadership controls is reserved, protected capacity — a steady cadence beats a heroic push.

'How long will this take and what will it cost' is the first question leadership asks, and the honest answer is a range tied to a few measurable drivers — not a fixed date. A useful anchor: a very large estate (around four million lines of custom code) moving to S/4HANA is typically framed as roughly a twelve-month programme, while a smaller or cleaner estate is much less. What moves the number is how much custom code is actually used (most organisations find a large share is dead and can simply be retired), how many modifications and old-style integrations exist, and how much is already on supported interfaces.

The cost lever leadership actually controls is reserved capacity. Clean Core competes with the feature backlog, so if no team time is ring-fenced for it, it never happens. A small, steady, protected allocation — rather than an occasional heroic push — is both cheaper and more predictable, because it lets the work run as a routine cadence and keeps the findings burndown trending down instead of sawing up and down.

Staff it as a thin, cross-functional team with named owners, not a side task bolted onto everyone's day job. The technical depth lives with the developers — the delivery module (m14) covers their side — while leadership's job is to fund the capacity, set the phases with clear exit criteria, and hold the duration as a living estimate that updates each sprint from the actual fix rate.

Key points

  • Duration is a driver-based range, not a fixed date — anchor ~12 months for a very large (~4M-LOC) estate, less for smaller or cleaner ones.
  • The biggest sizing surprise is usually upside: much custom code is dead and can be retired, not migrated.
  • The cost lever leadership controls is reserved, protected capacity — a steady cadence beats a heroic push.
  • Fund a thin cross-functional team with named owners; don't run it as a side task.
  • Hold the duration as a living estimate that updates from the burndown each sprint.

Examples

Steady capacity versus a heroic push

Ring-fencing 15% of a team every sprint clears debt predictably and keeps the burndown falling; an annual two-week 'cleanup sprint' spikes, then the line climbs again as feature work re-adds debt.

Source notes: clean-core-curriculum (business synthesis)

Ask Claude

Build a prompt from this lesson + your question and open a fresh Claude chat with it pre-filled — handy for adapting a before/after pattern to your own object.