Thirty-four teams run their own CI/CD pipelines and the platform's pipeline covers 11 of 45 services. You have four platform engineers, no authority to mandate anything, and one year. Sequence the consolidation so that every step is reversible and the programme can stop at any point with the estate still working.

The sequence

1. Measure before offering anything. Derive lead time, change-failure rate and median pipeline duration per team from git and deploy data you already have, and publish it per team. This costs two weeks, needs nobody's permission, and it is what tells you which teams have a problem worth solving. Reversible by definition.
2. Take one step, not the pipeline. Pick the stage every team hates and nobody wants to own - image signing, release notes, secret injection - and ship it as something callable from their pipeline. Adoption of a single callable step is a two-line change, which is the only size of ask that works without authority.
3. Run the platform pipeline in shadow for three volunteer teams: it builds and tests on every commit and deploys nothing. Divergences are your defect list, and you fix them rather than asking teams to.
4. Do the migration for them. A platform engineer performs the first cutover for each team, in their repository, with their on-call present. Four engineers can realistically do one of these a week while keeping the lights on.
5. Make the platform path the default for new services once it has 10 real users. New services are free adoption; existing ones are expensive.
6. Freeze feature work on the old path with a date, published with the usage numbers from step 1 so it reads as a consequence rather than a threat.
7. Decommission only when telemetry shows zero runs for 30 days, including monthly jobs.

Where it can diverge and how you would know

The dangerous divergence is behavioural, not structural: the old pipeline deploys with a flag the new one does not set, or runs a test suite with a different timeout. Shadow mode catches it only if you compare the produced artefacts byte for byte, not merely the exit codes. Keep a per-team dashboard of deploy count by pipeline so a team that quietly reverts shows up within a day rather than at the decommission meeting.

The point of no return

Step 7. Everything before it leaves both paths working. Delete the old pipeline's credentials and you have removed a team's ability to ship on their worst day, so the irreversible step comes last and is taken per team, never fleet-wide.

How long it really takes

Thirty-four teams at roughly 3 days of their time plus 2 days of yours is about 170 engineer-days of migration work on top of running the platform. Expect 60 to 75% by month nine and a long tail of five or six teams with genuine reasons - a Windows build, a regulated release process, a team mid-reorganisation. Budget the tail as permanent rather than as failure.

Common weak answers

• "Ask the CTO to mandate it." A mandate converts a product problem into a compliance problem, delivers coverage without benefit, and destroys the only honest signal you had.
• "Build a converter that translates their config." You now own 34 configurations forever and have made the old path cheaper to keep.
• "Big-bang over a weekend." Thirty-four teams cannot be rolled back on a Monday morning.