Decommissioning Legacy Systems: The Last Ten Percent of a Migration Nobody Staffs

Last updated: October 8, 2026

By Mike Carter, Managing Director, KORE1

Decommissioning legacy systems means fully retiring an old platform after a migration, archiving its data under the retention rules that apply to it, cutting off every downstream consumer, and reclaiming the licenses, hardware, and access it still holds. Most migrations never finish that part. The new system goes live, the project team gets reassigned, and the old one keeps running in the background with a real invoice attached to it.

I found one of those invoices by accident.

A distributor we staff for, about $240M in revenue, had moved off an on-prem ERP onto NetSuite the previous year. Go-live was considered a win internally. Somebody sent a cake. Fourteen months later their controller was walking me through headcount for a project req and mentioned, almost as a footnote, that they were still paying roughly $19,400 a month to keep the old environment alive. Hosting, two support contracts, a database license, and an annual true-up nobody had modeled. The reason was smaller than you would guess. Two Crystal Reports feeds that finance used for commission statements still came out of the old box, and the file the bank’s lockbox process picked up every Tuesday morning was generated by a scheduled job in there that no living person had written.

Nobody was hiding it. Nobody owned it either.

Quick disclosure before we go further, because you should expect one. I run the commercial side of a staffing firm. The argument I’m about to make is that you should bring in a small contract crew to finish these projects, and we are in the business of placing exactly that kind of crew through our IT staffing services desk. Read the numbers, not my enthusiasm. The pattern below shows up whether you hire us, hire somebody else, or do it with the people you already have.

What Decommissioning Actually Means

Decommissioning is the formal retirement of a system: data archived or destroyed under policy, every integration and report severed or rebuilt elsewhere, users removed, licenses terminated, and hardware reclaimed or wiped. It’s the last stage of a migration, not an afterthought to it. The test is simple. If the box can be powered off permanently and nothing breaks and no auditor can object, it’s decommissioned.

Migration and decommissioning are two different projects that get funded as one. Migration is additive and visible. You’re standing up something new, there are demos, and executives can see progress. Decommissioning is subtractive and invisible, which means it produces no screenshots, no steering-committee slide anyone wants to present, and no moment where somebody gets to say the thing is live. It only produces a smaller bill, and a smaller bill lands in a different quarter than the credit for it.

That asymmetry is the whole problem.

Why the Old System Never Gets Turned Off

This isn’t a mid-market failure of discipline. It happens at the largest scale available in this country, and it’s documented.

In 2019 the Government Accountability Office looked at 65 legacy systems across 24 federal agencies and named the 10 most critical, ranging from about 8 to 51 years old. GAO’s finding was not that agencies lacked ambition. It was that their modernization plans were incomplete, and the specific criteria GAO used are worth stealing. A plan has to include milestones, a description of the work, and a plan for the disposition of the legacy system. Eight of the ten lacked a complete plan.

Four years later GAO went back. By May 2023 six agencies had fixed it. Two still had not, the Department of Transportation and the Office of Personnel Management, and what they were still missing included the legacy system disposition details. Those 10 systems cost about $337 million a year to run and maintain.

Read that sequence again, because the shape of it is the point. Of the three things a modernization plan needs, the one that stayed unfinished the longest, at agencies under direct congressional attention, was the plan to turn the old thing off. Not the new build. The shutdown.

Four reasons it happens, in roughly the order we see them:

• The budget was written for the migration. Decommissioning work gets no line of its own, so it competes with next year’s roadmap and loses.
• The people who could do it are the people you just promoted onto the new platform. Their calendars are full of the thing that’s live and visible.
• Nobody can prove the old system is unused. Which is a different sentence from “the old system is used.” More on that below, because it’s the technical heart of this.
• Somebody got scared once. One finance close broke during a cutover, and now the standing instruction is to leave it running, indefinitely, just in case.

That last one is cheap insurance, right up until it’s a six-figure annual subscription to a fear nobody revisits.

The Long Tail of Consumers

Here’s the part that stalls real projects. A legacy system has a list of consumers, and the list is always longer than the documentation says. The front-end users are easy and they aren’t the problem. The problem is everything that reads from it quietly.

A medical device manufacturer in Irvine ran into this hard. They had an SQL Server 2008 R2 instance behind a system they had replaced, and the plan was to shut it down at the end of a quarter. The team pulled the connection logs. Sixty-one distinct accounts had touched that database in 90 days. Fourteen were service accounts nobody could map to an owner. One turned out to be a VBA macro in a spreadsheet on a quality engineer’s desktop that pulled lot genealogy for a supplier audit, twice a year. It was not on any inventory. It would have failed silently, in a regulated process, and nobody would have noticed until the audit.

They didn’t shut down that quarter. They were right not to.

Ninety days is the floor on that log window, and it isn’t enough on its own. Quarterly and annual processes hide below it. If you want a defensible shutdown you need at least one full fiscal year of observation, or a compensating control, which in practice means leaving the system readable but not writable for a defined period and watching what screams.

