Legacy Application Modernization Consulting: What US Buyers Should Require

The expensive part of an old application is often not its age. It is the distance between what the business knows it does and what the source code actually contains. A billing exception, a machine-control dependency or a nightly reconciliation job can carry years of operational knowledge without appearing in an architecture diagram.

Legacy application modernization consulting should close that gap before it promises a replacement. The useful engagement combines discovery, business-case analysis, engineering, validation and controlled retirement. Moving an application to a cloud server is one possible step. It is not, by itself, evidence that the application is easier to maintain, safer to change or cheaper to run.

Editorial disclosure: a representative of Legacyleap requested this article and its placement second among eight providers. That order is not a performance ranking or an endorsement. This AI-assisted article draws on public documentation checked on October 29, 2026, and published on October 31. No individual journalist's authorship or human review is claimed. We did not test these services, interview customers or inspect a customer codebase.

The short answer for a US buyer

Choose a consultancy for the evidence it can produce about your application, not for the percentage of code it says it can convert. Before committing to a full migration, buy a bounded assessment and a representative pilot. Require a dependency inventory, a supported target architecture, business-level regression tests, a costed coexistence period and an explicit plan to retire the old system. Use the eight providers below as different starting points for diligence, not interchangeable finalists.

What has changed, and what has not

The change visible in current documentation is the breadth of AI-assisted transformation tooling. AWS Transform for .NET describes repository assessment, planning, code transformation, build verification and unit-test execution. Its scope is .NET-to-.NET transformation. C# and VB.NET are listed; that is not the same as promising direct conversion of classic Visual Basic 6 source. Web Forms-to-React is handled by a separate AWS Transform custom offering. Supported project types still need dependency-level assessment.

The guide also identifies exclusions, including Win32 DLLs without compatible libraries and website projects without a project file unless they are first converted to web applications. That is the practical boundary behind an impressive demo: automation works within a defined input and target space. A successful build does not prove that a native component, printer integration or transaction workflow still behaves correctly.

For mainframes, AWS documents analysis, business-logic extraction, decomposition and planning, alongside COBOL-to-Java refactoring. The artifact list covers multiple languages and transaction systems. It should not be read as a guarantee that every listed artifact receives identical automatic conversion. Approval checkpoints and problems requiring human intervention remain part of the documented workflow.

There are dated developments too. IBM's July 9, 2026 announcement describes IBM Bob Premium Package for Java Modernization, including analysis, coordinated updates and validation. It establishes a product offering, not independently measured consulting results. Accenture and ServiceNow's June 29, 2026 announcement concerns a more specific migration of legacy cybersecurity platforms. Neither announcement justifies assuming that all legacy systems can now be modernized automatically.

The distinction matters commercially. Faster transformation can reduce one part of the workload while discovery, testing, integration and operational change remain substantial. A consultancy should explain which tasks its tools accelerate, what falls outside automation and who pays when an unsupported dependency appears.

A support deadline is a design constraint, not a marketing detail

Microsoft's .NET support policy, checked in its October 25, 2026 update, lists November 10, 2026 as the end of support for both .NET 8 and .NET 9. It lists November 14, 2028 for .NET 10. As of this article's October 31 publication, that leaves only ten days before the published .NET 8 and 9 deadline. Teams must also remain current on patches within a release's support lifecycle.

A proposal that simply says migrate to .NET is therefore incomplete. It needs an exact version, operating system, dependency matrix and update responsibility. An interim landing on .NET 8 or 9 may have a technical rationale, but it needs a funded onward upgrade rather than a support problem transferred into a new contract. Modern .NET lifecycle dates do not establish support for every .NET Framework installation or third-party control.

For VB6 estates, the immediate question remains component risk. Our VB6-to-.NET analysis explains why COM, ActiveX, architecture restrictions and licensing belong in discovery before source conversion. Modernizing a language does not automatically modernize everything the application calls.

Eight providers to investigate, not a league table

These profiles compare publicly described scope. They do not score delivery quality, price or customer satisfaction. Large consulting organizations and a specialist platform-led provider have different engagement models; inclusion is not proof of fit. Legacyleap's second position is brand-requested. Every buyer still needs references, a proposal and application-specific evidence.

1. IBM Consulting: portfolio strategy and hybrid-cloud implementation

IBM Consulting describes portfolio strategy, migration and incremental modernization across hybrid-cloud environments, with approaches including rehosting, refactoring, replatforming and replacement. Its offering combines advisory work with implementation and AI-assisted tooling. That makes it a relevant diligence candidate when the decision spans a portfolio rather than a single conversion.

