The System Nobody Wanted and Nobody Could Switch Off

There is a particular species of corporate expenditure that persists not because anyone has decided it should, but because nobody has decided it should not. It sits on the budget. It renews automatically. It is occasionally questioned in a finance meeting, at which point someone says "we still need it for our regulatory obligations," and the conversation moves on.

This is how organisations end up paying indefinitely for software they no longer use. Not because the software is valuable. Not because turning it off is genuinely dangerous. But because the question "can we get rid of this?" is difficult, and difficult questions in corporate life have a well-documented tendency to be deferred until they become someone else's problem.

The company in this case study had migrated to a new Human Resources Information System. The migration was successful. The new platform was operational. The old one was, by any functional definition, finished. Except that it was not finished at all, because it still held historical records — tax documents, pay stubs, personnel files — that the organisation was legally required to retain.

And so the old system stayed. Read-only. Expensive. A digital attic that nobody wanted to climb into but nobody was allowed to empty.

The Problem: Paying Rent on a Building You Have Already Left

The situation was a textbook case of what economists call a sunk cost trap compounded by loss aversion. The organisation had already invested in the migration. The new platform was working. But the old system still contained data that might, conceivably, be needed for an audit, a tax inquiry, or a legal dispute. And so it remained — accruing fees, accumulating risk, and quietly resisting every attempt to shut it down.

The obvious solution — migrate everything from the old system to the new one — was technically possible. It was also, on closer inspection, absurdly expensive relative to the value of the data involved. The legacy platform stored records in a structure that did not map neatly to the new system's data model. Building a full one-to-one mapping, with all the transformation logic required, would have been a significant project: slow, costly, and delivering almost no incremental business value. You would be spending real money to move data that nobody looked at, into a system that did not particularly want it, in a format that did not naturally fit.

Meanwhile, the legacy vendor held all the leverage that comes with being the only place a regulated organisation's compliance records live. If the vendor changed its pricing, its access methods, or its support terms, the company had no meaningful alternative. This is the IT equivalent of storing your passport in someone else's house and hoping they continue to answer the door.

The organisation was stuck in the worst possible position: paying for something it did not want, unable to leave because of something it was legally required to keep, and facing a "proper" migration that cost more than the problem was worth.

The Insight: Ask a Better Question

Here is where the story turns, and it turns on a question — which is usually how the most valuable consulting engagements work. Not a new technology. Not a new platform. A new question.

The old question was: "How do we migrate everything from the legacy system to the new one?"

The better question was: "What, exactly, are we legally required to keep?"

These sound similar. They are not. The first question assumes the entire dataset must move. The second question asks what subset actually matters. And when you sit down with finance, payroll, and legal — the people who actually understand the retention obligations — the answer is almost always the same: you need a clearly defined subset of records, not the entire archaeological history of every field the legacy system ever stored.

Once the retention scope was defined — which record types, which fields, which time windows, and in what format they needed to be accessible for audit — something remarkable happened. The mapping problem, which had seemed impossibly complex when applied to the entire dataset, became straightforward when applied to the subset that actually mattered. The required records had an obvious, consistent path from the old system into the new one.

An intractable integration project had become a well-scoped automation problem. And well-scoped automation problems are exactly the kind of thing that can be solved quickly, reliably, and cheaply.

This is a pattern Sutherland would recognise immediately: the most powerful intervention was not a technology change but a reframing. The constraint was not technical. It was conceptual. Everyone had been trying to solve the wrong problem, and the wrong problem was expensive. The right problem was manageable.

The Solution: A Robot With a Very Specific Job

The legacy system had no reliable bulk export path and no usable API. The only way to access the data was through the user interface — the same screens a human would click through. This is exactly the situation where RPA earns its keep: when the data is trapped behind a UI that was never designed for extraction, and building a proper integration would cost more than the entire project.

Step 1: Define What Must Be Kept

Workshops with finance, payroll, and legal stakeholders produced a precise, auditable retention definition: which record types (person records, tax records, pay stubs, expenses), which fields within each, the required retention windows, and the format and accessibility expectations for audit purposes.

This was not a technical exercise. It was a governance exercise. And it was the single most valuable step in the project, because it drew a clear line between "data we are obligated to retain" and "data we have been hoarding out of anxiety." The difference, in volume and complexity, was enormous.

Step 2: Build an Unattended Migration Worker

An RPA bot was built to do what a human would have done — only without the fatigue, the transposition errors, or the tendency to take lunch breaks at inconvenient moments.

The bot iterated through a master list of records, navigated the legacy UI (including the pop-ups, timeouts, and inconsistent page loads that make legacy systems such a joy to work with), extracted the required data points, transposed them into the new system's target fields, and logged every step.

