Application modernization starts with choosing the right scope

Application modernization programs can go wrong before engineers change any code if leaders classify the work incorrectly. A move to the cloud can be budgeted as modernization, while a full rewrite can be approved under the safer-sounding label “refactor.” Those choices carry very different scope, risk, and disruption, so the first modernization task is to decide what kind of problem each application actually presents.

Modernization starts with naming the problem correctly

Application modernization changes an existing application’s architecture, platform, or code while preserving core business logic the organization already trusts. The change can be narrow, such as swapping a database engine, containerizing a service, or patching an end-of-life (EOL) runtime, meaning software whose normal support lifecycle has ended. It can also transform most of an application while stopping short of replacing its codebase. The intended outcome determines where the work sits on that spectrum.

That distinction separates modernization from cloud migration, which primarily changes hosting and infrastructure. Moving an unchanged monolith, an application deployed as one tightly connected unit, to Microsoft Azure or Red Hat OpenShift qualifies as migration because its architecture and code remain fundamentally unchanged. Modernization changes architecture, platform, or code to remove accumulated technical debt while retaining business behavior worth preserving. Migration can be part of that work, while a hosting move alone leaves the underlying application substantially unchanged.

The same classification puts maintenance and digital transformation on opposite sides of modernization. Maintenance covers patches, bug fixes, and minor version upgrades needed to keep a system operating. Digital transformation can reach further into a company’s business model, customer experience, processes, or organizational structure, with modernization as one technical workstream where application change is required. Many transformation programs can proceed through strategy and organizational change without requiring an application rewrite.

A rewrite changes the planning assumptions more sharply because it replaces the codebase from scratch and carries a high-risk, all-or-nothing scope compared with incremental modernization. A damaging planning error occurs when leadership authorizes “modernization” while engineering is effectively rebuilding the application, because the budget, timeline, and risk approval still assume existing code remains useful. Calling the work a “refactor” does not change its actual scope. Scope has to follow the engineering work being proposed.

That scope matters financially because technical debt can make each future change harder even while maintenance keeps the current system running. Patches and minor improvements may be sensible for years, but accumulated constraints can eventually leave a rewrite as the viable route. Leaders therefore need to decide what should be preserved before estimating how quickly engineers can change it. A technology-upgrade problem begins as a classification problem.

Legacy is operational drift

Once the type of work is clear, classification also changes what “legacy” means. An application becomes legacy when its runtime, framework, or architecture has drifted beyond vendor support cycles, the organization’s delivery requirements, or both. A production system can keep serving traffic reliably after its runtime reaches EOL, so current performance alone says little about how safely the organization can keep changing or supporting it.

Vendor lifecycle dates make support drift explicit. Windows Server 2012 and 2012 R2 left Microsoft extended support in October 2023. Microsoft, Red Hat’s RHEL, IBM middleware, and other vendor platforms operate on fixed lifecycle clocks; once the relevant support period has elapsed, patches are described here as unofficial. Unsupported software consequently becomes a security and compliance issue even when users see no immediate degradation.

Delivery performance exposes another form of drift because a stable application can still become prohibitively expensive to change. A team that once released weekly can reach a point where a change that should take days consumes a quarter because every release has to pass through a monolith engineers no longer trust. Workarounds, manual regression testing, technical-debt service, and repeated firefighting then become operating costs. Netguru, which sells enterprise software development, software maintenance, replatforming, and modernization engagements and therefore has a commercial interest in organizations funding this work, says its software-maintenance engagements often reveal this cost-of-change problem before clients classify it as modernization.

Integration can create the same pressure even when the existing application remains stable. A system may be unable to expose the application programming interface (API) required by a new CRM, data platform, partner, or cloud service without substantial changes to its internals or data layer. Yet integration around the existing system can still be the economical response. When a system of record is the actual constraint, ERP integration can cost less than changing everything around it.

External requirements make some forms of drift harder to defer. Unpatched dependencies, data-residency gaps, or an audit finding tied to a library or runtime that cannot safely be upgraded indicate that the current design can no longer satisfy a security or compliance requirement cleanly. Talent scarcity creates a related operational limit as engineers who know the stack become harder and more expensive to hire. Together, those conditions can turn routine maintenance into an increasingly fragile way to postpone larger change.

