You Are Paying to Maintain Systems That Do the Same Job.

Nobody decided to run this many systems. They accumulated. An acquisition brought its own platform, a department bought a tool to solve one problem, a decade-old project left behind an application that three people still open every Monday. Each one has a license, an integration, and a constituency. You did not create this burden, but it is now yours to reduce, and the hard part is not recognizing the waste. The hard part is retiring anything safely when every system has someone who depends on it and dependencies nobody wrote down.

Quick Answer: Enterprise system consolidation is decided by what a system holds and who depends on it, not by license cost alone. Inventory each system’s data, integrations, and actual users; rank candidates by total maintenance burden against migration difficulty and business risk; consolidate onto a platform that already carries the organization’s identity, governance, and compliance controls; and retire in an order where each retirement is preceded by a verified replacement. The cost that justifies the program is rarely licensing. It is the staff time and the risk of running systems nobody maintains.

Key Takeaways

• License cost is the smallest line in the maintenance bill. The real spend is integration surface, staff attention, security exposure, and the audit cost of systems nobody owns.
• Inventory before judgment. You cannot retire a system responsibly until you know what data it holds, what integrations depend on it, who actually uses it against who is assumed to, and what records obligations outlive the software.
• Rank for risk, not for savings. The cheapest system to switch off is often the one that quietly feeds three others; the ranking has to weight blast radius, not just the recurring invoice.
• Consolidate onto a platform you already govern. A destination that already carries your identity, permissions, retention, and compliance controls turns consolidation into a move rather than a new governance project.
• Sometimes keeping a system is the correct answer. Regulated systems under validation obligations, systems whose replacement cost exceeds their burden, and genuinely distinct departmental workflows are honest reasons not to consolidate.
• A retirement is not done when the new system is live. It is done when the replacement is verified, the records obligation is satisfied, and there is decommissioning evidence you could hand an auditor.

What Maintaining Many Systems Actually Costs

The invoice you can see is the license. It is also the least of it. The cost of maintaining overlapping systems sits in five places, and only one of them shows up as a subscription line. There is the integration surface: every system that talks to another is a connection someone has to keep working through every upgrade on either side. There is staff attention, the most expensive and least tracked resource in the estate, spent on patching, access requests, and the tribal knowledge of which server cannot be rebooted before noon. There is security exposure, because every additional system is another attack surface, another patch cadence, another set of credentials to manage. And there is the audit cost of systems nobody owns: when an auditor asks who has access to a platform and why, the honest answer for an orphaned system is a script and a long afternoon.

The consolidation case is strongest where those hidden costs are largest, and it is provable. A federal agency that had supported and maintained more than thirty separate legacy systems consolidated them onto a single centralized SharePoint platform. The outcome that matters for the buyer reading this was not a licensing footnote: it reduced administrative time and cost and it eliminated the downtime that came with keeping that many aging systems running. Thirty-plus systems collapsing to one is the maintenance-burden argument made concrete. It is worth being precise about what that proves and what it does not. It proves that consolidation removes real maintenance and stability cost. It does not, on its own, prove a dollar figure, a migration timeline, or a governance maturity score for your estate. Those are yours to establish, and the next section is where that work starts.

Inventory Before Judgment: What Each System Actually Holds

You cannot rank what you have not inventoried, and the inventory that matters is not the asset register IT already has. It is a content and dependency inventory that answers four questions for every candidate system. What data does it hold, and is any of that data the system of record for something? What integrations run into and out of it, including the scheduled export nobody remembers building? Who actually uses it, measured against who is assumed to use it, because the two numbers are rarely the same? And what records obligations survive the system, meaning the retention, legal-hold, or regulatory duties that persist even after the software is gone?

That last question is where consolidation programs most often get hurt after the fact. A system can be redundant as software and still be the sole custodian of records you are legally required to keep. The inventory is what separates a system whose function is duplicated from a system whose data is unique, and those are different retirement problems.

The duplicate-data case is common enough to name plainly. A state bar association running multiple accounting systems moved to an integrated platform that eliminated manual spreadsheets and reduced the duplicate data entry those overlapping systems had forced on staff. That is the pattern the inventory is built to surface: the same record maintained in several places, reconciled by hand, at a cost that never appears on any license. When the inventory shows one authoritative source and several shadow copies, the shadow copies are consolidation candidates. When it shows genuinely different data in each system, you have a migration problem, not a duplication problem, and you rank it accordingly.