It ran unattended — overnight, on weekends, at whatever pace the organisation was comfortable with. No staff time consumed. No interruption to day-to-day operations.

Step 3: Build Audit Trails and Quality Controls From Day One

Because these were compliance-relevant records, the controls were not an afterthought bolted on at the end. They were designed into the solution from the start — which is the only way to build controls that actually work, as opposed to controls that exist on a slide deck and nowhere else.

Detailed run logs captured every record processed, with timestamps and outcomes. An exception handling queue caught records that failed validation or required human review. Accountants performed QA spot checks to confirm accuracy. Progress reports and reconciliation summaries provided visibility throughout.

The result was a migration that was not merely complete, but defensible — provably accurate, fully traceable, and ready for any auditor who cared to inspect it.

Step 4: Reconcile and Retire

A final comparison report confirmed that the retained subset in the new environment matched the legacy source. The organisation formally decommissioned the old system. The recurring cost disappeared. The vendor dependency ended.

The digital attic was finally empty.

Why They Chose Slow Over Fast (And Why That Was Smart)

There is a temptation, when you have a bot that can process records autonomously, to run it as fast as possible. Run multiple bots in parallel. Maximise throughput. Finish in days instead of weeks.

The organisation deliberately chose not to do this. There was no urgent deadline. The team was risk-averse, for good reason — these were compliance records, and a mistake would be visible to exactly the kind of people you do not want noticing your mistakes. Running a single bot at a controlled pace meant clear visibility into what was being moved, simpler investigation if anything looked wrong, lower load on the target system, and more comfortable governance for the finance and legal teams monitoring the process.

They traded speed for confidence. In automation, as in life, this is almost always the right trade when the consequences of an error are asymmetric — when getting it wrong costs far more than getting it done a week sooner.

This is a deeply Sutherlandian insight: the optimal solution is not always the fastest one. Sometimes the optimal solution is the one that lets everyone sleep at night.

The Results

The legacy system was fully retired. Not mothballed. Not kept on life support. Retired. The recurring cost — which had been quietly accumulating since the migration was "complete" — stopped entirely.

A costly full data mapping project was avoided. The organisation did not spend six figures moving data it did not need, into a format that did not fit, to solve a problem that did not exist.

Vendor dependency was eliminated. The compliance records now lived in the organisation's own environment, accessible on their terms, not the legacy vendor's.

Audit readiness improved. Structured, accessible records with clear evidence trails, rather than data locked inside a platform the organisation no longer controlled.

A repeatable approach was established. The methodology — define the retention scope, automate the extraction, build controls from day one, reconcile and retire — is now available for the next legacy system the organisation outgrows. And there will be a next one. There always is.

Where AI Fit (And Where It Did Not)

This project succeeded through automation and control design, not artificial intelligence. The data was structured. The mapping was deterministic. The rules were clear. AI would have added complexity without adding value — which is a polite way of saying it would have been a solution looking for a problem.

That said, similar legacy retirement projects often benefit from AI in targeted ways: detecting anomalies in migrated values, classifying unstructured attachments, or assisting with mapping discovery when field naming is inconsistent across systems.

The principle is worth stating plainly: use AI where it reduces risk or effort. Use deterministic automation where accuracy and traceability must be exact. And resist the temptation to use AI simply because it is available, in the same way you would resist the temptation to use a helicopter to commute simply because someone offered you one.

The Lesson Nobody Wanted to Hear

The most expensive part of this problem was not the migration. It was the delay. Every month the legacy system stayed alive was another month of fees, another month of vendor dependency, and another month of compliance records sitting in a system the organisation did not control.

The delay was not caused by a technical obstacle. It was caused by a framing problem. Everyone assumed that retiring the legacy system required a full migration. A full migration was expensive. Therefore, the project was deferred. Therefore, the fees continued. Therefore, the problem got slightly worse every quarter, in a way that was never quite urgent enough to force action.

This is how most legacy cost problems work. Not with a dramatic failure, but with a quiet, compounding expense that everyone acknowledges, nobody prioritises, and the organisation absorbs until it becomes part of the landscape — like a subscription you forgot to cancel, except this one costs five figures a year and introduces regulatory risk.

The fix was not a technology breakthrough. It was the willingness to sit down, define what was actually required, and discover that the problem was considerably smaller than everyone had assumed.

Most problems are, once you ask the right question.

Legacy system retired · Full migration avoided · Reduced risk · Audit-ready retention

Paying for a system you no longer use?

You are not alone. Most organisations that complete a platform migration end up in read-only limbo with the old system — paying fees, accumulating risk, and deferring the retirement because it feels too complex. A short process audit will usually reveal that it is not.

Book a process audit | Learn more: process automation | Contact us