Economics completes the assessment because the organization eventually has to compare continued support with the cost of restoring changeability. Netguru’s practice experience gives an example in which support tickets and workarounds can cost more each quarter than a phased modernization sprint. Because Netguru sells the work involved, the comparison is an engagement-derived practice claim. The useful calculation remains organization-specific: compare actual spending required to preserve current operation with the proposed cost of restoring the ability to change the system.

Those operating conditions produce a practical set of signals: an EOL runtime, an unshippable release cadence, an integration ceiling, compliance or security exposure, talent scarcity, and maintenance costs that exceed change costs. Several can occur together, and none depends on an arbitrary age threshold. As an illustration rather than study evidence, a ten-year-old application with reliable characterization tests, which record and verify existing behavior, can be safer to change than a two-year-old codebase engineers are afraid to touch. Confidence about behavior can matter more than age.

Choose the treatment before choosing the technology

Once those signals show that an application needs attention, the 7 Rs provide an application-level classification: retain, rehost, replatform, refactor, rearchitect, rebuild, or retire. Each route changes a different amount of the system, giving it a different level of effort, risk, and ability to remove legacy constraints. Choosing an R before selecting a target technology prevents a preferred cloud or architecture from deciding scope by accident.

At the low-change end, retaining is valid when an application continues to do its job and patching or isolation can reasonably handle its risks. Rehosting changes the infrastructure, perhaps by moving the application to an Azure VM or an AWS environment, while preserving the application itself. EOL exposure or a hosting contract can make that fast move the appropriate response. The team can then address the immediate risk without committing to the much larger scope of architectural change.

Replatforming changes more of the foundation while requiring relatively limited code changes. Moving a workload to Azure App Service or a managed database illustrates the category because the organization adopts a different operating platform while keeping the application architecture substantially intact. Rehosting cost is driven mainly by migration work and the period when old and new environments must run simultaneously. Its business case should reflect that bounded objective.

Refactoring reaches into internal code structure when that structure is slowing delivery and external behavior remains worth preserving. Characterization-test coverage should exist before the work begins because engineers need evidence that restructuring internals has preserved relied-upon behavior. Terminology matters directly to the estimate here. If engineers are replacing the codebase, existing code has ceased to be load-bearing, so calling the effort a “refactor” destroys the assumptions on which the estimate was built.

Rearchitecting goes further by changing the architectural pattern itself. A monolith might be decomposed into services when integration requirements or scaling limits prevent the product roadmap from advancing. That larger scope raises effort and risk because boundaries, data movement, deployment, and dependencies can all change. Teams nevertheless sometimes choose this route when a straightforward rehost could clear an urgent EOL problem within weeks, thereby accepting architectural risk beyond what the immediate business problem requires.

Rebuilding accepts full rewrite scope while preserving the application’s business domain and functional scope. It fits when the existing code has become unmaintainable but the organization understands the domain logic well enough to recreate it deliberately. Retiring applies the same economic test at the application level: if continuing value no longer supports continuing cost, the organization can decommission the application in favor of SaaS or simply eliminate it. These options make preservation itself a decision rather than an assumption.

With the treatment identified, prioritization can follow the underlying pressure. EOL runtimes deserve early attention, while business criticality provides a stronger portfolio ranking signal than code age. For a modernization candidate, teams can then determine whether architecture, platform, code, or some combination genuinely needs to change. Technology selection now has a defined problem to solve.

Cost follows the treatment because each R buys a different amount of change. Rehosting largely buys movement and temporary dual operation, while rearchitecting or replacing modules costs more upfront because it changes more of the system and aims to reset accumulated technical debt. Modernization funding competes with money already committed to running and improving existing applications. A business case should compare the proposed treatment with the continuing cost of the current treatment.

At enterprise scale, dependencies determine what moves together

Application-level classification becomes insufficient when modernization spans an enterprise portfolio. The unit of work can expand to dozens or hundreds of interconnected services with different owners, release schedules, data contracts, and technology lifecycles. An application that appears independently modernizable may share a database or an undocumented job with another system. Those dependencies determine which systems can safely move together.

