Most technology portfolio discussions eventually arrive at the same question: should we build it or buy it? The question is familiar and easy to frame however it has become too narrow for the decisions that technology leaders now face. A typical organisation holds hundreds of capabilities, each at a different point of value, age and risk. Some deserve fresh investment, some are best left alone, and some should be switched off altogether. A two-option choice cannot describe that spread, and it tends to steer decisions towards the two routes that cost the most.
The price of getting these decisions wrong continues to rise. McKinsey found that the direct cost of technology debt, once its effect on profit and loss is properly measured, can reach 40 to 50 percent of total investment spend. The UK public sector illustrates how quickly the problem compounds when decisions are deferred, with legacy technology making up an estimated 28% of central government systems in 2024, up from 26% the year before. Visibility is part of the challenge, with around 15% of the organisations interviewed for the State of Digital Government review unable to describe their own legacy estate.
AI has added a further layer of complexity. It has changed the cost, speed and risk of several options at once, which means a decision made three years ago may no longer hold today. This article sets out six routes available for any capability, five tests for choosing between them, and the specific ways in which AI has shifted the balance.
Six routes for every capability
Retain:
The first route is to retain a capability as it is, with routine maintenance. Retaining suits systems that are stable, meet current needs and face little demand for change. It is a legitimate decision in its own right, although it works best when it is made deliberately and paired with a date for review, so that "retain" does not quietly become "neglect".
Typical fit: Stable, low-change, acceptable risk
Retire:
The second route, to retire, is the most overlooked in most portfolios. Retiring a capability means decommissioning it and either moving its users elsewhere or confirming they no longer need it. Duplicated tools, low-use reporting systems and applications kept alive for a handful of users are common candidates. AWS guidance offers a useful starting point, suggesting a closer look at applications where average CPU and memory use sits between 5 and 20 percent over 90 days, or where nothing has connected to the application over that period.
Typical fit: Low value, duplicated or low use
Buy:
To buy is to adopt a packaged product or software as a service. This route suits capabilities that are common across an industry and where the organisation is comfortable adopting standard processes.
Typical fit: Common capability, standard process
Configure:
Closely related, is the option to configure – extending a platform the organisation already owns, such as an ERP, CRM or low-code environment. Configuration is often faster and cheaper than any other route, yet it is easily overlooked because it rarely looks like a project worth a business case.
Typical fit: Owned platform can meet the need
Modernise:
To modernise is to improve an existing system in stages, whether by moving it to a new platform, refactoring components or replacing parts incrementally while the rest continues to run. Modernisation suits systems whose core logic remains fit for purpose but whose underlying technology limits the pace of change.
Typical fit: Appropriate logic, limiting technology
Rebuild:
Finally, to rebuild is to write the capability again from the ground up. Rebuilding offers the greatest control over the result, and with it the greatest delivery risk and the heaviest demand on the organisation's people and budget.
These routes will feel familiar to anyone who has planned a cloud migration, since the AWS "7 Rs" which build on a set of migration strategies Gartner identified in 2019. Those models were designed for moving workloads into the cloud. The six routes described here are broader, applying to any capability decision whether or not a cloud move forms part of it.
Typical fit: High value, high control, high capacity
Five tests for choosing a route
Choosing well depends on judging every route against the same criteria. Consistent scoring gives leaders a defensible basis for the decision, a clear record for audit, and a way to compare very different options on equal terms.
1. Business value
Leaders should ask whether the capability differentiates the organisation or is common to every competitor, how much revenue, service delivery or regulatory compliance depends on it, and what would happen if it were unavailable for a week. High-value, differentiating capabilities justify routes that preserve control, while low-value capabilities are strong candidates for retirement or a packaged product.
2. Lifetime cost
This matters far more than the initial outlay, which is usually a small part of the total. A realistic lifetime view covers licences, hosting, support, specialist skills, integration, change requests and the eventual cost of exit, typically over a five to ten year horizon. It is worth paying particular attention to costs that rise over time, such as licence increases or the growing premium on scarce legacy skills, and to the cost of leaving a route once the organisation has committed to it.
3. Control
This covers the roadmap, the data and the intellectual property. The key questions are whether the organisation needs to decide when and how the capability changes, whether it holds proprietary data or process knowledge, and how dependent a given route would make the organisation on a single supplier. McKinsey's analysis of technology budgets supports the value of retaining control over critical work: the organisations it describes as deliberate modernisers rely on internal teams for critical change projects, allocating 16 percent of their technology budgets to internal staff working on change.
4. Risk
Risk spans delivery, operations, security and regulation. Leaders should consider how likely each route is to overrun or fail, the operational impact if a change goes wrong, and whether the capability depends on a small number of people who understand it. One question often proves decisive: can the system's current behaviour be documented and tested before anything changes? Our companion article on test debt explores this in depth.
5. Capacity for change
This is an assessment of the organisation itself. It asks whether teams have the skills and time a route demands, whether suppliers can support it alongside their other commitments, and whether the wider business can absorb the associated process and training change. In our experience, this test removes more options than any other. A rebuild that scores well on value and control will still struggle if the organisation cannot resource it.
What AI has changed
The six routes and five tests remain the same in an AI-enabled world. What AI has altered is the score each route earns against those tests, and six shifts matter most.
The first concerns discovery, which has always been one of the largest costs in any legacy decision. Before teams can decide what to do with a system, they must work out what it actually does, often with little documentation and few remaining experts. AI tools now carry much of that effort, with McKinsey describing agents that work to derive the intent of legacy systems as the basis for modernisation. More effective and efficient discovery strengthens the case for modernisation and allows retirement to be planned with far greater confidence.
The second shift is in the cost of modernising and rebuilding, where the effort estimates behind many past decisions are now out of date. McKinsey reports that AI agents can deliver a 40 to 50 percent acceleration in modernisation timelines and a 40 percent cost reduction.
The third shift is a counterweight to the second, since faster delivery brings new stability risk. Google's DORA research found that higher AI adoption is associated with increases in both delivery throughput and delivery instability, and describes AI as an amplifier that magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones. An AI-assisted rebuild therefore needs stronger testing, review and release discipline than a conventional one, and organisations with weaker engineering practices should score the risk accordingly.
The fourth shift affects the buy and configure routes, as packaged software evolves at unprecedented speed. Gartner predicts that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from less than 5% in 2025. This raises the value of packaged products and of platforms already in place, while also raising new questions under the control test, such as, who owns the data an agent learns from, how is agent behaviour governed, and what happens to that capability if the organisation later moves on.
The fifth shift is that control itself now carries more weight. AI draws its value from data and process knowledge, so capabilities that hold proprietary data, distinctive workflows or deep domain logic have become more strategically important than they were. Passing them to a supplier may also pass on the raw material for future AI advantage, which gives leaders good reason to revisit the control score for any capability where this applies.
The sixth shift opens up new retirement options. Some capabilities exist largely to move information between people or systems, such as manual triage queues, bespoke reporting tools and simple workflow applications. AI features within platforms the organisation already owns can now absorb many of these, so a portfolio review should include a deliberate search for capabilities whose job an existing platform could take over.
Applying the framework
A worked example shows how the tests interact when applied to a single decision. Consider a large insurer reviewing its policy administration platform, a fifteen-year-old system that is heavily customised and supported by a small team nearing retirement. The business wants to launch new products faster, and the platform has become the main constraint.
Retain: Fails on risk: key-person dependency grows each year
Retire: Fails on business value: the capability is core
Buy: Strong on lifetime cost, weak on control of product rules
Configure: Not viable: no owned platform covers policy administration
Modernise: Strong on value and control; AI-assisted discovery reduces risk
Rebuild: Strong on control, fails on capacity for change
Modernisation emerges as the lead route, although the analysis becomes more useful when applied to individual components. The platform's reporting module duplicates the insurer's existing data platform and can be retired. The broker portal can be configured on the insurer's CRM. The product rules engine, which holds the insurer's pricing knowledge, is modernised in stages using AI-assisted code comprehension. A single capability ends up taking three separate routes, which is a common outcome - assessing components individually frequently produces a cheaper and safer plan than treating a system as one indivisible unit.
An iterative approach to review and decision
The economics behind route decisions are now moving faster than most review cycles. AI tooling improves every few months, and packaged products add significant capabilities each quarter, so a route that was right in 2023 may today be the second-best option.
Audacia's view is that route decisions should be recorded alongside their test scores and revisited on a fixed cycle, typically once a year for critical capabilities. That record makes clear which assumptions drove each choice, so when an assumption changes, such as the cost of modernisation or the maturity of a packaged product, the decision can be reopened based on evidence.
Across our delivery work, the strongest portfolio plans share three habits – they assess capabilities at component level as well as system level, they weigh capacity for change and they treat retain and retire as active decisions deserving the same detail as a rebuild. Organisations that adopt these habits spend less on the wrong routes and move faster on the right ones.
