A transition plan is a schedule of dates on which capability leaves the building. Read it as a list of departures rather than a list of activities and most such plans fail on sight. The failure is that every borrowed capability comes back on the same day, because that is the day the contracts were written to end, and nobody compared the dates to each other.
A global payments acquirer and processor was folding a fragmented set of brand and business-unit websites onto one shared estate and needed an operating model to run the result. The pack that came back has a transition section, and inside it one plain slide lists every dependency the programme had beside the date it ends. It is the most useful page in the document, for a reason nobody intended: put the end dates in one column and the problem stops being arguable.
The challenge
The engagement covering digital leadership, programme management, technical leadership, and user and customer experience design was due to finish on the day the site was scheduled to go live. The creative and build partner's main work was scheduled to finish on the same day, with a mop-up sprint of two weeks already inside the contract, due to start the day after. The third relationship, hosting, was contracted for twelve months and was the only one with continuity past launch.
So the capabilities that decide what gets built, in what order, and whether it is safe to release were all scheduled to expire on one date, while the capability that keeps the servers running had a year on the clock. That is not a considered allocation of risk. It is what you get when each contract is scoped against the launch milestone independently, and the milestone is all they share.
Two conditions made the date worse. The operating model meant to receive those responsibilities had been presented but final approval was not yet confirmed, so on the planned departure date there was no approved structure to hand anything to, and the roles that were in place carried an acknowledged mix of gaps and upskilling. The launch itself was an acknowledged compromise on the level of sophistication delivered, described in the pack as a minimum viable product. That is defensible until the deferred work lands on the week the capacity to do it disappears.
The pack is honest about the second-order effect. Requirements for the next releases would be difficult to write before launch, because the same individuals were working to the launch. The people who could specify what came next were committed to shipping what came now, and were then scheduled to leave.
The approach
What this pack did well was refuse to pretend the gap away. It named a transitional period running from launch to a point three to four months later, for three stated reasons: momentum on the site had to continue, the operating model still had to be approved and populated, and the remaining sites were now migrating in phases across roughly four months rather than in one cutover. Phasing a migration quietly creates a period in which two ways of working run at once. Here, at least, somebody sized it.
Inside that window it listed eleven workstreams, among them standing up three governance bodies from nothing, documenting the prioritisation and content workflow processes, taking technical ownership of the site in-house for the first time, and finishing the permanent operating model itself. The six-step sequence is worth copying: technical handover comes second and governance third, while executive sign-off of the future model comes last. The platform is live either way, so somebody has to be able to answer a call before anyone has finished arguing about the organisation chart.
Then it priced the thing. One full-time role to set up and run the three governance groups, with programme office support. One to map and document the processes and train staff on them. One holding technical ownership and the supplier relationships. One analytics resource. About half a role across best practice and policy. One to two days a week across two months to finish the org design, plus programme management to deliver it. That is roughly four and a half full-time roles across the first five of those, before the org-design time is counted and before any release delivery at all, for a window of three to four months, against a permanent model whose whole net effect was one to two extra roles, and which reached even that figure only because two existing roles were being removed elsewhere.
The bridge cost several times the destination. Business cases get written against the steady state, because that is what the board asked about, and the crossing is left inside somebody's day job.
The resourcing table has one more feature most do not. Almost every activity carries at least two named options side by side: do it internally, in several cases with additional training attached, or hand it to a partner. Nothing defaults, so speed or capability gets chosen knowingly, activity by activity. On the technical ownership row the partner option is written as carrying out the role and doing the knowledge transfer, which is the only place in the table the transfer is named at all. Knowledge transfer written as a line in an options column is still only an intention. It becomes real when it leaves a trace the receiving team can read after the author has gone.
The sharpest sentence in the pack is about people rather than suppliers. Continued support could be arranged with the same individuals, but the decision had to be confirmed very quickly to avoid losing key individuals who had built deep knowledge and relationships. The asset at risk was never the contract. It was the set of heads holding why a decision was made, which supplier to call, and what breaks when a given thing changes. A supplier can be re-signed. The people disperse within days.
The outcome
This is a plan and a set of options, put up for approval because it carried budget and people implications. Three capability areas were listed as available internally straight away, and the third of those only as a possibility and only with training. The rest, the pack says, would have to be resourced, with governance set-up, requirements and prioritisation, programme management and policy work among the examples given. Nothing in the pack confirms that the launch happened on the planned date, that any engagement ended, or that the resourcing was funded.
Three things would be done differently now. First, the exit gets staggered at signature rather than negotiated in the last fortnight. Not one end date but a ramp, each capability handed to a named owner on its own date with a deliberate overlap, so the receiving owner runs the thing once while the person who built it is still reachable.
Second, the handover becomes an artefact instead of a meeting. Most of what a departing team knows is already visible in the systems they operated: deployment history, the ticket trail, the workflow events. In the Platform work we do, process mining over those events, plus honest lineage for what feeds what, hands the receiving team a description of how the estate behaves rather than of how it was meant to.
Third, the training happens before the departure date. The internal option carries a training caveat on three separate rows of that column, which reads as prudence and functions as a wish: training scheduled after the teacher leaves does not happen. Capability has to be built on the programme's own material while the programme is still running, so that the upskilling has a source at all.
The same pattern runs through machine learning delivery, unchanged apart from vocabulary. A partner builds the pipeline, the model is deployed at roughly the date the partner rolls off, and six months later nobody can say why those features were chosen or what the retraining trigger was meant to be. Most of what MLOps is for is moving knowledge out of heads and into pipelines, feature definitions and lineage that outlive the engagement. The cautious language-model pilots we are asked about now keep the same clock, with evaluation and escalation filed under phase two, the phase that starts the week the team leaves.
A plan that returns every borrowed capability on one date is not a transition. It is the date an organisation finds out what it never learned to do.