TL;DR
- Group applications into waves by the data they share. In enterprise application modernization, applications that write to the same tables move together, or one moves behind a stable interface first.
- Re-price the portfolio with AI-assisted transformation costs. Applications parked on rehost or tolerate because refactoring cost too much become refactor candidates once assessment, code changes, and tests are AI-assisted.
- Decide where database logic lands before each wave starts. Every stored procedure, trigger, and view shared by a wave gets one destination.
- Close each wave on one parity standard. API responses, data state, and batch outputs match the legacy baseline before the next wave starts.
- Plan timelines from drivers. Shared data, starting test coverage, transformation method, and business calendars set the number and length of waves.
Enterprise application modernization changes the code, data, and architecture of many applications in one program, with the business running on all of them. At that scale, the order of the work is a cost driver in its own right.
A 2025 Pega survey of more than 500 IT decision makers put the average global enterprise’s annual waste from technical debt at more than $370 million [1]. Time was the largest share, about $134 million a year tied to how long legacy transformation projects take to complete.
This guide covers enterprise modernization at portfolio level. It sets out how to assess the estate, choose a path per application, and sequence waves around shared data. It also shows where Gen AI changes the cost of each step.
What Enterprise Application Modernization Covers at Portfolio Scale
Enterprise application modernization is portfolio-level change to an enterprise’s applications, covering code, data, and architecture, sequenced so the business keeps running. It includes assessing every application, choosing a path for each one, grouping the work into waves around shared data, and proving each wave behaves like the systems it replaces.
An application qualifies as legacy through friction, and four triggers put it in scope.
- Change cost. Small changes take weeks because tests and documentation are missing.
- Support status. The vendor has ended support for the framework or its tooling, as with AngularJS in 2021 and the VB6 IDE in 2008.
- Risk. Unpatched dependencies, open audit findings, or knowledge held by one or two people.
- Business drag. The application blocks a product launch, a partner integration, or an AI initiative.
Moving an application to new infrastructure leaves its code and data as they were. Rehost and replatform are staging positions, and the debt moves with the application. Programs that stay on-premises or hybrid still modernize, because the work happens in the code and the database.
Target architecture follows each domain’s rate of change. A domain that changes weekly can justify separate services, and a stable domain often runs well as a modular application. The tradeoffs between a monolith and microservices apply domain by domain.
How to Assess an Enterprise Application Portfolio With Gen AI
Portfolio assessment produces two views of every application, one for business fit and one for technical health. Gartner’s TIME model supplies the business view, sorting applications into Tolerate, Invest, Migrate, and Eliminate.
The technical view comes from signals measured in the code, the database, and the runtime.
| Signal | What to Measure |
| Support status | Runtime, framework, and database versions against vendor support dates |
| Change cost | Lead time for a small change, and how often releases need a hotfix |
| Test coverage | Coverage report and count of untested entry points |
| Dependency depth | Calls into and out of the application, including shared libraries and queues |
| Data coupling | Tables the application reads and writes that other applications also use |
| Database-resident logic | Stored procedures, triggers, and views the application calls |
Manual assessment reads a sample. Architects review the largest or most critical applications in depth and estimate the rest, so shared tables and cross-repository calls outside the sample stay invisible.
Gen AI-assisted code and dependency analysis reads every repository and database schema in the estate. The dependency and data coupling rows then cover the whole portfolio, which is the input wave planning needs.
Each application still gets a deeper review before its wave starts, using the same checks as a legacy system audit.
The 6 Rs of Enterprise Application Modernization and Their Effect on Technical Debt
Each application gets one of six paths. At portfolio level, the column that matters most is what each path does to the code and data debt the application carries.
| Path | What Changes | Effect on Code and Data Debt | Fits When |
| Rehost | Infrastructure only | Relocated. Code, schema, and database logic stay the same | A data center exit sets the deadline |
| Replatform | Runtime or managed services, with minimal code change | Relocated, with small reductions where a managed service replaces custom code | A supported upgrade path exists and the code is sound |
| Refactor | Internal structure, with the same behavior | Reduced in the code, with the schema largely unchanged | The domain model holds and tests can be built |
| Rearchitect | Boundaries and data ownership | Reduced in code and data, with schemas split by domain | A domain needs independent scaling or team ownership |
| Replace | A commercial or SaaS product | Removed, with data moved into the vendor’s schema | The capability is a commodity |
| Retire | The application is removed | Removed, with data archived or merged | Functionality is duplicated or unused |
Retain sits outside the six. It fits stable applications on supported runtimes with a low change rate, and those applications get reviewed at every portfolio refresh.
Rehosting and replatforming earn their place before a fixed deadline. Their debt stays on the books until a later wave refactors or replaces the application.
The database work each path brings is planned application by application in legacy code modernization. For programs headed to the cloud, cloud modernization services price these paths in cost tiers.
How Gen AI Changes Which Applications Are Worth Modernizing
Path assignments in a portfolio are partly cost decisions. An application lands on rehost or tolerate when its business value doesn’t cover the cost of refactoring it, and Gen AI changes that cost.
Where Gen AI Lowers the Cost per Application
Three parts of the application modernization cost for each application fall with AI-assisted transformation.
- Assessment and comprehension. Dependency maps and business rules are reconstructed from the code, which shortens the weeks spent reading an undocumented system.
- Code transformation. Framework, language, and data access changes are drafted by the model and reviewed by engineers as diffs.
- Test generation. Characterization and regression tests are drafted from legacy code paths, which removes the slowest prerequisite for refactoring.
Published evidence points the same way. In a study of 39 code migrations at Google, LLMs generated 74.45% of the code changes [2]. Developers estimated a 50% reduction in total migration time compared with earlier manual migrations.
Those migrations ran inside one company’s codebase. Across a portfolio the effect compounds, because every application near the refactor boundary gets re-priced at once.
Portfolio Paths at Manual Cost and at AI-Assisted Cost
Six common application profiles show the shift. Three change path when transformation cost drops, and three hold.
| Application Profile | Path at Manual Cost | Path at AI-Assisted Cost | Reason |
| Mid-value .NET Framework application with low test coverage | Rehost | Refactor to modern .NET | Generated tests remove the cost that kept it on rehost |
| Undocumented Java EE application with rules in stored procedures | Tolerate | Refactor, with database logic decided before its wave | Reconstructed business rules make the logic decisions affordable |
| VB6 or Delphi desktop application with a high change rate | Replace with a partial-fit product | Rebuild on .NET or React with parity validation | The rebuild estimate gets re-run against the cost of adapting the product |
| Commodity capability, such as expense management | Replace | Replace | Custom code adds no advantage |
| Duplicated or unused application | Retire | Retire | Lower cost creates no reason to keep it |
| Stable application on a supported runtime | Retain | Retain | Low change rate leaves little friction to remove |
Rehost stays the right call when a deadline arrives before a refactor can finish.
Modernization Costs Gen AI Leaves Unchanged
Some program costs sit outside the code, and AI-assisted transformation leaves them where they were.
- Stakeholder alignment. Business owners still agree on target behavior and approve changes to it.
- Freeze windows and peak seasons. Cutover dates follow the business calendar.
- Data cutovers. Moving a domain’s system of record still needs a planned window and a rollback path.
- Regulatory dates. Audit and filing deadlines set fixed points the plan works around.
- Review and acceptance. Engineers review every AI-generated change, and business users run acceptance testing.
These costs set the floor under a program’s timeline, so the wave plan carries more weight as code transformation gets faster.
A global entertainment equipment manufacturer had modernized 95% of its legacy estate. The remaining 5%, VB6 and Windows Forms components with 1,700 DLLs and hundreds of executables, had stalled as the most tightly coupled and fragile part of the architecture. Legacyleap mapped dependencies with Gen AI and moved components in phases, each validated before the next. Code conversion ran 60% faster, and live operations continued throughout.
Measure One Application Before Pricing the Portfolio
+moreHow to Sequence Modernization Waves Around Shared Data
Wave planning groups applications so each wave can move, cut over, and pass validation without breaking the waves around it. Shared data decides the groups. AWS builds the same principle into its wave planning guidance, creating waves per business domain because data is typically shared within a domain [3].
Six steps decide which applications to modernize first and how they group into waves.
- Assess the estate. Score every application on business fit and technical health.
- Map data ownership. Record which applications read and write each table, and which one owns the system of record for each data domain.
- Group by shared data. Applications that write to the same tables join one wave, or one of them moves behind a stable interface first.
- Decide database logic. Assign each stored procedure, trigger, and view a destination before the wave starts.
- Score and order the waves. Rank waves by business value, dependency count, and complexity, with lower-risk waves first.
- Set exit criteria. Define the parity checks each wave passes before the next wave starts.
Mapping Shared Databases and Systems of Record
The data map lists every table with its readers, its writers, and the application that owns its records. Query logs, connection strings, and code search produce it, and AI-assisted analysis extends it to embedded SQL and stored procedure calls across every repository.
Ownership sets the order inside a wave group. Applications that only read a domain’s data can move early behind a read interface.
The application that owns the system of record moves last, once every consumer reads through an interface it controls.
Batch jobs, reports, and partner extracts belong on the map too. They read the same tables and break the same way when a schema changes.
Deciding Where Database Logic Lands Before a Wave Starts
Stored procedures, triggers, and views often hold pricing rules, eligibility checks, and status transitions that several applications depend on. Each object gets one destination before its wave starts, since every application in the group calls it.
- Keep in the database. Set-based logic that runs close to the data, such as period-close calculations.
- Move into service code. Rules that change often or need unit tests, owned afterward by one service.
- Rewrite for a new engine. Logic that stays in the database through an engine change.
Engine changes add conversion work of their own, as in an Oracle to PostgreSQL migration, a SQL Server to PostgreSQL migration, or a Db2 to PostgreSQL migration.
Running Legacy and Modernized Data Stores in Parallel
During a wave, legacy and modernized applications read and write the same data. Each table needs one source of truth for the duration, and three patterns provide it.
- Shared database. Both applications use the legacy schema until the wave’s last consumer moves.
- Dual writes. The modernized application writes to both stores, and reads verify that the copies match.
- Synchronization windows. Changes replicate on a schedule, with one application named as owner of each table to resolve conflicts.
The wave plan names the date the legacy store stops being the source of truth. Traffic routing between old and new code follows the strangler fig approach, and these data patterns keep that routing consistent at the database.
Applications that can’t take an outage at cutover use the patterns of a zero-downtime migration.
How a Shared Database Turns Microservices Into a Distributed Monolith
A distributed monolith forms when an application splits into services and its database stays shared. The services deploy separately, and every schema change still needs every team.
Microsoft’s architecture guidance draws the line at the schema. Services can share a physical database server, and problems start when they share a schema or read and write the same tables [4].
Waves that split services move the schema with them. Tables get split by domain, or each shared table sits behind the interface of the one service that owns it.
How to Validate Behavior Parity Across a Modernization Wave
A wave closes when every application in it behaves like the system it replaced. One acceptance standard applies to every application in the wave, set by the program and enforced the same way for every team.
The standard compares legacy and modernized behavior at three levels.
- API responses. Status codes and payloads for recorded production requests.
- Data state. Rows written by each transaction, including trigger side effects.
- Batch and report outputs. Job output tables, generated files, and report totals for the same period.
Data-level checks use the same techniques as data migration validation, applied to every application in the wave.
| Wave Exit Criterion | Evidence Leadership Sees |
| Behavior parity | Share of recorded requests and batch runs matching the legacy baseline, with every mismatch triaged |
| Data reconciliation | Row counts and key totals reconciled for every migrated table |
| Consumers moved | Every downstream report, feed, and integration confirmed on the new source |
| Rollback path | A tested rollback until the legacy store is retired |
| Decommission scheduled | Legacy components for the wave booked for retirement |
Size Your First Modernization Wave
The $0 Modernization Assessment produces a risk and complexity heatmap and a modernization plan for one representative application in 3 to 5 days. Programs use it to size a first wave.
How Long Enterprise Application Modernization Takes
Program length comes from the number of waves and the length of each one. AWS recommends keeping migration waves within 6 to 10 weeks and handling complete rewrites of application components outside them [3].
Four drivers set both numbers.
| Driver | Effect on Timeline | How to Measure It |
| Applications sharing data | More applications on shared tables means larger waves and fewer waves in parallel | Applications per shared table group |
| Starting test coverage and documentation | Low coverage adds baseline work before transformation | Coverage reports and share of applications with current documentation |
| Transformation method | Manual, tool-assisted, or AI-assisted transformation sets the effort per application | Delivery rate measured on a pilot application |
| Business constraints | Freeze windows, regulatory dates, and peak seasons fix cutover dates | Calendar of blocked windows |
AI-assisted transformation shortens assessment, code changes, and test creation inside each wave. Data cutovers and business calendars stay fixed, so the larger gain comes from running more waves in parallel where the data map allows it.
A program-level application modernization roadmap turns these drivers into dated waves, with the pilot application’s measured rate as the planning unit.
Enterprise Modernization Governance With Wave Owners, a Decision Log, and Leadership Metrics
Enterprise modernization governance stays light when ownership and decisions are explicit.
- Portfolio owner. Owns the data map, the wave order, and path assignments across the estate.
- Wave owners. Each owns one wave’s scope, exit criteria, and cutover, with authority to hold the wave if parity fails.
- Decision log. Path changes, database logic decisions, and approved behavior changes are recorded asynchronously with an owner and a date, which takes routine decisions off a weekly review board.
Leadership tracks four numbers.
- Applications retired.
- Waves closed against their exit criteria.
- Legacy run cost removed.
- Share of the portfolio on supported runtimes.
How Legacyleap’s Gen AI Agents Run Enterprise Application Modernization Across the Portfolio
Legacyleap is a Gen AI-powered legacy application modernization platform built on multi-agent orchestration. Its five agents run the Assess, Comprehend, Modernize, Validate, and Deploy lifecycle on one persistent model of each codebase, which carries context from portfolio assessment through every wave.
- Assessment Agent. Produces dependency maps, technical debt reports, risk indicators, and effort and timeline estimates. Assessment and documentation of an application take 2 to 5 days.
- Documentation Agent. Reconstructs architecture, module boundaries, data flows, and integration maps, with business logic documented from the code itself.
- Recommendation Agent. Recommends refactor, replace, or retain per module, with ordered migration phases and a target architecture.
- Modernization Agent. Delivers converted code as diff-based pull requests for human review. Roughly 70% of the modernization work is automated, and engineers review and direct the rest.
- QA Agent. Generates unit, integration, regression, API, and functional tests, and validates behavior parity against the legacy baseline before cutover.
The platform modernizes the UI, services, and data layers in coordination. Full-codebase grounding covers polyglot estates across .NET, Java, frontend, and database code, and the platform has processed over 10 million lines of code.
Modernization runs roughly 50% to 70% faster, which is the cost shift the path grid above depends on. No agent merges, deploys, or executes code, and all processing runs inside the organization’s own infrastructure.
For a portfolio, the choice between platform-led and services-led modernization is the decision point. Texas-based Legacyleap works as a turnkey modernization partner that owns delivery end to end, or licenses the platform so internal teams or systems integrators run the waves. A program can start turnkey on its first waves, then license the platform and run the rest of the portfolio in-house.
Next Steps for Planning an Enterprise Application Modernization Program
Enterprise application modernization holds together as a sequence. Shared data sets the waves, each wave closes on parity evidence, and AI-assisted transformation re-prices the applications that once sat on rehost or tolerate.
The $0 Modernization Assessment produces a dependency and module map, a risk and complexity heatmap, and a modernization plan for one representative application. It takes 3 to 5 days, runs inside your environment, and draws on more than 150 production-grade assessments.
A technical demo shows how the five agents take an approved plan through code changes and parity validation in an enterprise modernization program.
Start the Wave Plan With Measured Data
A $0 Modernization Assessment produces a dependency and module map, a risk and complexity heatmap, and a modernization plan for one representative application in 3 to 5 days, inside your own environment.
FAQ
Cloud migration changes where applications run, and enterprise application modernization changes their code, data, and architecture. A program can migrate an application in one wave and modernize it in a later one, which keeps a data center deadline from setting architecture decisions.
The first wave should combine low data coupling with at least one application that calls stored procedures, so the program tests its database logic decisions early. A first wave chosen only for ease leaves the hardest process untested until a riskier wave.
Cost is estimated per wave from a pilot application’s measured effort, adjusted for each wave’s path mix and shared data. A per-application average across the estate misses data cutover costs, which fall on the waves that move systems of record.
Rehosting fits when a fixed deadline, such as a data center lease or hardware end of life, arrives before a refactor could finish. The rehosted application needs a planned refactor wave in the portfolio plan, or its debt becomes permanent.
An insurer groups its policy, billing, and claims applications into waves around the shared policy database. Read-only reporting applications move first, and the policy administration system that owns the records moves last.
AI agents assess and document every application, draft code and test changes for engineers to review, and compare modernized behavior with the legacy baseline. Engineers keep authority over target architecture, approve every change, and own each release decision.
References
[2] Google, “Migrating Code At Scale With LLMs At Google” (arXiv, 2025)
[3] AWS Prescriptive Guidance, “Wave planning”
[4] Microsoft Azure Architecture Center, “Data considerations for microservices”
