Governing an Application Portfolio When the Portfolio Keeps Changing Shape

The application portfolio management frameworks written by analysts assume something that most real estates do not provide: a reasonably stable set of systems, owned by identifiable people, costed with some accuracy, and reviewed on a cadence the organisation actually keeps. If that describes your environment, the standard guidance applies. If your estate has been reshaped by an acquisition in the last three years, or a platform migration that is still running, or a wave of shadow IT that emerged during a remote-working period, then the standard guidance will produce a tidy document and not much else.

Application portfolio management best practices, when written for a stable estate, are genuinely useful. The challenge is that most of the organisations that most need portfolio discipline are also the ones whose portfolios are least stable. Acquisitions bolt on new systems faster than they can be classified. Vendor contracts get renewed quietly, and the system that was earmarked for retirement gets extended for another three years without anyone updating the record. A platform migration that was supposed to consolidate twelve systems into four is still running, and nobody is quite sure which of the twelve have been decommissioned and which are still live.

This post is about what application portfolio management looks like when the portfolio keeps changing shape. Not theory, not a framework diagram, but the specific practices that survive contact with an estate nobody can fully pause long enough to photograph.

What do application portfolio management best practices look like when the estate is unstable?

The standard framing for portfolio management, including Gartner's TIME model (Tolerate, Invest, Migrate, Eliminate) and the pace-layering concepts that sit alongside it, works well when you have enough clarity about each system to place it in a category. The gap in a shifting estate is not the framework. It is the data, the ownership, and the cadence assumptions underneath the framework.

The most durable practice in a changing estate is to decouple classification cadence from business layer. Gartner's pace-layering concept, originally developed in the context of enterprise architecture, distinguishes between systems of record (which change slowly), systems of differentiation (which change on a business cycle), and systems of innovation (which change fast and sometimes disappear). If you review all three layers on the same annual cycle, you are either reviewing your fastest-moving systems too slowly to catch problems, or reviewing your most stable systems more often than necessary.

A practical mapping for most estates: systems of record reviewed annually, with a lightweight quarterly check on cost and ownership. Systems of differentiation reviewed every six months, because they are where business requirements press hardest against technical constraints. Systems of innovation reviewed quarterly or on a project cadence, because by the time the annual review arrives, several of them will have been replaced, abandoned, or quietly adopted as permanent infrastructure despite being procured as experiments.

The discipline is not in the framework. It is in holding the cadence when a major programme is running and the temptation is to defer everything until it finishes.

How do you keep an application inventory accurate when systems keep being added or changed?

The question of inventory accuracy comes up in almost every portfolio engagement. The honest answer is that no large estate has a fully accurate inventory at any given moment. The practical goal is not perfection. It is a process that keeps the inventory close enough to reality to support decisions, without requiring a dedicated programme every time something changes.

The technique that works consistently is what some practitioners call event-driven inventory maintenance. Rather than scheduling an inventory refresh as a standalone exercise, you attach the maintenance obligation to governance events that already exist in the organisation.

A change advisory board approval is a natural moment to confirm that the system being changed is correctly recorded in the portfolio. A contract renewal - especially a software licence renewal - is a natural moment to confirm whether the system is still classified the right way and still owned by the right person. A new vendor onboarding event is a natural moment to add a system that might otherwise enter the estate invisibly. A merger or acquisition integration workstream is a natural moment to bring acquired systems into the inventory, even if their classification will be provisional for the next twelve months.

The failure mode is relying on a dedicated inventory exercise that happens once a year or once every two years. In an estate of any complexity, the gap between exercises is long enough for the inventory to become materially wrong. Systems get extended, integrated, or quietly kept alive by a third-party vendor, and none of that shows up in a record that is only updated when someone schedules the time to update it.

The practical minimum is a named owner for each system, a cost figure that is updated at contract renewal, and a classification that is revisited when the system's business context changes. That is not comprehensive. It is enough to avoid the worst decisions.

Why do application portfolio management processes fail even when the framework is right?

There is a pattern that appears repeatedly in failed portfolio management programmes. The analysis is thorough. The classification is defensible. The report lands on the right desks. And then nothing changes, because nobody in the room has clear authority to decommission a system that three different business units say they depend on, or to redirect the budget currently paying for its maintenance.

Gartner research on application portfolio management consistently identifies governance structure, specifically the absence of a decision-making body with explicit investment and retirement authority, as a primary reason portfolio management programmes stall. The analysis produces a list. The list does not produce decisions because decisions require someone with authority over money and someone with authority over operations to agree at the same moment, and that alignment is not automatically created by a framework.

The governance structure needs to be settled before the first classification exercise begins, not after the results are ready. The practical minimum is a small group with representation from technology, finance and operations, meeting on a fixed cadence, with a documented mandate to approve investment, approve retirement and approve the toleration of systems that will not be changed in the near term.

Finance must be in the room. Without finance, the conversation about which systems to fund and which to retire stays theoretical. A technology leader can classify a system as ready for retirement, but if the budget to maintain it is embedded in a business unit's operational cost base, the retirement decision requires a finance conversation that most technology governance bodies do not have the standing to initiate.

The comfortable assumption is that the governance structure can be created as needed. The reality is that the moment a portfolio review produces a contentious recommendation, the absence of a governance body with clear authority becomes the reason the recommendation is deferred, and the deferral becomes the default.

When should you stop portfolio management activity rather than continue it?

This is the recommendation that rarely appears in practitioner guidance, because it runs against the implicit message that more portfolio management is always better than less. Sometimes the right decision is to stop.

