Two ERPs, One Company: Why SaaS Redundancy Outlives the Consolidation Meant to End It

Sooner or later, a CFO in a budget review asks the question nobody answers cleanly: Why are we paying for two systems that do the same job? The replies usually sound like “we’re still migrating” or “finance needs the old one for historicals.” Give it a few more months, they say. A few months turns into three years. That’s how SaaS redundancy settles into the finance stack. Carelessness rarely has much to do with it. The way ERP consolidation programs are run makes it close to inevitable, and that’s exactly why it keeps slipping past IT cost optimization efforts.

How the Second System Gets There: The Stalled ERP Migration

Nobody plans to run two ERPs. The second one almost always shows up as the replacement for the first.

You’ve probably seen the sequence. A company outgrows its original finance platform, buys a business that runs on something else, or signs a new system as part of a larger transformation. A business case gets approved with a sponsor, a budget, an implementation partner, and a go-live date. Turning the new platform on has owners at every step.

Then the ERP migration slows down. There’s rarely one big failure. The general ledger moves over, but a couple of subsidiaries stay behind. Historical data turns out to be messier than anyone expected, so the old system stays up for reporting. A few custom workflows, built years ago by someone who has since left, don’t map cleanly to the new platform. You can defend every one of these exceptions. Taken together, though, they keep the legacy system running with no end in sight.

The real issue is how success gets measured. Implementation programs are judged on go-live. Once the new platform is up, the project team gets thanked and moves on to the next thing. Retiring the old system was in the plan from day one, but it never became anybody’s job.

So consolidation adds and rarely subtracts. Adding has an owner. Retiring doesn’t.

The Real Cost of SaaS Redundancy Isn’t the License Fee

When a company pays for duplicate software at the core of its finance stack, license fees are the easiest expense to see. They’re usually the smallest one, too. Most of the money goes to places that never land on the same invoice.

Start with integration. When two systems run in parallel, data either has to move between them or be reconciled after the fact. That means middleware subscriptions, connectors, custom scripts, and someone watching for the sync that fails right before month-end close. Tooling built around a legacy platform often outlasts the platform’s usefulness, mostly because it sits on its own contract and nobody reviews the two together.

Then there’s headcount. The old system still has to be administered, patched, and audited, and someone has to manage who can log in to it. Finance teams end up running parallel closes or keeping reconciliation spreadsheets alive to bridge two ledgers. None of that time is tagged as a legacy ERP cost, so it simply disappears into overhead.

The quieter drain is friction. With two sources of truth, every report starts an argument about which number is right. Closes take longer. Controls get harder to prove. And the benefits that justified the new platform never fully show up, because part of the business is still working somewhere else.

Meanwhile, the legacy license tends to creep up. When a contract loses its owner, it loses its negotiator along with it, and it renews on whatever terms the vendor sends over.

One Company, Two Platforms

Saasrooms data from a US company serving the healthcare market shows what this looks like up close. The business tracks roughly $26.7 million a year in software spend across 58 applications.

The headline here isn’t a dollar figure. It’s that both systems are still running.

In mid-2022, the company signed a seven-year agreement for a new enterprise platform. The contract is worth about $16.7 million over its term, runs through mid-2029, and accounts for just over $2 million of spend this year alone.

Right next to it sits the finance system the company has used since early 2015. More than four years into the new contract, that legacy platform is still active and still billing: roughly $406,000 so far this year, which is close to four times the contract value on file. There’s no expiry date recorded, and nothing in the data suggests anyone is planning to wind it down.

The rest of the stack follows suit. Integration and data-sync tools connecting the two are still under contract. A former payroll provider, whose recorded agreement ended in 2018, is still drawing spend almost eight years later.

One detail explains most of this. All 58 applications have a key user on record, but only one has a named budget owner, and neither ERP is that one. Plenty of people use these systems. Nobody is accountable for what they cost or has the authority to decide when one should go.

This isn’t an isolated case, either. Elsewhere in Saasrooms data, a large multinational holds live licenses with three different ERP vendors at the same time. Its main SAP environment has roughly 6,000 unused software licenses, and its smaller Infor and QAD deployments have only half to two-thirds of their licenses in active use. Another company that has already moved to a new ERP still pays a small residual amount for its old NetSuite instance. The number is tiny. What matters is that it’s still there, because it means the retirement never actually closed.

Saasrooms catches this as soon as a stack is mapped against its contracts: two systems of record in the same category, both still billing, one with no end date and no budget owner.

Who Should Own Legacy System Decommissioning

The easy answer is IT. IT runs the systems, so it should shut them down.

In reality, IT usually can’t make this call on its own. Retiring an ERP means accepting that historical data will live in an archive instead of a live system, that subsidiaries will migrate on a fixed timeline, and that some workflows will be rebuilt or dropped entirely. Those are business decisions with real financial consequences, which makes decommissioning as much a finance question as an IT cost optimization one. They need an owner who can declare the work finished and make that stick.

For most companies, that’s the CFO or someone the CFO explicitly names. A few habits, borrowed from any serious application rationalization effort, make that ownership real instead of ceremonial.

• Put the retirement in the business case. Any new platform should be approved with a committed shutdown date for the system it replaces, and the program isn’t done until that date is met. Go-live is a milestone. Retirement is the finish line.
• Give it to one person. It shouldn’t be a committee or “the project team.” Pick one named owner for the legacy system’s end of life and attach its budget line to them, so any spend that lingers is clearly theirs to fix.
• Price every exception. When a team asks to keep the old system around for another quarter, the request should come with the full bill: licenses, integration, and support hours. Once people have to justify an extension in dollars, they ask for far fewer of them.
• Watch the tail. The last stretch of a migration is where legacy systems quietly live on. Keep tracking leftover contract spend, the integrations built around the old platform, and any user accounts that are still active until every one of them hits zero.

None of this needs new technology. It needs the visibility that good SaaS spend management provides, meaning a clear view of what’s still billing, plus a leader with enough standing to act on it. Saasrooms gives finance that view by tying every contract to its spend, renewal date, and owner, so an orphaned legacy system shows up as an obvious gap instead of a cost buried in overhead.

The Part of the Program Few Companies Plan For

Every ERP program has a launch date. Far fewer have a shutdown date that carries the same weight.

That gap is why SaaS redundancy at the heart of the finance stack survives budget cycles, leadership changes, and even the consolidation programs meant to get rid of it. The new system gets celebrated. The old one fades into the background and keeps getting paid.

Someone has to be responsible for turning things off, not just for turning them on.