Executive Summary
Applications do not earn modernization by getting old. They earn it when a business constraint can be named, priced, and traced to them.
Most modernization decisions are argued from technology preference and settled by whoever argues longest. This article replaces that with an evidence-based decision in two stages: first where the ownership boundary sits, then which transition path removes the constraint at the lowest risk to continuity. It closes with Hancocks, a UK wholesaler that tripled its platform capacity through a phased modernization rather than a rebuild, scored against the framework using published figures.
Takeaways
- Ownership comes before engineering. Decide where the ownership boundary sits before debating rehost against rebuild. Many hard cases settle the ownership question at retire or standardize before the modernization-path debate begins.
- One decision sets the ownership boundary, five scores describe the constraint, two gates test the program. Change friction, operational risk, access constraint, coupling, and data complexity describe the system. Economics and delivery readiness decide whether the recommendation survives contact with your team.
- Unknown is a legitimate score. Undocumented schemas and single-person knowledge are reasons to run a short discovery, not a Medium by default.
- The smallest sufficient intervention wins. A rewrite is one option on the menu, and it sits last, behind everything cheaper and safer.
- Hancocks tripled capacity without rebuilding the commerce core. Concurrent users went from 100 to 300, page loads got 50% faster, and a phased modernization kept the wholesale business trading throughout.
Legacy Is A Constraint, Not An Age
An application becomes a modernization candidate the day a business constraint can be traced to it, and not a day before. That is the claim this article defends, and it cuts both ways. A 15-year-old system that ships policy changes in a week and feeds your analytics cleanly is not automatically a modernization priority. A five-year-old one that turns every reorganization into a development project does.
The money involved is not small. Deloitte’s 2026 Global Technology Leadership Study estimates that technical debt accounts for 21% to 40% of an organization’s IT spending. A separate Deloitte survey, published in August 2026, covered 501 US leaders whose organizations were already at least piloting agentic AI. Even among these active adopters, data access remains a material constraint: 72% reported lacking unified and accessible data, and only 42% rated their organization prepared on data.
The constraint usually stays invisible until a business event forces it out. A distributor reorganizes two business units into three and discovers that pricing rules live in code, so a commercial decision becomes a development queue. A lender’s approved AI forecasting pilot stalls for a quarter because no governed path exists from the system of record to the model. In our assessment calls the opening question is rarely whether to modernize. It is which migration program to buy, and the application in question has usually never been scored at all.
Once the evidence is assembled, the scoring itself usually fits into half a day per application. Assembling the evidence is where the work sits, and the rest of this article is the method.
Ownership First, Engineering Second
A modernization call is two decisions wearing one name, and most frameworks blur them. The first is a portfolio decision: should the business keep investing in this capability, and which parts of it still justify tailored software? The second is an engineering decision: given what we keep, what is the least disruptive path that removes the constraint?
The first decision sets an ownership boundary rather than picking a side. Retire the capability if the business no longer needs it. Standardize it on a product if the capability matters, holds little differentiated logic, and a viable product can meet the required constraints. In many enterprise systems the honest answer sits between those poles: a packaged core with tailored layers around it, so the real question is which layers remain tailored and which are standardized on products. Wherever tailored ownership survives, the engineering menu opens: retain as-is, remediate, rehost, replatform, refactor, rearchitect incrementally, or rebuild in phases.
Cloud vendors publish their own menus of migration options. AWS’s 7Rs are broader than they look: retire, retain, and repurchase sit alongside the engineering moves, and AWS applies them during portfolio assessment. This framework is complementary rather than competing. It specifies the evidence used to choose an option, separates the custom-ownership decision from the engineering path, and holds up when cloud migration is not the objective at all. Answer ownership first and half the architecture arguments dissolve before they start.
THE CORE PRINCIPLE
The Smallest Sufficient Intervention Wins. A rewrite is the most expensive item on a menu you should read from the top. Retaining, remediating, rehosting, and replatforming all come before it, and whichever of them removes the constraint is the cheaper, safer answer
Decision 1: Set the Ownership Boundary
The first step is not a score. It sets a boundary, starting from two questions answered separately, because they can disagree. Does the capability still matter, and for how long? And which workflows, data, or interfaces create enough advantage to stay tailored? Payroll can be vital to the business and still be better standardized on a product, because vital and differentiating are different things.
If the capability is no longer required, retire it. If it matters, holds little differentiated logic, and a viable product can meet the operational, regulatory, and integration constraints, standardize on that product. If only some layers differentiate, keep ownership of those layers and standardize the rest. Every non-retirement outcome then moves into the five scores below, because a product replacement can be just as constrained by data, coupling, and continuity as a modernization. And if the value or the boundary is unknown or disputed, the honest output is a discovery.
Five Scores for the Constraint
Score the five constraint factors Low, Medium, High, or Unknown, with High always meaning greater constraint or risk. Every score carries three attachments: the evidence behind it, a confidence level, and an owner. A bare High is an opinion. A High backed by deployment lead times pulled from your CI system is a finding. The numeric boundaries teams use vary by industry and service level, so calibrate against your own portfolio rather than importing someone else’s thresholds; 90 days to onboard a regulated banking partner may be fine while 90 days to add a routine commerce channel is a lost season. The anchors are:
- Low: within agreed business and risk tolerances, with no approved outcome constrained.
- Medium: recurring, measurable friction or rising exposure, with workarounds still viable.
- High: blocks an approved business outcome, breaches risk tolerance, or costs disproportionate effort.
- Unknown: evidence missing, disputed, or too weak to support a decision.
Do not add or average the scores. This is a decision profile, not a maturity index: decision 1 settles ownership, and the five scores point to the smallest sufficient intervention.
1. Business and Change Friction
Which material business changes are being delayed or blocked? Count the policy, pricing, and organizational changes in the last year that required code to express. Measure the lead time from approved request to production, and weight materiality as well as count; frequent low-impact releases are not evidence of high friction. Include the front of the system in this factor: teams keeping shadow spreadsheets, copying data between screens, or taking weeks to onboard a new hire are paying a change tax that never appears in a ticket queue.
2. Operational, Security, and Lifecycle Risk
Incident frequency and severity, availability and recovery performance, latency and capacity ceilings, the maintenance cost trend, open critical vulnerabilities, unsupported runtime components, and vendor end-of-life exposure. Track two amplifiers alongside: knowledge concentrated in one or two people, and platform versions the vendor has abandoned. A confirmed critical vulnerability on an unpatchable component is one of the few signals that justifies immediate containment before the rest of the scoring finishes; active exploitation, serious data corruption, and compliance breaches sit in the same category.
3. Integration, Data, and AI Access Constraint
How hard is it for approved systems, partners, and AI initiatives to reach the right data and capabilities through governed interfaces? Measure the calendar time from a signed integration request to live traffic, and from a data request to governed access. AI raises the bar rather than changing the question: an agent needs its own identity with scoped permissions, a governed interface to call, and data fresh enough to act on. An application designed for human logins at human pace often exposes too little of that safely. The Deloitte readiness figures above are this factor showing up at survey scale.
4. Architecture Coupling and Extraction Difficulty
If you had to change one domain inside this application, how much of the rest would move with it? Assess how tightly the parts are coupled, how far a single change ripples, test coverage, and whether releases can ship independently. This factor helps determine whether incremental paths are available: a system whose valuable domains can be isolated behind an interface can be modernized piece by piece. Where domains cannot be isolated, incremental options narrow and the cost and risk of change rise.
5. Data Integrity and Migration Complexity
Whether the schema is documented, whether records stay consistent across tables, who owns each data domain, how much is duplicated, and how much of the business logic lives undocumented inside the data itself. This factor does not veto any outcome. What it governs is sequencing: a High here means any path involving migration needs its own data workstream, phased cutover, and reconciliation plan. Data movement is often the highest-risk workstream on the plan.
If an Unknown could change the ownership decision or remove a primary engineering path, stop and run a time-boxed discovery. Materiality decides, not the count: the absence of evidence is itself the finding, and committing to a target architecture without it is how rebuilds fail.
Two Gates That Test the Organization
The boundary decision and the five scores describe the application. Two gates describe you, and they sit outside the scorecard deliberately, because mixing them in is how frameworks change their answers halfway through.
The economic gate asks whether the value created or protected justifies the cost, the period of running old and new systems in parallel, and the transition risk. Build the payback case from your own operational savings and quantified risk reduction rather than from a vendor’s benefit slide. The gate has three outcomes: proceed, resize or resequence the intervention, or do not proceed and record the accepted risk with an owner and a review date. A long payback does not always mean shrink the intervention; sometimes the constraint is real but not yet worth removing.
The delivery-readiness gate asks whether the organization can execute the chosen path: the platform knowledge, the leadership attention, and the engineering capacity to run old and new side by side. It can approve the route, change sourcing or the interim architecture, or defer until the organization can sustain the target. A target the organization cannot sustain is not the correct target. What a failed gate must not do is pretend the constraint has disappeared; a stopped program records the risk it accepted, with an owner and a dated review.
That is the whole framework. One decision on the boundary, five scores on the constraint, two gates on the program, and a discovery whenever the evidence runs out.
From Scores to a Primary Path
When several scores land High, find the constraint tied to the largest approved business outcome or the sharpest breach of risk tolerance, and let that set the primary path. Treat the other Highs as prerequisites or parallel workstreams only where they independently threaten the outcome. A page of High scores is not a mandate for a full-estate transformation program.
The map translates the ownership boundary and the dominant constraint into a starting path. Read the rows as positions to argue from, not rules that close the argument, because a single regulatory finding can outweigh every operational score on the card.
| Stage 1 · The ownership boundary | |
| Capability no longer required by the business | Retire |
| Little differentiated logic, and a viable product exists | Standardize on that product |
| Some layers differentiate, the rest do not | Keep those layers, buy the rest |
| Capability value or boundary unknown or disputed | Discovery before commitment |
| Stage 2 · The transition path, for every non-retirement outcome | |
| Standardizing on a product | Phased or full replacement, then decommission |
| Fit for purpose, within risk tolerance | Retain, with a dated review |
| Sound logic; hosting infrastructure is the constraint | Rehost |
| Sound logic; runtime or platform unsupported, or the platform caps scale or blocks governed access | Replatform or upgrade |
| Localized security or maintainability exposure | Remediate |
| Localized code quality problems | Refactor |
| Strategic capability constrained by structural coupling | Rearchitect incrementally |
| Implementation no longer economically recoverable | Rebuild in phases |
| Stage 3 · The gates | |
| Both gates pass | Proceed |
| A gate partly fails | Resize, resequence, or change sourcing |
| A gate fails materially | Defer or stop; record the accepted risk |
The discovery rows matter most. CTOs reach for modernization precisely when documentation and ownership are weakest, and a framework that forces certainty where none exists is worse than no framework at all.
Hancocks: Tripling Capacity Without Rebuilding the Commerce Core
Hancocks is the UK’s leading B2B confectionery wholesaler, trading since 1962, with over 3,000 products across 14 stores and an Adobe Commerce platform that had become the constraint. The results first, then how the framework explains them.
The scorecard below shows how the framework explains those results. The published evidence supports a partial scorecard, including two Unknowns the assessment had to resolve before the transition architecture was committed.
| Factor | Result | Evidence | Confidence |
|---|---|---|---|
| Ownership boundary | Split by layer | Adobe Commerce remained the packaged transactional core; the B2B experience and business-specific workflows stayed tailored; content, search, and recommendations moved to specialist platforms | High |
| Change friction | High | Marketing edits went through the Magento admin and promotional updates took days | High |
| Operational and lifecycle risk | High | Database deadlocks cascading into crashes, over 100 plugins and 100 cron jobs, page loads past six seconds | High |
| Access constraint | Unknown | The published case shows search and discovery limits, which measure experience rather than governed access; no baseline integration evidence is public | High that public evidence is insufficient |
| Coupling and extraction difficulty | Medium | Tightly coupled core, but content, search, and recommendations had viable component boundaries | Moderate |
| Data and migration complexity | Unknown | The published case documents the phased execution, not the baseline schema and ownership condition | High that public evidence is insufficient |
Read the profile. The boundary splits by layer, friction and risk are the High scores, and coupling sits at Medium because component boundaries were visible. Two rows stay Unknown on public evidence, and that is the framework behaving correctly: those gaps are exactly what the assessment phase exists to close before a path is committed. The public evidence supports a targeted modernization rather than a commerce-core rebuild, though it does not independently determine the precise transition architecture. The validated delivery decision was an Adobe Commerce upgrade and incremental rearchitecture: the backend upgraded and kept, the frontend rebuilt in React and Next.js, content moved to Contentful, and search and recommendations extracted as components. A phased four-step roadmap carried the modernization forward while maintaining trading continuity.
Note what was deliberately not done. Nobody rewrote the commerce engine. That is the smallest sufficient intervention in practice: the intervention matched the constraint, and the results came from removing that constraint rather than from maximal engineering.
The longer-horizon version of the same discipline is EdPlace, a UK learning platform where a full replacement was judged financially impractical and operationally dangerous. The architecture was modernized incrementally across a 12-year partnership while the platform kept serving users, and the modernized platform supported the company’s acquisition by Supporting Education Group.
Want this scorecard run on your own portfolio? Our modernization assessment applies the same method to your highest-impact applications and names the smallest intervention that removes each constraint, before any budget is committed.
See how the assessment works →When the Honest Score Is Unknown
A composite from patterns we see in financial services, because incomplete evidence is the normal case, not the edge case. A lender faces a regulatory examination that surfaces unsupported runtime components and a single engineer who holds the system’s knowledge. At the same time an approved AI forecasting pilot cannot get governed, real-time access to the system’s data. Lifecycle risk scores High with high confidence, because the findings are documented. Data complexity and the difficulty of separating out a domain both score Unknown, because the schemas are undocumented and nobody can say what a domain extraction would drag with it.
The framework’s answer has two speeds. Act now on what is proven: contain and isolate the exposed components, then remediate, upgrade, or replace them. Start breaking the one-person knowledge dependency at the same time. Defer the target architecture until a discovery converts the Unknowns into scores. The pilot team will push for a faster answer. The discipline is refusing to let a confirmed risk stampede an unconfirmed architecture.
Running the Assessment
Scores come from system evidence, not workshop opinion. Pull deployment lead times from the CI system, integration timelines from project records, and cost trends from finance. Where telemetry does not exist, proxies work: count the manual steps in the deployment runbook, the emergency patches raised in a year, the contractor hours on maintenance, and the undocumented tables in the database. Poor proxies honestly gathered beat good metrics invented in a meeting.
The Hancocks figure shows the public shape of the instrument: decision or factor, result, evidence, and confidence. The working scorecard adds two columns, a named owner and a review date on every row. Start with the three applications whose failure or inability to change would hurt most, and expect the first pass to produce more Unknowns than answers. That is the assessment working. Which incremental techniques to use once a path is chosen, such as the Strangler Fig pattern that moves traffic from the old system to the new one piece by piece, deserves its own article.
FAQs
The 7Rs name the available dispositions in a cloud migration program, including retire, retain, and repurchase. This framework is complementary: it sets the ownership boundary before the engineering path, scores the constraint with evidence, and adds economic and delivery gates. It also holds up when cloud migration is not the objective at all.
Record it as Unknown and treat that as a finding. A discovery is time-boxed to resolve the material unknowns, often in a few weeks. Its output is scores with evidence: schema documentation, dependency maps, and an owner for each data domain. Committing to a target architecture on guessed scores is the failure mode this framework exists to prevent.
No. It raises the risk of one, and sometimes the data model is exactly what has to go. What high data complexity does demand is a separate data workstream covering ownership, cleansing, and migration. It usually favors a phased transition over a single cutover, shaping sequencing rather than vetoing an outcome.
Each application gets one named owner who assembles the evidence with the engineers who run the system and the business owner who depends on it. Refresh scores yearly, or immediately when a trigger event lands: a reorganization, a new partner, a compliance change, or a funded AI initiative that needs the application’s data.