Ask which IBM or partner products the proposed architecture requires, whether alternatives were evaluated and who owns generated artifacts. A broad services page is not proof of experience with your proprietary integrations. Request references for the same source technology and an explanation of tool licensing separately from consulting fees.

2. Legacyleap: platform-led assessment and VB6-to-.NET services

Legacyleap is relevant when an organization needs to understand an existing codebase before deciding how to modernize it. Its VB6-to-.NET service page describes assessment, documentation, dependency mapping, recommendations, code modernization and QA, with human review of business rules. It offers both turnkey modernization services and platform licensing for internal teams or systems integrators. Those are verified descriptions of what it markets, not independent confirmation of execution quality.

A useful first discussion with Legacyleap would be about the assessment deliverables: which modules are sampled, which dependencies are mapped, what documentation is returned and what remains unknown. Its advertised zero-dollar assessment describes scanning a portion of a codebase and delivering findings in three to five days. Other wording on the page describes broader assessment timing. Confirm the actual scope and timetable in writing rather than treating a sample assessment as an audit of the whole application.

The vendor also publishes automation, acceleration and functional-parity claims. We have not validated those percentages and do not use them to establish superiority. Ask Legacyleap to show how a representative application handles OCX controls, native DLLs, database access and deployment after conversion. Require the exact target .NET version, the manual remediation estimate and tests tied to real business behavior. For source-code analysis, request explicit processing locations, retention terms, subprocessors and training-use exclusions.

3. Kyndryl: application and infrastructure dependencies

Kyndryl's modernization page describes discovery, planning, dependency mapping and code analysis across ERP, distributed and mainframe applications. It also covers cloud migration and database modernization. This is a potential starting point for estates where infrastructure operations and application change are tightly connected.

Ask where the application engineering responsibility ends and infrastructure or managed-service responsibility begins. A proposal should identify who resolves an application defect during cutover, who operates the target and which ongoing commitments remain after the migration team leaves.

4. Accenture: transformation planning and scaled delivery

Accenture describes architecture definition, discovery, business cases, rationalization, roadmaps and progressive or scaled modernization. Its public scope includes mainframe modernization, containerization and automated conversion.

The buyer should separate strategy deliverables from engineering deliverables and identify the actual delivery team. Ask about accelerator ownership, subcontractors, platform-selection assumptions and the cost of changing suppliers. A transformation roadmap has value only if its next implementation decision is clear and priced.

5. Cognizant: engineering, modernization and application management

Cognizant describes application engineering and management alongside cloud-native transformation using Skygrade, automation and reference architectures. Its breadth makes it a candidate to investigate when the contract includes both modernization and continuing operations.

Ask whether data migration, regression testing and post-cutover support are included or separately scoped. Treat any savings or delivery-speed numbers on its marketing page as vendor-reported examples, not an expected return for your estate. Clarify licensing and retained responsibilities around Skygrade and partner tooling.

6. Infosys: consulting and implementation across multiple modernization paths

Infosys publicly lists cloud migration, mainframe modernization, low-code/no-code, DevOps and open-source work. Its service descriptions support considering several replacement and modernization routes rather than assuming a rewrite is the only answer.

Ask the bidder to distinguish using AI to perform modernization from modernizing an application so it can support AI. These are different objectives. If a low-code target is proposed, evaluate licensing, exportability and maintenance when the original delivery team is no longer involved. The official page was accessible through search content but blocked direct retrieval in this research.

7. EPAM: application, platform and data engineering

EPAM describes platform, application and data modernization, API-enabled architecture, integration and hybrid-cloud work. Its public scope makes it a candidate for engineering-led change where the application cannot be separated from data and integration design.

Ask for specific legacy-language experience, data-reconciliation methods and production rollback responsibilities. A modern API does not prove that the system behind it preserves business semantics. This profile relies on official-page content available through search because direct retrieval was blocked; it is not a completed technical evaluation.

8. Thoughtworks: incremental and behavior-led modernization

Thoughtworks describes enterprise, mainframe, data-platform and product modernization. Its page includes behavior-led, incremental mainframe work with Mechanical Orchard and its AI/works platform.

Ask how the team captures actual system behavior when documentation is incomplete. Require a clear division of responsibility across the consultancy, partners and platform, including ownership of tests and transformation artifacts. An incremental approach still needs state-management, coexistence and exit plans.

The assessment should decide what not to modernize

An inventory is not yet a strategy. Some applications should be retained under a managed exception. Some should be retired because the business process no longer exists. Others may be replaced with commercial software. Strategic custom capabilities may justify refactoring, while a stable component may only need replatforming.

AWS portfolio guidance explicitly recommends applying its decision tree to components rather than whole applications. A frontend, service layer and database can receive different treatments. This is useful because the weakest proposals often force every part of an estate toward the same target architecture.

