The 70% Rule — Why Most Apps in Your Estate Are Consolidation Candidates
Once you exclude the legitimate-separation cases, the remaining estate is overwhelmingly accidental. The 70% rule is the heuristic that translates the inventory into a triage plan: retire, merge, or replace. The savings live in the 70%.
The previous two posts argued that some applications must remain separate — data residency, sector compliance, country-specific regulation, sovereignty, contractual obligation. That cluster typically accounts for around 15% of a mid-to-large enterprise's application estate. Another 15% is legitimately kept for genuine specialist reasons that survive the diagnostic from Post 3. That leaves 70% of a typical estate as the consolidation territory — the long tail of duplicates, trial debris, zombie subscriptions, departmental sprawl, and org-change leftovers that the rationalisation programme exists to address.
The 70% rule is the centerpiece of the consolidation cluster of this series. It is a heuristic, not a precise number; some estates land at 60%, others at 80%, the variation is driven by industry, geography, and prior governance maturity. What is consistent is the pattern: once the legitimate cases are excluded, the majority of the remaining estate is candidates for retirement, merger, or replacement. The savings live in this bucket; so does most of the integration debt and security exposure that motivated the programme in the first place.
This post walks the triage. For each consolidation candidate, the question is which of three destinations applies: retire (the application disappears), merge (the application's function migrates to another existing application), or replace (the application is swapped for a better-fit alternative). The diagnostic is concrete; the work is sequenced.
The triage framework
Every application in the consolidation-candidate bucket gets routed to one of three destinations based on three properties: whether the function is needed at all, whether an existing application can absorb the function, and whether the existing application is the right tool for the function once absorbed.
Destination 1: Retire
The function is no longer needed. The application is org-change debris, a zombie subscription, a trial that nobody upgraded, a use case that ended. The work is to identify the active users (if any), notify them, set a sunset date, and turn the application off. Retirement is the highest-leverage destination because the savings are immediate and the risk is low — nobody is using the application, so retiring it does not break a process.
Destination 2: Merge
The function is needed and another existing application can absorb it. The duplicate project management tool merges into the sanctioned one. The departmental survey tool merges into the enterprise survey platform. The shadow expense tool merges into the corporate expense system. The application disappears; the function continues; the user experience consolidates.
Destination 3: Replace
The function is needed but the application doing it is the wrong tool. Either the application was a stopgap that should never have been a permanent answer, or the requirement has evolved beyond what the application can handle. The work is to evaluate alternatives, select a successor, and migrate — on the same kind of small, tactical timeline a well-run procurement should permit, not the multi-year programme that defines large platform migrations.
The retire destination
Roughly 30% of a typical estate — about 30 of the 70 consolidation candidates — ends up in the retire bucket. These are the applications where the diagnostic from Post 3 returned no defensible justification. No identifiable owner. No active users. No business function the enterprise still performs. The application is paid for because the contract auto-renews, used because someone forgot to remove their bookmark, and integrated because somebody wired it up five years ago and nobody documented it.
The retirement playbook
The work for each retirement-bucket application is small, repetitive, and concrete.
- Identify active users. The inventory from Post 2 shows access patterns. If the application has had no logins in 90 days, the user count is effectively zero.
- Identify dependencies. Does any other application read from this one? Does any scheduled job depend on it? The integration map from Post 2 surfaces these dependencies.
- Notify and set a sunset date. If there are users, give them notice and a date. If there are dependencies, route the dependencies to alternatives or sunset them along with the application.
- Cancel the contract. Notify procurement, ensure the next renewal does not auto-process. The savings start the moment the renewal does not happen.
- Decommission and archive. Export any data the enterprise has obligations to retain. Decommission the integrations. Close the SSO entry.
The merge destination
Roughly 25% of a typical estate — about 25 of the 70 candidates — ends up in the merge bucket. The function is needed; the enterprise already has another application that performs the same function; the second one is redundant. The work is to migrate the users, migrate the data, retire the duplicate.
Common merge patterns
Multiple project management tools. The classic case. The marketing team uses one tool, the engineering team uses another, the operations team uses a third. The functions are identical at the platform level. Sanction one, migrate the other two, retire the duplicates.
Multiple expense systems. Acquisition debris, almost universally. The acquired company brought its expense system; the parent already had one; both are still running. Merge the acquired estate into the parent system, retire the acquired one.
Multiple survey tools. Shadow IT debris. Each function bought its own survey tool because they didn't know about the sanctioned one. Sanction one, migrate the others, retire the duplicates.
Multiple chat or collaboration platforms. Either acquisition debris or generational drift (the team that started on one platform never moved when the enterprise standardised on another). Sanction one, migrate the others, retire the duplicates.
The merge playbook
- Pick the surviving application. Usually the one with the most users, the strongest enterprise contract, or the cleanest integration into the rest of the estate. Sometimes it is the smaller of the alternatives if the smaller one is genuinely better-architected.
- Assess the data migration scope. Active records that need to move. Historical records that need to be archived. Reference data that has to be reconciled.
- Plan the user migration. Training on the surviving platform. Bulk account creation. SSO mapping. Permissions reconciliation.
- Run a parallel period. Both applications running for a defined window. Validate the data has migrated correctly, the users have onboarded, the integrations have rerouted.
- Retire the deprecated application. Same playbook as the retire destination from this point on.
Most merges complete within a quarter. The longest are the ones with the deepest data history; the shortest are shadow IT applications with little persistent state.
The replace destination
The smallest of the three buckets, typically around 15% of a typical estate. The function is needed; the enterprise does not have an alternative that can absorb the function; the current application is the wrong tool. Replace is the most expensive of the three destinations because it requires evaluating alternatives, running a procurement, and migrating to a successor that nobody has used before.
When replacement is right
- The current application is end-of-life. The vendor has announced sunset, has been acquired and the new owner is winding down the product, or has gone out of business. The replacement is forced.
- The current application is unmaintained. Critical security vulnerabilities are not being patched. The vendor support is unresponsive. Continued operation is a risk.
- The current application is structurally unfit. The requirement has evolved beyond what the application can handle. The function is real and important; the tool is wrong.
- The current application has unsupportable economics. The vendor has materially increased pricing, the value-for-money has eroded, and a comparable alternative exists at significantly better economics.
The sequencing
The order in which the three destinations are executed determines whether the rationalisation programme produces visible savings on a defensible timeline or stalls in the second quarter.
Quarter 1: retirement wave
Run the entire retire bucket. The work is small, repetitive, and concrete. The savings start landing within weeks. The programme produces visible momentum and proves to the CFO that the rationalisation is real. Most enterprises in this phase recover meaningful licence cost in the first quarter alone — enough to fund the rest of the programme.
Quarters 2-3: merger wave
Run the merger bucket in sequence. Pick the highest-impact mergers first — the ones with the largest user populations or the most expensive duplicate licences. Each merger is its own small project; the agent layer (Post 8) handles the data and process integration during the parallel period. The merges complete in waves; by end of quarter three, most are done.
Quarter 4: replacement wave
Run the replacement bucket last. By this point the retire and merge work has produced enough savings to justify the harder work, and the team has built operational muscle on the easier destinations. Replacement decisions are made deliberately, with the cleaner inventory and cleaner integration map that the earlier waves produced.
What “agent-driven” means in this context
The triage framework is straightforward; the execution discipline is where most rationalisation programmes still fail. The agent-driven version of consolidation removes most of the execution failure modes.
Continuous inventory
The agent-driven inventory from Post 2 keeps running through the rationalisation programme. As applications are retired, the inventory updates. As mergers complete, the inventory reflects the consolidated state. The programme's status is visible in real time rather than reconstructed quarterly.
Dependency tracking
The integration map updates as applications retire. The agent layer flags any process that still depends on a retiring application before the cutover, surfacing dependencies the team did not know about. This is the difference between a clean retirement and the retirement that breaks production at 2am the day after.
Parallel-period validation
During mergers, the agent layer runs both applications in shadow mode and validates that the consolidated outcome matches the original. Discrepancies surface early; the merge cutover happens with confidence rather than hope.
Continuous savings tracking
The licence recovery, integration debt reduction, and operational savings are tracked continuously rather than reported quarterly. The CFO sees the programme's ROI accumulating in something close to real time. This is the foundation for the financial case in Post 9.
The legitimate-keep boundary
Throughout the consolidation work, the boundary against the legitimate-keep and legitimate-separate buckets has to hold. The most common failure mode in rationalisation programmes is scope creep in either direction — either the consolidation team starts forcing applications into the consolidation bucket that should have stayed legitimate, or the application owners start lobbying applications out of the consolidation bucket on grounds the diagnostic does not support.
The discipline that holds the boundary is the documentation from Post 4. Every legitimately-separate application has a documented regulatory or contractual basis. Every legitimately-keep application has a documented specialist capability. Anything that cannot produce one or the other is a consolidation candidate. The decisions are defensible because they are grounded in evidence, not opinion.
What to do this quarter
Step 2: sequence the work. Retire wave first, merger wave second, replacement wave last. Resist the temptation to start with the most strategic application; start with the easy ones to build momentum.
Step 3: publish the savings target. The retirement bucket alone is typically large enough to produce meaningful first-quarter savings. Commit to a number; track it weekly.
Step 4: run the agent-driven inventory continuously. The programme's status should be visible in real time, not reconstructed at quarterly steering committees.
Step 5: hold the boundary against scope creep. Applications that should be in the consolidation bucket and try to escape into legitimate-keep need a documented capability case. Applications in legitimate-keep that get challenged need the same.
Closing
The 70% rule is the diagnostic counterpoint to the legitimate-separation cluster from the previous two posts. Once you have done the honest work of identifying the applications that must remain separate, the majority of what remains is consolidation territory. The triage into retire, merge, or replace is concrete; the sequencing matters more than most programmes recognise; the savings live in the early waves.
The next post takes the largest single source of consolidation candidates — M&A integration debris — and walks the specific architectural pattern that solves it. Most acquisitions never finish their IT integration. The agent-driven approach makes that survivable.
Triage. Sequence. Execute. The 70% is where the savings live.
VoltusWave runs the triage as part of the rationalisation engagement. Each consolidation candidate gets a destination, a sequence, and a tracked outcome. The agent layer handles the integration during merges, the dependency tracking during retirements, and the savings measurement throughout. The programme produces visible savings on a defensible timeline.