The platform everyone wanted gone
Every established organisation has one, and this publishing group's was a subscription management platform, in service for over twenty years. It held the subscriber base for a portfolio of trade and consumer titles: who subscribes to what, at which rate, renewing when, delivered where. It had been extended by generations of developers into adjacent duties — billing runs, address feeds to printers and distributors, circulation figures for the auditors, commission statements for agents. It ran on infrastructure the hosting provider had formally declared end-of-life, and of the two people who genuinely understood it, one was eighteen months from retirement.
The group had already bought its replacement: a modern subscription and customer platform, live for two years, running the newer digital titles. The strategy said everything would move to it. The strategy had said so for some time. Meanwhile every new integration project faced a choice between wiring into the doomed platform or waiting for a migration with no date, and an annual sum that made the finance director wince went on keeping the old system alive.
We were engaged, through our Sparx EA consulting practice, not to perform the migration — the group had delivery partners for that — but to build the thing the migration kept failing for lack of: a complete, evidenced picture of the platform's connections, dependants and data obligations, and a decommissioning sequence that could be defended in front of the board and executed without surprises.
Why the previous attempts failed
This was the third attempt, and the first two had failed the same way from different directions. The first migrated the obvious: the subscriber records and the main renewal journeys moved to the new platform for two pilot titles. Then the nightly address feed to a printing partner broke, because nobody had realised those titles' feed was assembled by the old platform even for subscribers it no longer managed. The pilot was partially rolled back, and the programme lost a year and, more expensively, its credibility.
The second attempt over-corrected into analysis: a consultancy produced a thick current-state document, a catalogue of everything the platform did, gathered by interview. It was impressive and wrong in the places that mattered — interviews capture what people know, and the platform's danger lived precisely in what nobody knew any more. The document also began ageing the day it was delivered, and within a year it described a system that had since been patched twice for regulatory changes.
There was also a quieter failure shared by both attempts: neither had a defensible definition of done. "Migrate off the old platform" is a direction, not a state, and without an explicit, checkable condition for switch-off, every stakeholder held a private version of what remained — which is how switch-off dates come to be announced, missed and quietly re-announced until nobody believes them. Whatever we built had to end in a gate that could be evaluated, not an ambition that could be debated.
The lesson we drew was about evidence and upkeep, not effort. The picture had to be built from what the platform demonstrably does — its actual interfaces, its actual file transfers, its actual consumers — and it had to live somewhere it could be corrected as reality moved, which is what a repository is for and a document is not.
Mapping the edges, not the insides
We made one scoping decision at the start that shaped the whole engagement: model the platform's edges, not its insides. Its internal architecture — the accreted modules, the shared database, the batch chains — was the delivery partner's problem to understand for data migration. What kills a decommissioning is the edges: the consumers nobody listed, the feed nobody owned, the report a regulator turns out to depend on. So in Sparx EA the platform itself is a single application component, deliberately opaque, and all the modelling effort went into what surrounds it.
Around that black box we modelled every service the platform provides to the outside world as an application service — subscriber lookup, the billing run, each address feed, the circulation reporting, the agent commission extract — with the consumers of each service connected by serving relationships: downstream applications, scheduled file transfers, reports, and in a few cases named business roles, because a person who logs in monthly to pull a figure is a consumer too, and precisely the kind that surprises you at switch-off. Data objects captured what each service actually carries.
Each service and each consumer edge carries tagged values that did the operational work later: the evidence for the edge (seen in transfer logs, confirmed by owner, asserted only), the direction and frequency, the responsible contact on the consuming side, and — filled in as the work progressed — the replacement service, the migration wave and the current status. The conventions came from the same playbook we use for model migration engagements: one canonical element per system, no edge without a named source of truth.
Who was actually connected
The consumer hunt combined three kinds of evidence, in declining order of trustworthiness. First, the platform's own transfer and interface configuration — the scheduled jobs, the FTP accounts, the API credentials still active. Second, six weeks of transfer and access logs, which we mined with scripts and reconciled against the configured list; a configured feed with no traffic in six weeks is a different fact from an active one, and both differ from traffic on an interface nobody had configured knowingly. Third, interviews — valuable for meaning and ownership; an edge established only in conversation entered the model tagged asserted only, and stayed second-class until logs or configuration confirmed it.
Figure 1 shows the result: the platform at the centre, its services at its edge, and the ring of consumers — a picture the organisation had never had. The team had guessed there might be a dozen consumers. The evidenced count was just over thirty. The extras were the classic archaeology of a long-lived system: a warehouse extract feeding a business intelligence tool through an intermediate share, a commission feed to an agency network that had been "temporarily" arranged years earlier, a finance reconciliation report that turned out to underpin a quarterly regulatory figure, and several feeds to marketing tools of varying vintage, at least two of which turned out to be feeding nothing at all any more.
The dead feeds mattered as much as the live ones. Every consumer proven inactive was scope the migration no longer had to carry, and we retired those edges from the live views immediately — with the evidence recorded — shrinking the problem before anyone had migrated anything.
The data question
A retirement is not finished when the last consumer leaves; it is finished when the data question is answered. The data objects came from two directions — what the services demonstrably carried, and the delivery partner’s inventory of what the platform’s database mastered internally — and for each we recorded whether the platform was its master or merely a cache, and for everything mastered there, what the obligation was: migrate to the new platform, archive for a retention period, or let it die with the system. Subscriber and financial history carried retention obligations measured in years; circulation figures had audit relevance; a surprising amount of the rest was operational residue nobody needed.
The classification itself was done in two working sessions with the data owners, against the model's data objects rather than against a blank spreadsheet, which kept the discussion anchored to things the platform demonstrably held rather than to categories imagined in the abstract.
The archive decision was the one the previous attempts had never reached. Migrating twenty years of history into a modern platform designed for a different data model would have been expensive and mostly pointless; deleting it was not lawful; so the plan settled on a read-only archive store for the historical data, modelled in the repository as its own component with its own retention tagged values, so that "where do I find pre-migration history" has a permanent, navigable answer. Getting legal and finance to sign the retention lines took longer than any modelling task in the engagement, and starting that conversation in month one instead of month six was one of the few things this attempt did earlier than its predecessors.
Mapping the replacements
With consumers and data established, each provided service got its forwarding address: a realisation path on the new platform, an equivalent service already existing or to be built, connected in the model so that every consumer edge could be read against its replacement. For most consumers this was routing work — the new platform already exposed subscriber lookup and renewal APIs, and the address feeds could be regenerated from it in the partners' existing formats, which we insisted on rather than asking the external partners to change their side.
The mapping found two consumers with no sensible replacement. One — a legacy inserting-machine feed at a print site scheduled for closure — was retired along with its consumer, by agreement, on the print site's own timetable. The other, the agent commission extract, represented a business arrangement the new platform had no concept for; it got a small, deliberately boring bespoke feed built against the new platform's API, documented in the model like everything else. Finding these two on a diagram in month three, rather than in production in month eleven, is what justifies the method.
A sequence you can defend
The sequence, shown in Figure 2, was built on one rule stated in the first steering meeting and never varied: nothing switches off while it has an active consumer, and "active" is determined by the model, which is determined by evidence. Three waves followed from the dependency structure rather than from optimism. Wave one re-pointed the read-only consumers — reports, extracts, the warehouse feed — at a consolidated reporting store fed from both platforms for as long as both ran, so their outputs stayed complete while the subscriber base was still split; each move retired risk cheaply without touching subscription operations. Wave two moved the transactional consumers and the remaining titles' subscriber base, the delivery partner's heavy lifting, with the address and commission feeds cut over partner by partner. Wave three was the endgame: historical data to the archive store, a defined parallel-running period, then the gate.
In Sparx EA the stable states between waves are plateaus, each wave’s moves are work packages linked to the consumer edges they retire, and the switch-off gate combines the consumer countdown — a model search counting edges not yet migrated or retired — with three further conditions tracked as their own work packages: the archive loaded and retrieval tested, the retention sign-offs in place, and the parallel-running period completed without findings. That number — produced by a SQL fragment in the document template, the same query the saved search runs, and displayed at every steering meeting — became the programme’s heartbeat. It started at thirty-one. Meetings stopped debating whether the programme was on track and started asking what it would take to move the number down.
A decommissioning plan is a list of promises about who has stopped depending on a system. Keeping those promises in a repository, each with its evidence and status, is what turns "we think everyone has moved" into "these two have not, and here they are".
Holding the line while it shrank
A retiring platform has a way of growing while you shrink it. Twice in the first months, projects elsewhere in the group proposed new integrations against the old platform — one wanting a fresh extract for a marketing tool, one wanting to extend an address feed for a new title. Both were reasonable requests from teams solving their own problems, and both would have added consumers to a system whose entire programme existed to reach zero consumers.
The steering group adopted a freeze rule to match the switch-off rule: no new edges. Any request that would touch the platform routed through an architecture review, with the consumer map as the working document, and the review's job was not to say no but to find the requester the same capability on the new platform — which in both cases existed. The model made the rule enforceable in a way a policy memo never is: an edge that appears in the transfer logs without appearing in the model is now, by definition, a finding, whoever created it. The freeze held for the duration: no project ever added a new edge.
Keeping the external partners in step
More than half the consumers were external — printers, distributors, the agency network, an audit bureau — which turned the middle of the programme into a coordination exercise as much as a technical one. Each partner needed to know its own dates, its own file formats, its own test window, and nothing else; sending every partner the full programme plan would have generated as many sets of questions about other people's feeds.
The repository carried this too. Because every external edge held its partner contact, format, frequency and cut-over date as tagged values, a document template could generate a per-partner cut-over sheet — your feeds, your dates, your test files, your fallback arrangement — scoped by partner and regenerated whenever dates moved. The partner managers sent these out at each wave boundary, and the questions that came back were about content, not confusion. Two partners needed genuine negotiation — one contractual, one technical — and those were visible early precisely because the per-partner view made their exposure legible to the people who manage the relationships.
Internally, the same scoping logic produced a one-page view per consuming team. The lesson generalises well beyond decommissioning: the estate-wide diagram is for the steering group, and adoption with everyone else comes from views cut to exactly what each audience owns.
Tracking the retirement in the model
During execution the model stopped being an analysis artefact and became the programme's tracking system. As each consumer cut over, its edge's status changed — with the cut-over evidence noted — and the countdown moved. The weekly status report to the steering group was generated from the model; so was the partner-facing schedule of feed cut-over dates. When a wave-two partner slipped, the affected edges' dates changed in one place and every derived view followed, which is precisely the property a programme office spreadsheet does not have once three people hold three copies of it.
We also re-ran the log analysis at intervals rather than trusting the plan's account of reality. Each re-run asked one question: is there traffic on any interface the model says should now be quiet? Mostly the answer was no, and the exercise took an afternoon. Twice the answer was yes — once a consumer that had cut over but left its old feed running in parallel "just in case", which was then formally closed, and once something more interesting, described below.
The one that nearly got away
Late in wave three, with the countdown in single digits, a re-run of the log analysis — its scope by then widened to a legacy file-transfer host that sat outside the platform’s own infrastructure inventory, and so outside the first pass — showed a small weekly FTP pull that matched nothing in the model. It traced to a regional print partner who, years earlier, had been given direct access to collect a delivery-exception file — an arrangement that predated the current partner manager, appeared in no contract schedule anyone could find, and had survived every interview because the person who set it up had long since left both organisations — and survived the early log analysis because its host was not on the list of machines anyone thought of as part of the platform.
It was found on a diagram of log evidence rather than as a Monday-morning incident at a printing plant, which is the difference this working method buys. The feed was replaced with an equivalent from the new platform in three weeks, the edge was added to the model with its evidence and then retired through the same gate as every other consumer, and the switch-off date moved by less than a month. We tell this story in every retirement engagement since, because it makes the honest point better than any success does: the method did not prevent the unknown consumer existing — no method can — but it caught it before the switch-off, which is the promise the method actually makes.
What we would do differently
Start the log analysis before the workshops, not alongside them. We ran interviews and evidence-gathering in parallel to save calendar time, which meant early workshop sessions spent effort on edges the logs would soon confirm or kill anyway. Evidence first, meaning second, is the right order, and we now sequence it that way.
Be blunter, earlier, about what Sparx EA does and does not do in this pattern. The repository held the map, the statuses, the evidence references and the generated reporting, and did it well; the discovery itself came from scripts against logs and configuration, and the honesty of the map depended entirely on that external evidence being refreshed. A team that adopts the model without adopting the evidence refresh inherits a picture that is accurate on the day it was drawn and quietly degrades from there — the same failure as the thick document, on better stationery. The named limitation, then: EA is the system of record for the retirement, not a discovery tool, and the engagement has to build the refresh habit, not just the model.
And we would model the platform's human consumers — the roles logging in directly — from the first week. They entered the model late, after the login audit, and one of them turned out to be the finance reconciliation that fed the regulatory figure. People are edges too, and they are the least logged of all.
Where they are now
The platform was switched off on a Saturday morning, on the third scheduled date, roughly two years after the engagement began — the first two dates having moved for reasons visible in the model as they developed — a partner slip, and the late-found feed described above — rather than discovered at the gate. The archive store answers the history questions; the hosting and support spend has stopped; the retiring expert retired on schedule, with the map of his system's edges outliving his tenure in a form his successors can query. The group has since pointed the same method at the next candidate on its list, using the retirement package structure from this engagement as the template — which is what we most hoped would happen, since the durable deliverable of a decommissioning is the organisation's ability to run the next one itself.
If your organisation has a platform everyone wants gone and no one can safely switch off — and a history of attempts that proved why — you can reach us through our contact page.
This case study describes a representative engagement pattern. Organisational details are illustrative and do not identify a specific client.