Ranking Candidates: A Decision Framework for What Retires First

Consolidation goes wrong when the ranking optimizes for savings. The system with the largest license is not automatically the first to retire; it is often the one most deeply integrated, which makes it the most dangerous to touch first. A defensible ranking weights every candidate on three axes and lets risk dominate.

The first axis is total maintenance burden: license plus the integration, staff-attention, security, and audit costs from the section above, expressed honestly rather than as the invoice alone. The second is migration difficulty: how hard it is to move what the system holds and re-point what depends on it, which the inventory now lets you estimate instead of guess. The third, and the one that should carry the most weight, is business risk: what breaks, and for whom, if this retirement goes wrong. A low-burden, low-difficulty, low-risk system is an easy early win. A high-burden system that is also high-risk is not a “no”, it is a “not first”, sequenced behind the wins that build organizational confidence and behind the replacement work that lowers its risk.

The order the ranking produces is the program. Retire the clear duplicates first, where the inventory shows a shadow copy and an authoritative source. Sequence the deeply integrated systems later, after their dependents have somewhere else to point. And hold the regulated and records-bearing systems until the retention and evidence questions in the final section are answered, because a system you retired without satisfying its obligation is a finding, not a saving.

Consolidating Onto a Platform You Already Govern

The destination decides how much of this is a move and how much is a new project. Consolidating onto a platform that already carries your organization’s identity, permissions, retention, and compliance controls means the governance work is largely done before the first system retires. Access follows the identity model you already run. Retention policies you already enforce extend to the consolidated content. Compliance controls you have already had audited apply by default rather than being rebuilt per system. That is the difference between consolidation as a relocation and consolidation as a second governance program bolted onto the first.

Consolidating onto a platform you do not yet govern inverts every one of those advantages. Now the destination needs its own identity integration, its own permission model, its own retention policy, and its own compliance evidence, and you are building those under the deadline pressure of systems waiting to be retired. The platform question is therefore a governance question first and a features question second: the right destination is the one where the controls already exist, because controls that already exist are controls an auditor has already seen work.

When Consolidation Is the Wrong Answer

An honest framework says plainly when keeping a system is correct, because the pressure to reduce system count will occasionally point at a system that should not move. There are three defensible reasons to keep one.

The first is regulatory validation. A system operating under formal validation obligations, where the validated state is itself the compliance asset, cannot be casually folded into a general platform without re-incurring the validation cost the retirement was supposed to save. The second is replacement economics: when the cost and risk of replacing a system genuinely exceeds the burden of keeping it, retiring it is a loss dressed as a saving, and the ranking exercise should show that honestly rather than force the system into the queue. The third is genuine workflow difference. A department whose process is materially different, not merely unfamiliar, may be correctly served by a system that looks redundant from the outside and is not. The discipline is telling a real difference from an unexamined habit, which is exactly what the inventory and the usage data are for.

One boundary is worth drawing so it is not mistaken for a keep-or-retire question at all. If what you are looking at is a proliferation of citizen-developer apps and flows inside Power Platform rather than a set of overlapping enterprise systems, that is a different problem with a different owner and a different risk profile, and it is addressed on its own terms in Power Platform app sprawl and its governance risk. System consolidation is about retiring redundant systems. App sprawl is about governing a platform’s own output. Solving one does not solve the other.

Retiring Safely: Evidence, Cutover, and What Happens to the Data

The retirement is the moment every earlier decision is tested, and it runs on evidence rather than optimism. Each retirement should be gated by exit criteria that are checkable, not asserted. There is a verified replacement: the function the retired system performed is demonstrably running somewhere else, confirmed by the people who depend on it, before the old system goes dark. There is records disposition: the retention obligation the inventory surfaced is satisfied, whether that means migrating the records to the consolidated platform under policy, archiving them to a governed store, or formally dispositioning them where policy allows. And there is decommissioning evidence: a record of what was shut down, when, what happened to its data, and who signed off, in a form you could hand an auditor a year later.

Cutover order carries the same logic the ranking established. Verify the replacement, run the two systems in parallel long enough to trust the new one, cut over, and only then decommission, keeping the evidence at every step. The failure mode consolidation programs pay for later is the reverse: retire the system on schedule, discover afterward that a downstream process quietly depended on it or that a records obligation was never addressed, and spend the following year doing on a live platform the work that should have gated the retirement. Each retirement preceded by a verified replacement is the rule that prevents it, and it is the rule the entire program exists to honor.