The conditions that justify pausing are specific. An acquisition that is actively integrating systems from the acquired company means the portfolio is changing faster than classification decisions can usefully be made. Classifying a system as "invest" or "migrate" when you do not yet know whether the acquiring entity or the acquired entity will own the relevant business process is an exercise in producing work that will need to be redone. The same applies during a core platform migration. If the organisation is in the middle of moving from one ERP system to another, the systems that sit around the ERP are connected to a moving target. Classification decisions made mid-migration often need to be revisited when the migration completes and the actual integration points are clear.

The practical move is to freeze low-priority rationalization activity, concentrate on impact identification, and document what is known about affected systems without committing to classification outcomes. The key distinction is between maintaining the inventory, which should continue, and making retirement or investment decisions based on that inventory, which can wait.

The risk of continuing full portfolio management activity during a major change is that it produces a volume of work that feels productive but is not durable. Classification decisions made on incomplete information have to be revisited. Revisiting them consumes the credibility of the programme, because stakeholders reasonably ask why they were asked to contribute to an exercise whose conclusions did not last. Pausing and restarting is a more defensible posture than producing outputs that need to be corrected.

How should application portfolio management practices change after an acquisition?

Acquisitions are the most common reason a portfolio management programme breaks down. The existing estate had a governance cadence. The acquisition adds a second estate with different ownership structures, different technical conventions, different cost models, and sometimes a different relationship to the same underlying business process. The temptation is to classify the acquired systems quickly, because uncertainty is uncomfortable and stakeholders want a plan.

The practical advice is to resist that temptation for at least the first three months. What looks like a duplicate system from the outside often turns out to have a customer-facing function, a regulatory reporting obligation, or an operational dependency that is not obvious until someone has spent time with the people who use it. A system classified for retirement before its actual dependencies are understood is a risk, not a plan.

The sequence that works consistently in post-acquisition portfolio work is: inventory first, dependency mapping second, classification third. Inventory means getting every system from the acquired estate into a single record with a provisional owner assigned. Dependency mapping means understanding which systems connect to which, and which business processes depend on which systems, before making any classification decisions. Classification only becomes reliable once those two steps have produced enough clarity to reason from.

Konnectedly's post-acquisition assessment work consistently shows that the systems most likely to be misclassified are the ones that were acquired as part of a larger platform and have since been modified to serve a function the original vendor did not anticipate. Those systems look like commodity applications from the outside. They are often load-bearing in ways that only become visible when someone tries to retire them.

What does good application portfolio management discipline actually produce?

It is worth being direct about what the discipline produces, because the answer is narrower than most framework descriptions suggest. Portfolio management does not produce a strategy. It does not produce a roadmap. It produces the input that makes a strategy and a roadmap possible: a set of classification decisions, made by people with authority, based on data that is current enough to trust.

The toleration category is where the most honest work happens. Every estate has systems that are not worth investing in and not worth retiring. They run. They cost something. They serve a function that would be expensive to replace and that has not changed in years. The right answer for those systems is to leave them alone, track the cost, document the conditions under which the verdict would change (usually a failure event, a regulatory change, or a cost threshold), and move attention to the systems where a decision will make a material difference.

A portfolio management programme that always concludes "modernize" is an advertisement. The estates that benefit most from portfolio discipline are the ones where the honest answer for a large fraction of the systems is "tolerate it, track the cost, revisit in eighteen months". That answer requires the same analytical work as a modernization recommendation. It simply produces a different verdict, and a different budget conversation.

The discipline is not about finding systems to modernize. It is about knowing which systems to leave alone, which to invest in, and which to retire, and having the governance structure to act on all three verdicts when the evidence supports them.

Frequently Asked Questions

What are application portfolio management best practices for a portfolio that changes frequently?

Treat governance as a continuous process rather than an annual event. Classify systems by rate of change, not just by business function. Review the fastest-moving layers quarterly, the stable core annually. Lock down decision rights before the next acquisition or platform migration arrives, because the portfolio will shift again before the review cycle finishes.

How often should an application portfolio be reviewed?

There is no single correct cadence. Systems that support frequently changing business processes should be reviewed every quarter. Core operational platforms that rarely change can be reviewed annually. The error is applying one cadence to everything. A single annual review misses the systems that changed three times during the year and therefore needs no action now.

What is the biggest mistake organisations make in application portfolio management?

Treating the portfolio as a list to be counted rather than a set of decisions to be maintained. An inventory that is not connected to funding, ownership and change authority decays within months. The practical failure is that nobody updates the record when a system is extended, integrated with something new, or quietly picked up by a third-party vendor during a contract renewal.

How do you maintain an accurate application inventory when systems keep changing?

Attach inventory maintenance to events that already happen: change advisory board approvals, contract renewals, procurement sign-offs and new vendor onboarding. Each of those moments is a natural trigger to update ownership, cost and classification data. Waiting for a dedicated inventory exercise means waiting for a window that rarely opens cleanly.

What is the right governance structure for application portfolio management?

A small, senior decision-making group with explicit authority over application investment, retirement and toleration decisions. It needs representation from finance, operations and technology. Without finance in the room, decisions about which systems to fund or retire stay theoretical. The group should meet on a fixed cadence and have a mandate to say no, not just to review.

When should an organisation pause portfolio management activity rather than continue it?

During a major acquisition, a platform migration or a significant organisational restructure, the portfolio itself is too unstable for meaningful classification decisions. The practical move is to freeze low-priority rationalization activity, focus on identifying which systems will be affected by the change, and restart classification work once the shape of the new estate is clear enough to reason about.

Does application portfolio management require specialist tooling?

Not at the start. The discipline is about decision rights and governance cadence, not software. Many organisations run effective portfolio management on shared spreadsheets for the first year while they establish what data they actually need. Tools add value once the process is stable enough to know what it needs to track. Buying the tool first tends to shape the process around the tool's data model, which is usually the wrong model.