That intermediate state has a name in most runbooks. Read-only quiesce. It’s the single most useful tool in this work and almost nobody budgets for the months it takes.

Data Retention Is the Reason You Can’t Just Pull the Plug

Switching off a server is an afternoon. Satisfying the retention obligations attached to the data on it is the actual project, and the obligations don’t move just because the application did.

Two examples of how specific this gets. A broker-dealer’s books and records fall under SEC Rule 17a-4, where categories including blotters, general and subsidiary ledgers, and customer account records carry a six-year retention, and the first two years of that period have to be in an easily accessible place. A covered entity under the HIPAA Security Rule has to keep its required documentation for six years from creation or from the date it was last in effect, whichever is later. Neither of those clocks resets when you migrate.

So the archive isn’t a backup. A backup is a copy of a system you intend to restore. An archive is a readable, queryable, auditable copy of records you intend to produce on demand to somebody with subpoena power, which means it needs a schema somebody can interpret in year five without the original application sitting in front of them. Flat files with no data dictionary aren’t an archive. They’re a liability with good intentions.

And then the other half, the data you’re obligated to get rid of properly. NIST updated its media sanitization guidance in September 2025, and SP 800-88 Revision 2 is now the current version. Revision 1, the one most internal policies still cite by name, was formally withdrawn. If your decommissioning template references 800-88r1, it’s pointing at a retired document, which is a small thing that reads badly in an audit.

Four questions worth answering before anybody schedules a shutdown window:

1. Which records on this system carry a statutory or contractual retention period, and when does the longest one expire?
2. Where will those records live, in what format, and who can query them in year five?
3. What has to be sanitized rather than archived, to what standard, and who signs the certificate?
4. Who is the named owner of the archive after the project team disbands?

Question four is the one that gets skipped, and it’s the one that turns a finished decommission into an orphaned one.

Who Owns the Shutdown

Ask who owns decommissioning at most mid-market companies and you get a pause, then a name, then a qualifier about how that person is pretty busy.

The vacuum is structural. Application owners get measured on the new platform’s adoption. Infrastructure gets measured on uptime, and an old server that’s up isn’t failing anything. Security wants it gone and has no budget to make that happen. Finance sees one line item in a cost center and no mechanism to challenge it. Every one of those positions is reasonable. Together they produce a system that runs forever because turning it off is nobody’s win.

What works is embarrassingly simple and almost never done. Name one person accountable for the shutdown, give the shutdown its own dated milestone separate from go-live, and attach the recovered run cost to that person’s scorecard so the savings land where the work happened. Then publish a kill date and make the burden of proof flip. Instead of asking “can we turn this off,” the standing question becomes “who needs this to stay on, and what will they do about it by the kill date.” That reversal does more than any tooling. We watched one client clear 19 of 24 integrations in six weeks after they set a date, purely because the date made inaction expensive for people who had been comfortable.

If you’re reading this without a CIO to assign it to, the sequencing problem is the same one we covered in our guide to building an IT roadmap when you do not have a CIO. Dates you do not control beat priorities you do.

The Case for a Contract Decommission Crew

Here’s where I will be plainly self-interested, and also right.

The work of decommissioning is finite, specialized, documentation-heavy, and deeply unappealing to the engineer who just spent eighteen months building the replacement. That combination describes a contract engagement almost perfectly. You need specific skills for a defined window, the skills are partly obsolete ones you do not want on permanent payroll, and the deliverable is a closed ticket rather than an ongoing capability.

Pulling your own senior people onto it costs you twice. You pay their fully loaded rate to do archive mapping, and you pay again in the roadmap work that doesn’t happen while they do. Worse, you ask the person who built the new system to spend a quarter in the old one, which is a reliable way to start a resignation conversation. It happens. Three of the last six ERP cutovers we staffed into saw at least one key internal engineer leave within six months of go-live, and in two of those the stated reason was being held on cleanup after the interesting part ended.

That’s a three- to five-person crew for a quarter or two, not a department. For a single mid-market system we usually see it land somewhere between a tenth and a quarter of what the migration itself cost, against run costs that were going to continue indefinitely. The distributor with the $19,400 monthly bill did the math in one meeting once somebody wrote it on a whiteboard as an annual number.

Speed matters here more than it does on a permanent search, which is the practical argument for contract staffing on this specific work. Our average time to hire across IT roles is 17 days, and for a defined-scope engagement like this it’s usually faster, because you’re hiring against a task list rather than a culture. If the scope is big enough to need the whole crew placed and managed as a unit, that’s an IT project staffing engagement rather than a sequence of individual reqs, and it’s worth structuring it that way from the start. We have been doing this since 2005, across more than 30 U.S. metros, and decommissioning work has quietly become one of the more common reasons a client calls us in the twelve months after a cutover rather than before it.

A Decommission Runbook That Actually Closes

Nine steps. In order. The order is the part people get wrong.