Portfolio assessment makes those constraints visible before implementation begins. Each application can be scored by business criticality, technical debt, and proximity to an EOL runtime, giving leaders a basis for combining business impact with technical urgency. Netguru says its enterprise modernization experience typically allocates four to eight weeks to assessment and dependency mapping for a mid-size estate. Because that figure comes from the engagements Netguru sells and delivers, it is an engagement-derived planning estimate rather than a universal benchmark.

The assessment leads directly to dependency mapping because seemingly independent applications often turn out to form one modernization scope. Teams identify shared databases, undocumented batch jobs, and point-to-point integrations that couple release or data behavior across systems. Undocumented integration debt lengthens the assessment because engineers first have to discover relationships that operational processes have taken for granted. Existing service-level ownership maps can shorten the work because responsibilities and system boundaries are already explicit.

Once those relationships are known, migration becomes a sequencing problem before it becomes a product choice. If two services share a data domain or a hidden batch process, splitting their migration according to departmental ownership can create more cutover risk than moving them in the same wave. Enterprise phasing therefore commonly follows shared data domains instead of organizational reporting lines. Architecture diagrams and organization charts can describe useful boundaries, but the practical modernization unit is established by the relationships that have to survive the move.

That sequencing gives target-state technologies a specific role. A target state might decompose parts of a monolith into microservices, smaller independently deployable services; package services in containers; move workloads to managed infrastructure; and introduce continuous integration and continuous delivery (CI/CD), automated tests, and observability, meaning the ability to understand system behavior from operational signals. Azure Kubernetes Service, Red Hat OpenShift, IBM Cloud, Azure, and AWS are possible destinations within such choices. The dependency map establishes which workload should move first.

Each resulting wave then needs behavioral evidence before cutover. Characterization tests capture the business behavior that existing users and dependent systems rely on, allowing engineers to verify that modernization preserved it. Netguru links skipping that step with production failure at cutover: without those tests, continuity depends on assumptions about old code whose behavior may have accumulated over years. Dependency-aware sequencing controls what moves together, while characterization controls what must continue working after the move.

Those dependencies also explain why scope drives duration. Netguru’s engagement experience puts discovery, refactor, and cutover for one scoped service replatform at 8–14 weeks when characterization tests already exist. Netguru describes a phased program across a real portfolio as taking 12–24 months because dependency discovery keeps identifying services that must share a wave. Both figures are planning experience from commercial engagements rather than general benchmarks.

The working sequence follows the uncertainties revealed at each stage: assess the portfolio, map dependencies, select workloads and target platforms in an order those dependencies permit, build waves around shared data domains, execute characterization tests, and then cut over. Each stage supplies information needed by the next. Starting from a preferred platform or an organizational rollout plan commits implementation choices before teams know which systems can actually change independently.

The same dependency view explains why duration can increase sharply even when individual code changes do not become much harder. A relatively simple service can join a larger critical path because another application shares its data, release mechanism, or integration contract. Marketplace rebuild lessons, modernization pitfalls, legacy-system taxonomy, modernization frameworks and guides, project sequencing, cloud development, legacy-system costs, code-quality metrics, and pressure to deploy AI can all inform internal planning, but portfolio sequencing still has to model the concrete relationships between systems.

AI speeds comprehension while engineers decide what survives

Once dependency discovery exposes what engineers need to understand, AI can shorten one expensive part of the work. In 2026, models can inspect Java and .NET monoliths and draft documentation, reducing work that Netguru describes as taking senior engineers weeks of manual call-graph tracing to hours. Netguru benefits commercially from modernization engagements in which faster discovery can accelerate delivery, and the comparison is a practice claim rather than a measured benchmark. The practical value is earlier access to the architecture and preservation decisions that require engineering judgment.

Commercial tooling can also support migration analysis. Microsoft, which sells Azure OpenAI Service and the Azure platform and owns GitHub, offers Azure OpenAI Service and GitHub Copilot; IBM, which sells IBM watsonx Code Assistant and IBM Cloud, offers watsonx Code Assistant. These tools can propose routes away from EOL runtimes and identify dependency breaks for human review. Red Hat, which sells OpenShift and related platform services, provides migration tooling that performs related dependency analysis for Java estates moving toward containerized platforms, including deployments on Azure or another cloud.

