There is a particular kind of exhaustion that settles over a technology team roughly a year and a half into a platform migration — not the sprint exhaustion of a deadline, but something more chronic, more ambient, the kind that accumulates in the body the way damp accumulates in old walls. I have sat in enough post-mortems, enough steering committee rooms with the wrong people in the chairs, to know that this exhaustion is almost never caused by the technology itself. The stack is rarely the villain. What tends to break things is a set of decisions made very early — sometimes before a single engineer has been consulted — that encode assumptions about how an organisation works, what it values, and who has authority, assumptions that then have to be lived with by people who were never in the room. This essay is an attempt to think carefully about that gap: the distance between the contract stage, where everything is a slide deck and a statement of intent, and the operational reality eighteen months later, where those intentions have calcified into someone else's daily problem.
The contract as a document of optimism ¶
Every platform migration begins with a document that is, at its heart, a work of speculative fiction. Statements of work, RFP responses, vendor proposals — these are narratives about a future in which the technology works as described, the timelines hold, and the organisation receiving the new system is basically the same organisation that signed the agreement. None of those things are reliably true, and everyone in the room knows it, and yet the fiction holds because everyone needs it to. The vendor needs the deal. The internal champion needs the budget approval. The procurement committee needs the box ticked. What gets lost in that convergence of need is the harder, less comfortable conversation about what the organisation actually looks like on the inside — its informal power structures, its inherited technical debt, the three people who know where everything is buried and who are quietly planning to retire. I worked with a mid-sized public sector organisation a few years ago that had signed a ten-year infrastructure contract with a managed services provider. The contract was thorough, detailed, and almost entirely about the technology. There was a single paragraph — I counted the words once, out of morbid curiosity, there were seventy-one — about knowledge transfer. Seventy-one words to describe the process by which an organisation of four hundred people would learn to inhabit a fundamentally different operating environment.
What the Gantt chart does not contain ¶
Project plans are very good at representing sequences of technical events. They are almost entirely silent on the social and cultural conditions those events require. A task labelled 'user acceptance testing' on a Gantt chart does not contain, within its coloured bar, the information that the team expected to do that testing is also managing a regulatory submission, that their manager changed three months ago, that half of them have never used the new system's interface category before and are quietly terrified of looking incompetent. It does not contain the information that 'acceptance' in this organisation has historically meant 'we will accept whatever we are given because complaining has not worked in the past.' Project management methodology — PRINCE2, MSP, even the better-intentioned corners of agile practice — tends to treat organisational culture as a context variable rather than a primary design constraint. The timeline is built around the technology's complexity, not around the human complexity of adopting it. And so the plan proceeds, milestone by milestone, while underneath it the actual conditions of success or failure are developing on their own schedule, unmonitored and unmeasured, until they surface as a crisis with a name: 'adoption issues,' 'stakeholder resistance,' 'change fatigue.' These are not causes. They are symptoms with a very long incubation period.
Eighteen months in: what the organisation has become ¶
By the time a migration is eighteen months old, it has usually passed through at least two phases of confident announcement — a launch, a go-live, possibly a press release — and is now in the quieter, harder phase that nobody puts in the press release. What I consistently find at this stage is a kind of institutional split personality. There is the official story of the migration, which is broadly positive, reported upward, and lives in dashboard metrics that measure what was easy to measure. And then there is the lived experience of the people who actually operate the system daily, which is frequently a mosaic of workarounds, undocumented exceptions, shadow processes running in spreadsheets alongside the new platform, and a generalised sense that the organisation has traded one set of problems for a different, less familiar set. The shadow processes are the most telling detail. When people rebuild in spreadsheets what the new system was supposed to replace, they are not being obstructive — they are being rational. The new system does something the old system did not, or does a familiar thing in an unfamiliar way, and the path of least resistance is to route around it. Over time, those routes become load-bearing. They become the real infrastructure, invisible to the programme board, essential to the people who do the work.
The three decisions that tend to cause the most damage ¶
Not all early decisions are equally consequential, but in my experience three categories cause a disproportionate share of the downstream damage. The first is the data ownership decision — specifically, who owns the data model, the vendor or the client. This sounds technical and is in fact deeply political. When a vendor owns the schema, the organisation becomes dependent on the vendor's roadmap for what is fundamentally their own information. This tends not to matter in the first year, when the relationship is new and goodwill is high. It matters enormously in year three, when a business requirement emerges that the vendor has no commercial incentive to accommodate. The second is the integration decision made under time pressure. Integrations built quickly at the start of a migration — to connect the new platform to payroll, to the CRM, to the reporting layer — are rarely revisited once they work well enough. 'Well enough' calcifies. The third, and perhaps the most underappreciated, is the governance decision: specifically, which part of the organisation has authority to change the system configuration after go-live. When this is ambiguous — and it almost always is — the result is a configuration that nobody feels empowered to improve, a system that drifts further from operational reality with each passing quarter.
What doing it differently actually looks like ¶
I want to be precise here, because the advice in this space tends toward the abstract. 'Involve stakeholders early' is not advice — it is a slogan. What I mean by doing it differently is more specific. Before the contract is signed, the organisation should be able to answer three questions with genuine specificity, not aspiration. First: who will be accountable for the system's configuration eighteen months after go-live, and what authority do they have to change it without raising a change request with the vendor? Second: what does the data model look like, and under what conditions can the organisation export a complete, unencumbered copy of all their data? Third: which existing processes are load-bearing in ways that are not documented anywhere, and who holds that knowledge? That third question usually requires a few weeks of ethnographic work — sitting with the people who actually do the work, not the people who manage the people who do the work. It is slow and it feels inefficient and it is the most valuable thing you can do. The organisations I have seen navigate migrations with the least operational damage are almost universally the ones that invested in that kind of structured listening before the implementation began, and then appointed someone — a named individual, not a committee — to be responsible for the gap between how the system works and how the organisation needs it to work.
On the question of who carries the cost ¶
There is a political economy to platform migrations that rarely appears in the case studies. The decisions made at the contract stage are typically made by people who will not be present for the operational consequences — senior leaders who move on, external consultants whose engagement ends at go-live, procurement officers whose KPI was the signed contract, not the lived system. The people who carry the cost of those decisions are almost always lower in the hierarchy: the administrator who now takes forty-five minutes to complete a task that previously took ten, the analyst whose reporting process broke in a way that nobody has prioritised fixing, the IT support team fielding the same confusion calls eighteen months after launch. This asymmetry is not accidental and it is not easily solved by better intentions at the top. It requires structural accountability — specifically, the people who negotiate contracts should have some obligation to remain connected to the operational outcome, and the people who operate the system should have formal mechanisms to surface problems upward without those problems being reframed as complaints or resistance. The organisations that build those mechanisms before the migration begins are rare. They are also, in my experience, the ones whose migrations actually work.
A note on what success might actually feel like ¶
I do not think successful platform migrations feel triumphant. I think they feel, after a while, like the new system has simply become the unremarkable substrate of daily work — not loved, not resented, just there, doing what it is supposed to do, quietly, while people attend to the actual content of their jobs. That is an unsexy outcome and it is exactly the right one. The migrations I have been part of that I would call genuinely successful shared a quality that is hard to name precisely — something like institutional honesty, a willingness to keep looking at what is actually happening rather than what the programme plan said should be happening. They had people who were empowered to say, in a room where it mattered, that something was not working. They had enough slack in the process to respond when reality diverged from the plan, which it always does. They treated the period after go-live not as a wind-down but as the beginning of the actual work. And they started, always, by taking the human complexity of the organisation as seriously as the technical complexity of the platform.
I have been thinking about this essay for a long time — probably since a particular steering committee meeting in a city I will not name, where a very senior person said, with complete sincerity, that the hard part was over because the contract was signed. The hard part was not over. It had not yet begun. That is the thing I keep coming back to: the contract is not the end of the risk, it is the formalisation of it, the moment when everything that was still possible becomes fixed, and the people who will live inside that fixity start their clock.