Reconciling maintenance and support contracts after a deal is where steady, recurring cost meets inherited risk. Maintenance and support fees are charged year after year, often as a fixed percentage of an original license value, and a merger inevitably produces duplicate, mismatched, and orphaned support agreements. Reconciling maintenance and support contracts means mapping every active agreement across both estates, matching support to the systems that actually need it, and removing duplication without dropping coverage that would be expensive to reinstate. The trap is that maintenance looks like a simple line to cut, until a dropped agreement carries a reinstatement penalty that costs more than the support ever did.
This guide explains how to reconcile a merged maintenance estate safely. It is a core workstream in post close license reconciliation and one where careless cuts create more exposure than they save.
Reconciling maintenance and support contracts: the inherited picture
After a deal, the combined entity inherits every support agreement both companies held, including ones tied to systems that are being retired and ones no longer matched to any active deployment. The first task is to map them: which products are under maintenance, on what terms, at what annual cost, and against which deployments. This mapping almost always reveals support being paid on software no one runs, and conversely systems running with no support behind them. The reconciliation closes both gaps, dropping the orphaned support and securing coverage where a business critical system is exposed. This mapping depends on the deployed and contracted views being reconciled first, which is the work of building the combined entity license position.
Support from the major publishers carries the most weight, because Oracle, SAP, and IBM tie maintenance to specific licensing terms and treat lapses and reinstatements punitively. Reconciling support for those estates is inseparable from reconciling the underlying licenses, which is why this connects to reconciling Oracle licensing after a merger, where support policy and license metric move together.
The reinstatement trap
The single most expensive mistake in maintenance reconciliation is dropping support to save a fee, then needing it back. Major publishers do not let a customer simply restart lapsed maintenance at the old rate. Reinstatement commonly requires paying the back maintenance for the lapsed period plus a penalty, which can exceed the cost of having kept the support running. The reconciliation therefore distinguishes carefully between support that can be dropped permanently, because the system is genuinely being retired, and support that merely looks droppable but would have to be reinstated at a premium. Cutting the second kind is a false saving that surfaces as a larger bill later.
This is why maintenance is reconciled against a clear systems roadmap, not against the fee schedule alone. A support agreement on a system scheduled for decommission within the term can be allowed to lapse deliberately. A support agreement on a system the combined entity will keep should never be dropped to chase a short term saving, because the reinstatement cost erases it.
Key takeaways
- A merger produces duplicate, mismatched, and orphaned maintenance agreements that are rarely compared side by side.
- Support is often paid on retired systems while business critical systems run with no coverage at all.
- Dropping support to save a fee can trigger a reinstatement penalty larger than the support itself.
- Reconcile maintenance against a systems roadmap, not against the fee schedule alone.
- Major publisher support is tied to license terms, so the two must be reconciled together.
Removing duplication without dropping needed coverage
Where both companies hold support for the same product, the reconciliation keeps the agreement matched to the system the combined entity will retain and unwinds the other, timed to its renewal to avoid an unnecessary term. Where support tiers are over scoped, paying for a premium response level the business does not need, the reconciliation steps the tier down rather than dropping it entirely. The principle throughout is to match support precisely to need, removing what is genuinely redundant while protecting coverage on anything the business depends on. The recovered cost flows into the wider deduplicating software spend after an acquisition programme.
Using consolidation as leverage on support terms
A merger increases the combined entity's footprint with each major publisher, which is leverage that maintenance reconciliation can use. Consolidating two support relationships into one larger one is a moment to renegotiate the maintenance rate, cap future uplifts, and align renewal dates rather than simply continuing both on their old terms. A publisher facing a larger, consolidated customer has reason to hold the rate to keep the whole estate under support. The buyer that approaches the renewal with a mapped, reconciled position negotiates from strength rather than accepting the sum of two legacy agreements.
Recommendations for buyers
- Map every maintenance agreement across both estates against the systems each actually supports.
- Drop support only on systems with a confirmed decommission date, never on systems being kept.
- Check the reinstatement penalty before lapsing any support that might be needed again.
- Secure coverage on business critical systems found running with no support behind them.
- Reconcile major publisher support together with the underlying license terms.
- Use the larger consolidated footprint to renegotiate rates, cap uplifts, and align renewal dates.
Why an independent advisor reconciles maintenance
Reconciling maintenance puts a buyer across the table from publishers whose support revenue depends on keeping every agreement running at full rate. An independent, buyer side advisor maps the merged estate, tests each agreement against real need and the reinstatement risk, and negotiates the consolidated terms without a stake in the publisher relationship. That independence is what lets the combined entity cut genuine duplication while keeping the coverage that matters.