Post-acquisition application portfolios often contain systems inherited through several earlier acquisitions. The applications remain operational, but the organizational structures that originally owned them may no longer exist.
This creates several practical problems:
A technical team may support an application without owning its business value.
Users may remain, but no business owner may be accountable for the total cost or risk.
Several teams may depend on parts of the application while none can make a lifecycle decision.
Licenses, contracts and infrastructure may continue because nobody has clear authority to retain, replace or retire them.
Application rationalization should therefore begin with ownership, not with a list of systems to remove.
A workable approach is to:
- Create a complete application inventory.
- Confirm actual users and the current business purpose.
- Map technical, process and data dependencies.
- Establish visibility of licensing, hosting, support and control costs.
- Assign a business owner and a technical owner.
- Record the decision to retain, consolidate, replace or retire the application.
- Assign actions, dates and accountability for completing that decision.
Ownership is not about allocating blame for a decision made before the acquisition. It establishes who can assess current value, accept risk and remain accountable for the next lifecycle decision.
Without that step, rationalization decisions tend to move between teams while costs and risks continue. With it, the portfolio can be assessed using consistent evidence rather than organizational history or informal influence.
What governance mechanism has worked in your organization for assigning ownership to inherited or orphaned applications?