1. Set the kill date publicly. Before the inventory, not after. An inventory with no date attached becomes a document instead of a project.
2. Inventory consumers from logs, not from interviews. Pull a minimum of 90 days of connection, job, and transfer logs. Interviews come second, as a way to assign owners to what the logs already found.
3. Map records to retention obligations. Every table, feed, and document store gets an answer and a longest-expiry date. This is where a records analyst earns the engagement.
4. Notify every consumer with a named owner and a date. Silence isn’t consent. An unowned feed gets escalated, not assumed dead.
5. Rebuild or retire each feed deliberately. Most don’t need rebuilding. Say so in writing, with the owner’s name on it.
6. Go read-only. Quiesce writes, keep reads, and sit in that state through at least one month-end and ideally one quarter-close. This is where the hidden consumers surface, loudly and safely.
7. Build and validate the archive. Then test it the only way that counts, by having somebody who was not involved answer a real historical question from the archive alone.
8. Dark period, then power off. Disable access entirely, leave the system recoverable for a defined window, and only then shut down.
9. Close the money. Terminate licenses and support contracts, release the hardware or VM capacity, cancel the hosting line, and report the recovered run rate to whoever owns the budget. A decommission that doesn’t end in a canceled invoice didn’t finish.

Step nine gets dropped constantly. The server is off and the renewal still auto-processes in March, because the shutdown lived in an engineering ticket and the contract lived in procurement, and the two never spoke.

When You Should Leave It Running

Not every old system should be retired, and I would rather say that plainly than sell you a project you do not need.

Leave it alone when the run cost is genuinely small, the system is isolated with no integration pressure, and the data on it carries no retention or security exposure worth managing. The standard modernization frameworks, the ones built around retire, retain, rehost, replatform, refactor, rearchitect, and rebuild, all treat “retain” as a legitimate outcome rather than a failure to decide. A stable, cheap, air-gapped application that one department uses twice a year isn’t your problem. Go find a more expensive one.

Where it stops being defensible is when it’s reachable from your network, running an operating system that stopped getting patches, and holding records somebody could subpoena. That’s not a legacy system. That’s an open item with a timer on it, and the longer our broader take on application modernization sits unread on a shelf, the more expensive the timer gets.

Things People Ask Us About This

How long does a decommission actually take, start to finish?

One to two quarters for a single mid-market system, assuming you include a read-only period that spans a month-end close. The read-only window is what sets the floor. That part is fixed. You can compress the inventory and the archive work with more people, but you cannot compress a quarter-close into three weeks, and skipping that observation period is how quarterly jobs get discovered by their failure instead of by your log review.

Can our own team do this instead of bringing anyone in?

Often, yes. The question is what stops while they do. If your senior platform people have slack and the political cover to chase down 40 integration owners, keep it internal and save the fee. Where it usually falls apart is availability rather than capability, because the people who know the old system well enough to retire it are the same people now accountable for the new one, and something has to give. Usually the cleanup. When that’s the situation, a project-based staffing model protects the roadmap.

What does it cost to leave the old system running for another year?

Add the hosting, the support contracts, the database and OS licenses, the backup capacity, and the staff hours spent patching something nobody uses. For the distributor I opened with, that was about $233,000 annualized. Nobody had added it up. Most teams have never seen the number in one place, because it sits in four cost centers and three renewal cycles. Writing it as a single annual figure on a whiteboard changes the conversation faster than any argument about risk does.

Is an archive the same thing as a final backup?

No, and treating them as the same is the most common expensive mistake in this work. A backup restores a system. An archive answers a question years later without that system existing, which means it needs a documented schema, a retention expiry, a named owner, and a query path somebody can use under pressure. Test yours by having an uninvolved person pull a real historical record from it.

We finished the migration a year ago and the old system is still up. Is that bad?

It’s extremely common, and whether it’s bad depends on two things. What it costs you monthly, and what it’s exposed to. A year of drift is survivable. What makes it worse over time is attrition, because every month that passes takes away another person who remembered why a particular job exists, and the inventory gets harder rather than easier. The cheapest version of this project was last year.

Who should own the kill date if we do not have a CIO?

Give it to whoever owns the budget line the old system sits in, usually a controller or a VP of Finance, and give them a technical lead on contract. That pairing works better than it sounds. Finance has both the motive to see the invoice end and the standing to push back on departments that want the system kept alive, and the contract lead supplies the evidence that makes the shutdown defensible.

Where to Start This Week

Pull one number. Take whatever system your team “replaced” most recently and total what it still costs per month across hosting, licenses, support, and backup. Then annualize it and send that single figure to the person who owns the budget, with a proposed kill date in it.

That email is the whole intervention. One number, one date. Everything in this post is downstream of somebody finally writing the annual number down and attaching a date to it.

If the answer comes back that the work is real and nobody has the capacity to run it, that’s the conversation we are useful in. Talk to our team about what a decommission crew looks like for your stack, or if the replacement platform is where the gap actually sits, our ERP recruiters work on both ends of these projects.