Those tools can accelerate discovery and drafting, while the choice among retain, replatform, refactor, rearchitect, or rebuild remains an architectural and business judgment. Characterization-test generation is closely tied to that judgment because it records behavior a modernization may need to preserve. Netguru describes test generation as the most useful AI application in modernization practice and says models can produce draft tests in “a fraction of the time” required for manual test writing, without attaching a quantified comparison. A model can observe legacy inputs and outputs, including undocumented edge cases, and draft tests that record what the running application currently does.

Captured behavior then has to be classified because legacy systems contain both business rules and bugs. An engineer compares each important behavior with what the application is intended to do and decides whether preservation is correct. A generated test can faithfully preserve a defect and make that defect appear mandatory during refactoring. AI makes behavioral capture faster; senior engineering judgment determines which captured behavior deserves to survive.

Hallucination creates another review problem because a model can invent a business rule that the original implementation never enforced. A generated test can then certify that invented behavior, while poor abstractions can spread into downstream services as modernization proceeds. Responsibility consequently remains with senior engineers who understand the system’s business and technical boundaries. Faster generation increases the amount of material that can be reviewed; accountability remains with the engineers.

Evidence cited for AI-generated code reinforces that review boundary, although the citation attribution itself is inconsistent. One reference appears under the incomplete title “A Large-Scale Empirical Study of AI-Generated Code in”; another is described as a 2026 study, “Debt Behind the AI Boom, 2026,” covering 302,600 verified AI-authored commits across 6,299 GitHub repositories. The latter reports that 22.7% of AI-introduced code issues remained at HEAD, meaning the current state of the codebase, months after their introduction. The two attributions cannot be treated as corroboration, so the 22.7% figure remains one reported result with uncertain citation provenance.

That persistence risk matters particularly in modernization because intended legacy behavior can already be poorly documented. A defect in a migrated business rule may remain hidden until a customer, auditor, or regulator encounters it. Netguru’s working sequence in replatforming and modernization engagements is consequently strict: AI drafts documentation, tests, or migration suggestions; a senior engineer reviews and signs off; the generated suite runs against samples of real production traffic; then the team cuts over. The same sequence preserves senior review while allowing AI to reduce manual tracing and first-pass test writing.

Removing that gate can recreate the technical debt the modernization program is intended to address. Budget owners can account for the risk by preserving senior review hours in AI-assisted modernization and treating faster discovery and drafting as earlier delivery capacity. Some applications can still remain in place through patches and isolation, workarounds, manual regression, firefighting, lift-and-shift migration, or continued operation of legacy systems, while others may warrant rehosting, replatforming, refactoring, rearchitecture, rebuilding, or retirement. For applications that proceed to AI-assisted change, implementation speed becomes useful after engineers establish scope, dependencies, and the behavior worth preserving.

Key highlights

• Classify the modernization problem first: Scope the work as retain, rehost, replatform, refactor, rearchitect, rebuild, or retire before selecting technology. Misclassifying a rewrite as a refactor creates unrealistic budgets, timelines, and risk assumptions.
• Treat legacy as operational drift: Use EOL exposure, release delays, integration constraints, compliance risk, talent scarcity, and maintenance costs to identify modernization candidates. Business criticality and cost of change provide stronger prioritization signals than application age.
• Match the treatment to the constraint: Architecture owners can select the lowest-risk modernization path that resolves the actual business or technical limitation. Characterization tests provide evidence that relied-upon behavior survives changes to code, platforms, or architecture.
• Map dependencies before sequencing the portfolio: Portfolio owners can identify shared databases, batch jobs, data domains, and integrations before defining migration waves. These dependencies reveal which applications have to move together and can materially change program duration.
• Keep engineering judgment in AI-assisted modernization: AI can accelerate code analysis, documentation, migration suggestions, and characterization-test generation. Senior engineers remain responsible for deciding which legacy behaviors to preserve, reviewing generated output, and approving cutover.