Executive Summary
THE LEADERSHIP DECISION | Choose one business capability, establish its current cost and risk, and prove a reversible improvement before funding wider architectural change.
Legacy applications often hold the business rules, records, and workflows that keep an organization running. Age is rarely the only problem. The greater burden is the cost of change: scarce specialist knowledge, poorly mapped dependencies, unsupported components, slow integrations, and releases whose failures can interrupt critical operations. A cloud migration may move these constraints without removing them, while indiscriminate decomposition can add network, monitoring, security, and operating costs.
Astrik’s position is clear: modernize the business capability first, then choose the architecture that fits its value, risk, team maturity, and operating model. The right decision may be to retire a system, retain it, rehost it, replatform it, or change its boundaries. “Beyond Monoliths” is not a mandate to replace every monolith with microservices; it is a case for deliberate, workload-specific choices.
This paper presents BRIDGE, an Astrik-proposed framework: Baseline business value and constraints; Rationalize the estate; Introduce stable interfaces; Deliver incrementally; Govern security, data, people, and operations; and Evolve on evidence. Public examples include the GAO’s review of high-risk federal legacy systems, the TSB migration incident, Prime Video’s targeted architectural simplification, and research on the gap between AI ambitions and data readiness.
A realistic first 90 days should focus on one low-risk, read-only capability. Establish cost, risk, service, and change baselines; map dependencies; record current behavior; introduce one controlled boundary; test, monitor, and rehearse rollback; then decide whether the evidence justifies expansion. The objective is a better investment decision, not a promise to modernize an entire estate in a quarter.
KEY TAKEAWAY
Modernize the business capability first. Choose the architecture by value and risk, prove the smallest useful change, and expand only when evidence supports it.
Introduction
Enterprise systems accumulate over time. Acquisitions, regulatory changes, product launches, emergency fixes, and integrations leave business rules in code and data structures that few people fully understand. Modernization becomes urgent when that complexity slows essential change, raises risk, or makes it difficult to connect a dependable new service to an existing system.
A July 2025 U.S. Government Accountability Office review examined 69 federal legacy systems and identified 11 most in need of modernization. Within that selected group, eight used outdated programming languages, four had unsupported hardware or software, and seven had known cybersecurity vulnerabilities. These findings apply to selected federal systems, but illustrate why age, skills, security, cost, and plan quality can converge into a material business issue.
Cloud, APIs, and AI are useful modernization drivers when tied to a specific outcome. NIST’s API guidance covers protection across design and runtime, while AWS’s seven migration strategies provide a vocabulary for deciding whether to retire, retain, rehost, relocate, repurchase, replatform, or refactor a workload. Neither source implies that one architecture or migration method fits every application.
Astrik’s software development and custom engineering services span application development and connected technology work. That cross-functional perspective informs the position in this paper: business outcomes, application boundaries, integration, data, security, operations, and long-term ownership should be considered together.
Illustrative scenario: modernizing without stopping the business
Consider a hypothetical distributor whose order-management monolith powers pricing, stock availability, invoicing, and fulfillment. The business wants a customer portal, partner integrations, and a forecasting assistant. A wholesale rewrite could delay value and concentrate cutover risk; a cloud move alone might preserve the same tightly coupled logic and inaccessible data. A safer starting point is a low-risk, read-only view of order status while the existing system remains the system of record.
| STEPS | MOVE | WHAT CHANGES |
|---|---|---|
| 01 | Map value and risk | Trace the order-status journey, dependencies, ownership, exception rules, and impact of failure. |
| 02 | Create one seam | Introduce a governed read-only API or façade; define contract, identity, access, monitoring, and an exit path. |
| 03 | Prove parity | Compare the new view with representative outputs from the existing system; investigate differences with business owners. |
| 04 | Expand on evidence | Measure reliability and effort. Consider write operations, broader data access, or AI only after the first slice is controlled and understood. |
Problem Analysis
3.1 The estate is harder to understand than the inventory
An application register does not reveal every dependency, batch job, shared database, downstream report, or exception rule. Critical knowledge may sit with a small number of long-serving specialists. If teams cannot describe how a business journey crosses systems, they cannot confidently estimate modernization scope or decide what must be preserved. GAO’s assessment highlights skills, supportability, security exposure, and planning as connected concerns.
3.2 Architecture can be overbuilt as well as outdated
A tightly coupled monolith may slow independent change, but a distributed design can add network calls, orchestration, operational overhead, and new failure modes. Prime Video’s engineering team reported that consolidating its audio/video monitoring service into a single process reduced infrastructure costs by more than 90% for that workload. This is a narrow, company-published case—not evidence that monoliths are universally preferable. Its lesson is to test whether each boundary earns its cost.
3.3 Cutover concentrates operational risk
A platform migration can be technically complete while the service around it fails under real operating conditions. TSB’s 2018 migration disrupted branch and digital banking despite extensive preparation; regulators later identified failures in planning, testing, risk management, governance, and supplier oversight. The case concerns migration and operational readiness, not proof that a particular application architecture is inherently wrong.
3.4 AI exposes unresolved data and ownership gaps
AI-enabled services depend on consistent identifiers, clear definitions, governed access, traceable data, and reliable interfaces. Where those foundations are missing, teams risk building another fragile point solution or exposing an untrusted source directly to a model. Section 04 examines published evidence on this readiness gap; Section 05 turns it into controls for data, ownership, and security.
ASTRIK’S DIAGNOSIS
Modernization should be measured by whether it removes a meaningful business constraint, improves the ability to change safely, or reduces risk. Infrastructure movement and architectural novelty are inputs, not proof of value.
Research & Insights
The evidence below is deliberately mixed: public-sector audit findings show portfolio risk, regulatory findings document the consequences of a difficult migration, company engineering accounts illustrate architecture trade-offs, and data-leader research helps test the AI-readiness claim. These sources answer different questions and should not be combined into a universal success rate.
| Research Signal | What the source reports | Implication for Leaders |
|---|---|---|
| DORA: quality and delivery can diverge | DORA’s 2024 analysis associated 25% higher AI adoption with +3.4% reported code quality, +3.1% review speed, −1.5% throughput and −7.2% stability. In 2025, AI adoption was positively associated with throughput and product performance, but negatively with stability. These are associations, not causation. | Measure escaped defects, change failures and recovery alongside code quality, review speed and delivery flow. |
| Veracode: generated code can still be insecure | Veracode’s July 2025 benchmark found known OWASP Top 10 vulnerabilities in 45% of generated samples across controlled, security-relevant tasks in four languages without security-specific guidance. The October update includes newer results. This is not a failure rate for all AI-generated code. | Validate security and behaviour independently; functional correctness alone is not sufficient evidence of quality. |
| GitClear: maintainability signals matter | Analysis of 211 million changed lines from 2020–2024 found copy-pasted lines rising from 8.4% in 2021 to 12.3% in 2024, while refactoring-associated moved lines fell from 25% to under 10%. The analysis does not isolate AI as the sole cause. | Track duplication, churn, refactoring, complexity and ownership not just whether the current build passes. |
| Developer survey: verification adds friction | Among respondents to Stack Overflow’s 2025 AI-frustration question, 66% cited “almost right” answers and 45% cited more time spent debugging AI-generated code. These self-reported perceptions use that question’s respondents, not all survey participants. | Budget review and debugging effort into the workflow; adoption does not remove the need to verify output. |
| METR: productivity estimates need context | METR’s early-2025 trial found 19% longer completion times among 16 experienced developers across 246 issues. A late-2025 follow-up, reported in February 2026, suggested faster work with newer tools; selection and time-measurement problems prevented a reliable estimate of the gain. | Treat productivity evidence as context, not a substitute for measuring quality and value in your own workflow. |
Reading the evidence responsibly
The cases establish different lessons. GAO identifies recurring risk in a selected public-sector portfolio; TSB and its regulators document a major service-disruption event; Prime Video describes one workload-level consolidation; Thoughtworks reports a proof of concept; CNCF measures reported platform use; and IBM reports CDO perceptions from a survey. None proves that monoliths are always wrong or right, or that cloud, APIs, or AI automatically produce value. The common implication is that modernization needs an explicit goal, a strategy matched to the workload, measurable controls, and a plan for operation and retirement.
What the evidence means for AI readiness
AI should be one possible outcome of modernization, not the automatic destination for every system. IBM’s survey points to confidence gaps in data capabilities. In practice, start with a defined use case, identify the authoritative data and decision owner, limit access, retain traceability, and evaluate whether the use case needs real-time integration, a curated data product, or no new AI component at all.
Recommendations: The BRIDGE Framework
Astrik proposes BRIDGE as a practical framework for planning and governing modernization. It is Astrik’s model for this paper, not an external standard or certification. The framework connects business priorities to a repeatable sequence of decisions and evidence, rather than prescribing one target architecture.
| PRINCIPLE | LEADERSHIP QUESTION | PRACTICE | EVIDENCE OF PROGRESS |
|---|---|---|---|
| B — Baseline business value | What outcome should improve, and what must not break? | Map the journey, current costs, dependencies, behavior, data owners, constraints, risks, and success measures. | Baseline; service map; known risks; named sponsor; measurable outcomes. |
| R — Rationalize the estate | Which workloads should retire, remain, move, or change? | Assess value, condition, change frequency, vendor support, skills, risk, and total transition cost; decide per workload. | Recorded disposition, rationale, target state, and exit criteria. |
| I — Introduce stable interfaces | Where can change be separated without exposing internal complexity? | Define contracts, ownership, versioning, identity, authorization, errors, data responsibility, and monitoring. | Versioned contracts; consumer inventory; contract tests; access controls. |
| D — Deliver incrementally | What is the smallest useful change that can be verified? | Start with a low-risk read-only slice; compare behavior; release gradually; retain rollback and stop criteria. | Parity evidence; test results; telemetry; rollback rehearsal; user feedback. |
| G — Govern the service | Can the modernized capability be secured, staffed, operated, and exited? | Govern data and AI, identity, resilience, cost, skills, team ownership, supplier dependency, and exit plans. | Named owners; runbooks; service objectives; data lineage; tested export/exit plan. |
| E — Evolve on evidence | What should expand, change, or stop next? | Review business outcomes and engineering signals together; expand, revise, retain, or stop on evidence. | Value realized; dependencies retired; risks reduced; next decision recorded. |
The table is the overview; the following subsections translate each letter into decisions and deliverables. The scope should remain proportionate to the value and risk of the capability being changed.
Suggested leadership dashboard
| B BASELINE | R RATIONALIZE | I INTRODUCE |
|---|---|---|
| Identify value, constraints and owners | Choose retain / retire / change per workload | Create governed, testable interfaces |
| D DELIVER | G GOVERN | E EVOLVE |
| Prove one reversible slice | Secure, operate and assign accountability | Measure, retire and decide what comes next |
BRIDGE is iterative: evidence from Evolve informs the next Baseline and investment decision. The sequence does not imply that every system needs every technical intervention.
5.1 B — Baseline business value and constraints
Start by naming the business outcome, the executive sponsor, the accountable product or service owner, and the operational team that will inherit the result. Map the end-to-end journey, dependencies, data flows, exception rules, service expectations, security concerns, and specialist knowledge. Capture the current behavior before changing it. Characterization or “golden-master” tests can record outputs for representative inputs and compare later versions with observed legacy behavior. These tests are a baseline, not proof that every existing result is correct; differences should be reviewed with business owners.
A business case that survives scrutiny
| COMPONENT | QUESTIONS TO ANSWER |
|---|---|
| Current cost to run | What do licenses, infrastructure, specialist support, incident recovery, workarounds, and manual processes cost today? |
| Cost of delay | What customer, revenue, compliance, or productivity outcome is blocked or made slower? Monetize only where assumptions are defensible. |
| Transition cost and dual-running | What will discovery, tests, data cleanup, training, parallel operation, migration, and retirement cost over the chosen planning horizon? |
| Risk-adjusted exposure | What risks arise from unsupported components, fragile recovery, concentration of specialist knowledge, or provider dependency? Use ranges and scenarios rather than false precision. |
| Exit and option value | For provider-specific services, estimate the time and cost to leave; record data export and transition assumptions. GOV.UK guidance recommends understanding switching cost and planning for exit. |
Compare the “do nothing” or retain option with retire, rehost, replatform, refactor, and repurchase scenarios. Make costs and benefits visible over the same time horizon, include uncertainty, and record the assumptions that would change the decision. Do not promise a universal ROI: the business case should be tested against local data and revisited after the pilot.
5.2 R — Rationalize the estate
Classify workloads by business value, risk, supportability, change frequency, differentiation, and fit with standard products. Retire capabilities that no longer serve a need; retain stable systems when change offers little value; rehost when infrastructure is the priority; replatform where operational benefits justify the cost; and refactor or re-architect where better boundaries or maintainability are essential. Repurchase may be appropriate for commodity capabilities. AWS’s 7 Rs are useful vocabulary, but apply them per workload and document why the chosen route fits.
Also decide what must be retired as each change ships. Without explicit decommissioning, organizations can end up paying for both old and new paths, preserving duplicate data, and maintaining the very dependencies the program was meant to remove.
5.3 I — Introduce stable interfaces
Choose a boundary around a coherent business capability, not merely around an existing database table. Define the contract, owner, versioning policy, authorization, error behavior, data semantics, rate limits, telemetry, and deprecation rules before onboarding consumers. NIST’s API-protection guidance covers lifecycle risks and both pre-runtime and runtime controls; apply those controls according to the sensitivity and criticality of the flow.
A façade or adapter is useful when it shields consumers from legacy complexity, but it becomes a product to secure and operate. Track who uses it, monitor failures and latency, and define when the temporary layer can be simplified or removed.
5.4 D — Deliver incrementally
Begin with a low-risk, read-only capability such as order status or a reference-data lookup. Keep the existing application as the system of record during the first pilot. Use representative test inputs and characterization results to check parity, route a limited set of requests, and compare correctness, latency, support effort, and cost. Do not use a first pilot to move high-risk writes, payments, or irreversible transactions unless the scope, controls, and recovery plan explicitly justify it.
The strangler approach described by Martin Fowler allows a legacy system and its replacement to coexist while functionality is moved in slices. Practitioner reporting from a mobile-app proof of concept illustrates that incremental patterns can improve local delivery, while also warning that the pattern can introduce accidental complexity. Keep the design reversible, monitor the boundary, rehearse rollback, and stop if the evidence does not improve.
5.5 G — Govern security, data, people, and exit
Treat operations as part of the architecture. Assign named owners for service behavior, data definitions, incident response, costs, and technical decisions. Embed authentication and authorization, secret management, data classification, logging, alerting, recovery tests, and service-level objectives into the delivery process. API and cloud controls should match the organization’s operational maturity, not assume that a managed platform removes accountability.
For AI-related use cases, identify authoritative data sources, definitions, lineage, quality rules, permissions, retention, and human escalation. Avoid giving a model or agent broad direct access to production stores by default. NIST AI 600-1, published in 2024, offers a lifecycle risk-management reference; IBM’s 2025 CDO survey reinforces that data capability and governance remain practical constraints for organizations seeking AI-enabled outcomes.
People and skills require a plan as well. Pair current subject-matter experts with engineers, record business rules and known exceptions, capture the reasoning behind high-risk decisions, and give the receiving team time to shadow operations before ownership transfers. Make training and specialist succession part of the budget; do not wait until cutover to discover that only one person understands the system.
Assess cloud and supplier dependency consciously. A provider-specific managed service can be worthwhile when its benefits exceed the switching cost; the aim is an informed choice, not portability for its own sake. Document ownership of data and intellectual property, export formats, contract notice periods, exit steps, likely time and cost to move, and how recovery would work if a service became unavailable. Test critical extraction or exit procedures periodically.
5.6 E — Evolve on evidence
Review business outcomes and engineering signals together: journey completion, cycle time, failed changes, recovery time, incidents, integration effort, cost to serve, data quality, unresolved dependencies, and team readiness. A rise in reported incidents or costs during parallel running may reflect better visibility or a temporary transition state; explain the cause and the planned exit criteria. Expand only when the evidence supports it, and retire old components when their replacement is stable and the business has confirmed that dependencies are gone.
BRIDGE is a decision loop, not a one-way maturity ladder. The right next step can be to extend a successful slice, revise the design, pause for foundational work, retain the existing system, or stop an initiative whose value no longer justifies its risk and cost.
ASTRIK’S DESIGN PRINCIPLE
Choose architecture by business value, workload behavior, and the organization’s ability to operate it. Every modernization slice should make a critical capability easier to change, safer to run, or less costly to sustain and should leave evidence of what improved.
Implementation Roadmap & Measures
A 90-day pilot should test whether a bounded modernization approach creates value while protecting business continuity. It is not a promise to modernize a complex estate in three months. Start with a low-risk, read-only capability; keep the current system as the system of record and defer transactional writes until the controls and business case justify them.
| PERIOD | FOCUS | DELIVERABLES |
|---|---|---|
| Days 0–30 | Baseline | Change lead time; deployment frequency; review wait time. | Name a sponsor, product owner, and operations owner; map one journey and its dependencies; capture current behavior with representative examples; baseline run cost, service health, change lead time, and risk; agree success and stop criteria. |
| Days 31–60 | Design and prove | Critical-journey test coverage; regression failures caught before release; flaky-test rate. | Define one API contract and access model; implement the façade or modular slice; compare results with the legacy system using characterization/contract tests; add telemetry, cost tracking, and a rehearsed rollback. Avoid high-risk writes in the first pilot. |
| Days 61–90 | Evaluate and decide | Escaped defects by severity; change-failure rate; customer-impact incidents. | Use internal users or limited read traffic; verify parity, latency, reliability, support effort, and cost; test rollback; document residual risks, skills needs, exit assumptions, and the next investment decision. Expand, revise, pause, retain, or stop based on evidence. |
Illustrative pilot acceptance scorecard
Define thresholds with business and operations owners during Days 0–30. The following criteria are examples, not universal benchmarks or reported Astrik client results.
| DIMENSION | EXAMPLE ACCEPTANCE EVIDENCE | DECISION OWNER |
|---|---|---|
| Business correctness | All agreed critical scenarios match approved expected behavior; differences are resolved or accepted. | Business capability owner |
| Security & access | No unresolved critical findings; authorization and least-privilege checks passed. | Security owner |
| Service performance | p95 latency, availability and error rate meet pilot-specific agreed limits. | Service / operations owner |
| Rollback & continuity | Reversal is rehearsed and completed inside the approved recovery window. | Operations owner |
| Operating readiness | Runbook, alerts, escalation, cost baseline and long-term owner are confirmed. | Product and operations owners |
Leadership dashboard: measure outcomes, not activity
| MEASURE | WHY IT MATTERS | INTERPRETATION |
|---|---|---|
| Business outcome | Tests whether the modernization solves the reason it was funded. | Choose a capability-level measure such as order cycle time, successful self-service, reconciliation delay, or customer wait time. |
| Change lead time and release reliability | Shows whether teams can change the system with confidence. | Track time from approved work to production alongside failed changes, incidents, rework, and recovery time. |
| Reliability and customer journey | Shows whether service health translates into business service. | Measure availability and latency alongside completion of the end-to-end journey, not infrastructure alone. |
| Integration flexibility | Shows whether new consumers can integrate without repeated custom work. | Track priority flows using documented, versioned interfaces and the effort needed to onboard a new consumer. |
| Cost to serve | Makes operating-cost changes visible. | Consider cost per transaction or business outcome, including platform, migration, support, and dual-running costs. |
| Knowledge and team readiness | Tests whether the new service can be owned after specialists move on. | Track documented rules, named owners, paired knowledge transfer, runbooks, and training for the receiving team. |
| Exit and dependency risk | Shows whether provider or legacy dependencies are understood. | Record export tests, estimated exit time/cost, vendor-specific services, contract dates, and decommissioned dependencies. |
| Risk and dependency retirement | Shows whether the legacy footprint is actually shrinking. | Count removed interfaces, duplicated data stores, unsupported components, and unresolved high-risk dependencies. |
| Data and AI readiness | Shows whether future capabilities can use data responsibly. | Track ownership, quality, lineage, access policy, and monitoring for the specific data products and use cases in scope. |
Baseline values before work begins. Set target thresholds from business needs and current performance rather than importing generic benchmarks. Cost can temporarily rise when the old and new paths operate in parallel; that may be justified if it is a time-bound step with explicit exit criteria. The dashboard should support a decision continue, adjust, expand, or stop not merely report activity.
Conclusion
Legacy modernization is a portfolio of business and engineering decisions. The evidence does not support a universal architecture rule. TSB’s migration experience demonstrates the consequences that can follow when platform change outpaces effective operational control; Prime Video’s service-level redesign shows that consolidation can be the right answer for a workload whose distributed components no longer justify their cost. The lesson is to diagnose the actual constraint and choose a proportionate response.
A successful program makes change safer and more valuable over time. It records current behavior, protects critical journeys, builds interfaces with clear ownership, addresses data and security, develops the team that will run the result, and retires old paths when it is safe to do so. Cloud and APIs can improve flexibility; AI can create new options when data and governance are ready. None of these outcomes should be assumed without evidence.
References
1. U.S. Government Accountability Office (GAO), Information Technology: Federal Agencies Need to Address Aging Legacy Systems (July 2025).
2. National Institute of Standards and Technology (NIST), SP 800-228 Guidelines for API Protection & NIST AI 600-1 Generative AI Profile.
3. AWS Prescriptive Guidance, 7 Rs Migration Strategies for Application Modernization.
4. UK FCA / PRA Investigation into the 2018 TSB IT Migration Programme.
5. Prime Video Engineering, Scaling Up the Prime Video Audio/Video Monitoring Service and Reducing Costs by 90%.
6. IBM Institute for Business Value, Chief Data Officer (CDO) Study (2025).