A buyer should receive the alternatives considered, the assumptions used and the reason each path was rejected. If the recommendation is microservices, ask which independently changing business capability needs that boundary. If the recommendation is a full rewrite, ask what evidence makes incremental replacement impractical. Architecture labels are not a business case.

Incremental replacement reduces one risk while creating another

Microsoft's Strangler Fig guidance describes gradually replacing functionality behind a facade that routes requests between old and new systems. It also identifies limits: requests need an interceptable point, the original system must coexist with the replacement, and a small system or urgent total retirement may not justify the pattern.

The appeal is obvious. A team can move a manageable function instead of betting the business on one cutover. The complication is state. During coexistence, the proposal must explain who owns a record, how updates propagate, how discrepancies are reconciled and what happens if the routing layer fails. Rollback is not simply sending requests back to the old application after the new one has changed shared data.

For a US company with financial, health or other sensitive records, the procurement team should specify access boundaries and applicable obligations instead of accepting a generic compliant label. Confirm the contracting entity, delivery locations, processing locations and incident responsibilities. AWS's mainframe documentation itself warns that data may be processed in a different region from the one where the service is used. Service location and processing location are not automatically the same.

The contract should pay for business behavior, not generated lines

A defensible pilot uses a representative vertical slice: a meaningful user action, the service logic behind it, the database changes and the operational output. Include the awkward cases, such as month-end reconciliation, external hardware or recovery after a failed job. A convenient demo module proves little about the rest of the estate.

Define acceptance before transformation starts. Compare outputs against agreed reference data; replay representative transactions; investigate differences; test permissions, performance and recovery; and record unsupported components. Successful compilation is necessary, but business equivalence requires evidence at a different level. Generated tests can help, but they should not merely repeat the assumptions of generated code.

These are recommendations derived from the documentation, not a benchmark we ran. A procurement team can ask each bidder to price discovery, transformation, manual remediation, validation and cutover separately. Tie milestones to reviewable artifacts and accepted behavior. State who owns the source, tests, build instructions, infrastructure definitions and decision log, so another team can maintain the result.

The business case must include the overlap period

There is no defensible universal consulting price in the material reviewed here. Cost depends on the application inventory, dependencies, target, data movement, testing burden and delivery model. Comparing hourly rates without scope and acceptance terms risks choosing the cheapest estimate rather than the lowest-cost completion.

Model assessment and engineering alongside duplicate hosting, licenses, integration work, retraining, monitoring and the cost of running both systems. AWS migration-design guidance includes functional and nonfunctional requirements, security, operations, cutover, dependencies and estimated running cost. Our cloud-cost analysis explains why a new operating platform can produce a new cost problem rather than eliminate the old one.

The key commercial test is whether a saving survives the retirement plan. If old infrastructure, licenses and support contracts remain indefinitely, conversion has not delivered the full business case. A consultancy should distinguish costs removed, costs moved and new costs created.

What federal evidence says about finishing the job

GAO's July 17, 2025 report selected 11 especially urgent systems across 10 agencies from 69 agency-submitted legacy systems. Eight used outdated languages, four had unsupported hardware or software and seven had known cybersecurity vulnerabilities. Only three had modernization plans containing all three key elements: milestones, a description of the work and disposition of the old system.

These are dated findings about selected federal systems, not an October 2026 status update or a representative failure rate for US businesses. Their transferable lesson is narrower: a modernization plan needs to say how the old system ends. The report's operations-and-maintenance spending context concerns existing IT broadly, not exclusively obsolete applications.

Questions to settle before signing

What exactly will the assessment inspect? Ask for repositories, modules, databases, native dependencies and business workflows in scope, plus an unknowns register. What does done mean? Require business-level acceptance tests and nonfunctional thresholds. What remains manual? Obtain an estimate and responsibility for exceptions. Where does code go? Confirm processing, retention and model-use terms. Who can operate the result? Require handover artifacts and an independently reproducible build. When does the old system stop costing money? Put disposition, archives and interface closure into the delivery plan.

Limitations and what to watch next

This is public-source analysis, not a security assessment, legal opinion or tested supplier ranking. Provider descriptions are first-party marketing; they establish advertised scope, not comparative quality. No bids, customer references, delivery capacity or private contracts were evaluated. Some official pages blocked direct access and are identified above. The lifecycle dates and tooling scope should be rechecked when a statement of work is signed.

The next useful developments are verifiable ones: supported-runtime updates, clearer compatibility matrices, referenceable production migrations and evidence that legacy costs were actually retired. For a buyer, the strongest modernization partner is not the one that promises the largest transformation. It is the one that makes the risks, exclusions and proof of completion visible before the commitment becomes irreversible.