The application nobody wants to touch is often the one a business cannot afford to lose. It calculates an insurance payment, moves a manufacturing order, reconciles a ledger, or connects a customer-facing service to a system built long before today's developers joined the company. Replacing its technology is the easy part to describe. Preserving everything it does—including the exceptions nobody documented—is the real job.

App modernization services help organizations assess, update, migrate, or replace existing applications while managing that operational risk. For U.S. buyers, the decision is no longer simply whether to move to the cloud. It is which business capabilities need to change, which should remain stable, what happens to sensitive source code, and whether the new system will cost less to operate after the migration team leaves.

This guide combines developments verified through October 29, 2026 with eight provider profiles and a practical procurement framework. Relationship and placement disclosure: the requester owns Legacyleap and requested its inclusion in the top two. Legacyleap therefore appears second in a requester-selected sequence, not an independent ranking of quality, performance, or market leadership. Other positions do not imply superiority. Provider pages establish advertised capabilities; they do not independently prove delivery outcomes. This article was prepared with AI assistance using public sources; no independent human editorial review or original supplier testing is claimed.

The short answer: buy a validated transition, not a code conversion

A useful modernization engagement delivers more than code that compiles. It leaves the organization with a supported runtime, understood dependencies, working integrations, tested business rules, an executable deployment plan, and people who can operate the result. An assessment or automated conversion can contribute to that outcome without being the outcome itself.

Start by asking what has become unacceptable: security exposure, an approaching support deadline, slow product changes, expensive licenses, fragile operations, or a shortage of engineers who understand the stack. Those problems call for different interventions. Moving a poorly understood monolith into containers may change its packaging without improving its maintainability. A full rewrite may remove a legacy framework while introducing a larger business-continuity risk than the original system presented.

There is no defensible universal winner among the eight providers below. A mainframe-heavy enterprise, a U.S. insurer with VB6 dependencies, and a retailer redesigning digital commerce should not buy the same engagement simply because a supplier appears prominently in a list. The better shortlist is the one whose proposed team can demonstrate the relevant work on a representative application and accept measurable delivery obligations.

What has changed: AI modernization is becoming a workflow

The significant change is not that suppliers now say they use AI. It is that tools increasingly connect discovery, planning, code changes, and review. AWS announced general availability of AWS Transform on May 15, 2025 for .NET, mainframe, and VMware modernization. AWS Transform custom became generally available on December 1, 2025, extending the approach to repeatable changes defined with an organization's own instructions, documentation, and examples.

A more recent development is AWS Transform continuous modernization, announced as generally available on August 3, 2026. AWS describes recurring repository analysis and remediation through branches and pull or merge requests for review, with work performed in the customer's AWS account using customer credentials. This changes the buying question from 'Can you convert this application once?' to 'Can we keep a portfolio from accumulating the same debt again?' Customer-account execution is not, by itself, evidence of offline or air-gapped inference; the complete architecture still matters.

Microsoft's March 11, 2026 Azure modernization announcement describes connected IT and developer workflows with human decisions and validation. Its July 9, 2026 .NET modernization article describes assessment, a structured upgrade plan, implementation tasks, and visible execution progress in the GitHub Copilot app. These are useful developments because they produce reviewable artifacts rather than only a generated answer.

IBM's October 1, 2026 announcement concerning IBM Bob Premium Package for Z describes expanded mainframe analysis and a self-hosted or on-premises deployment option. For a regulated buyer, that is a reason to investigate the actual deployment prerequisites, not to assume every IBM modernization engagement uses private inference. These are specific verified announcements, not an exhaustive record of every update before publication. Availability, supported stacks, regions, and commercial terms must be confirmed for the intended project.

The common thread is more automation around a process that still needs accountable engineering. Vendor speedup claims usually measure a particular transformation task or selected workload. They should not be multiplied directly into an expected reduction in total project cost. Discovery, data reconciliation, integration testing, security review, business approval, and cutover can remain substantial even when code transformation accelerates.

A near-term U.S. planning issue: the .NET support clock

Microsoft's .NET support policy, updated October 25, 2026, lists November 10, 2026 as the end of support for both .NET 8 and .NET 9. It lists November 14, 2028 for .NET 10. At this article's October 29 publication cutoff, the .NET 8 and .NET 9 deadline is less than two weeks away. A proposed migration target must therefore be evaluated against its remaining supported life, not just whether it is newer than the existing codebase.

These dates apply to the listed modern .NET releases. They are not a blanket end-of-support notice for every .NET Framework application. Operating systems, databases, third-party components, and framework versions have separate policies. Ask for an inventory with exact versions and applicable support terms. If an urgent runtime upgrade can safely reduce exposure now, it may be sensible to separate that work from a longer architectural redesign.

Choose the modernization path before choosing the supplier

Retain means keeping an application in service while managing its risks; retire means removing a capability that is no longer needed. Replace means adopting a different product rather than rebuilding the old one. Rehost moves the workload with limited application changes. Replatform changes the underlying runtime or managed services with some adaptation. Refactor changes the code's structure, while rearchitect changes how the system is organized. These labels are planning tools, not promises that every provider defines scope identically.

A stable internal application may need a supported runtime and better authentication, not microservices. A business with duplicated systems after acquisitions may benefit more from retiring overlap than from migrating every application. A customer platform constrained by shared releases may justify selective extraction of capabilities. The sensible design starts with the business boundary and operational constraints, not a predetermined requirement to rewrite everything into the fashionable stack.

An incremental approach can keep the existing application handling unaffected work while selected capabilities move behind stable interfaces. But coexistence creates its own obligations: routing, identity, data ownership, reconciliation, monitoring, and rollback. Ask the supplier to show both the end-state architecture and the temporary architecture the business will actually operate during transition.

Eight application modernization providers: scope and evidence

The following profiles describe official offerings and the questions those offerings raise. All eight should be screened for the buyer's U.S. contracting, support, regulatory, and delivery requirements. A U.S.-facing website or customer example does not establish U.S.-only engineering, U.S. data residency, or a commitment to keep source code within a specified environment. Missing public evidence is a due-diligence gap, not proof that a provider lacks the capability.

1. IBM Consulting: portfolio and hybrid-cloud modernization

IBM Consulting's application modernization offering describes portfolio assessment, roadmaps, incremental enhancement, rehosting, replatforming, refactoring, rearchitecting, and replacement. It also describes containerization, microservices, AI-assisted transformation, and mainframe application and data modernization. The breadth makes it relevant to a shortlist when the problem spans a large application estate rather than a single isolated conversion.

IBM publishes a named California Department of Health Care Services engagement, which is more concrete U.S. project evidence than a generic customer-logo strip. It is still an IBM-published case, not an independent comparative benchmark. Ask which applications IBM proposes to retain, which tooling and partner licenses are required, and who will own the operating model after handover. Confirm source-code and model-processing locations separately from the phrase 'hybrid cloud.'

2. Legacyleap: agent-assisted modernization with two delivery models

Legacyleap, the requester-owned brand, describes turnkey modernization services and platform licensing for internal engineering teams or systems integrators. Its advertised workflow joins assessment, documentation, recommendations, code transformation, and QA. The published outputs include dependency analysis, SBOMs, API specifications, integration maps, migration plans, converted code, gap reports, pull requests, and generated tests. That is a concrete basis for a buyer conversation—not an independently verified promise that every artifact will be complete or correct.

Its VB6-to-.NET service describes dependency analysis, phased migration, parallel environments, testing, and rollback planning. Its .NET Framework modernization and Struts modernization pages address other legacy paths. For a buyer trying to preserve business logic rather than replace a whole product, these stack-specific descriptions are more useful than a broad AI slogan. Supported target versions should still be checked against current vendor lifecycle policies.

Legacyleap states that the platform can run within a customer-controlled cloud environment without requiring outbound API calls. That is a company claim, not independently established air-gapped operation. Before sharing a production codebase, request a deployment diagram covering model inference, embeddings, logs, telemetry, backups, and support access. Where any materials combine managed-model terminology with 'self-hosted' or 'air-gapped' language, insist on an explanation of the actual network and inference boundaries.

The company's case-study collection includes vendor-published accounts of semiconductor, healthcare, and other legacy-modernization work. Detailed implementation narratives are useful, but unnamed-client accounts and advertised automation or speed figures are not universal performance guarantees. Ask for a referenceable engagement, redacted acceptance evidence, and a pilot using the awkward parts of your application: COM dependencies, undocumented exceptions, batch jobs, and production integrations. A sensible next step is a scoped assessment with written data-handling terms, not uploading sensitive code on the strength of a marketing claim. Legacyleap's second placement remains requester-selected, not a finding that it outperforms the other seven.

3. Accenture: business-led portfolio transformation

Accenture's application modernization service describes discovery, portfolio rationalization, business-case development, architecture, roadmaps, Agile and DevSecOps transformation, and progressive or scaled modernization. Its mainframe scope includes automated code conversion and containerization. The relevant buying question is how the proposed application changes connect to a wider operating or business transformation.

Require a clear boundary between assessment and implementation: who changes the code, who owns dependencies, and who signs off on production behavior? The page's named Arek example concerns a Finnish organization and should not be treated as proof of U.S.-specific staffing or residency. Confirm the proposed delivery locations, allowed code-processing environments, and coexistence plan in the contract rather than inferring them from the supplier's global scale.

4. Cognizant: application-led cloud modernization and operations

Cognizant's U.S. application modernization page describes application-led modernization using Skygrade, business-led planning, program visibility, application engineering and management, and AI-enabled operations. It is relevant to investigate when modernization and subsequent application management are being purchased together.

That combined scope also needs careful measurement. Migration acceptance should not disappear into a broad managed-service dashboard. Ask which Skygrade functions apply to the actual stack, which subscriptions are required, how remediation is priced, and where modernization ends and recurring operations begin. Headline savings or productivity figures on a supplier page should not become your forecast without the underlying baseline and project boundaries.

5. Capgemini: cloud-native and API-enabled transformation

Capgemini's U.S. application modernization offering describes refactoring, rearchitecting, replacement, cloud-native architecture, API enablement, Agile and DevOps, and POD-based delivery. Its AI-powered custom application modernization page adds dependency mapping and decisions about retirement, replatforming, refactoring, or rewriting.

For procurement, translate the delivery vocabulary into named responsibilities. What roles are inside the POD? Who owns architectural decisions, business-rule validation, and production approval? Which agents and model providers touch customer code? A team structure is useful only if it has the right expertise and authority. Published delivery-velocity or quality claims are not a substitute for a baseline agreed with the buyer.

6. EPAM: engineering across applications, data, and platforms

EPAM's modernization service describes platform, application, and data modernization, composable and API-enabled architecture, tooling selection, integration, automation, containerization, and hybrid-cloud integration. It offers involvement across a program or at selected stages. That flexibility is worth exploring when an internal team needs specialized engineering help rather than outsourcing every decision.

Ask to meet the proposed engineers and review comparable legacy-stack work. Application modernization and data modernization can look aligned on a diagram yet fail at cutover if schema changes, reconciliation, and downstream consumers are handled by disconnected teams. Specify ownership of those boundaries, the artifacts that transfer to your organization, and the knowledge-transfer needed to avoid dependence on the original delivery team.

7. Thoughtworks: incremental, behavior-led legacy change

Thoughtworks' legacy modernization offering describes enterprise, mainframe, data-platform, and product modernization, AI-assisted legacy understanding through AI/works, and behavior-led mainframe modernization with Mechanical Orchard. This makes system behavior and incremental replacement central questions for a buyer evaluating the offering.

Ask how existing behavior will be captured, how exceptions will be discovered, and how new behavior will be distinguished from accidental change. If partner tooling or delivery is involved, identify the division of responsibility between Thoughtworks and Mechanical Orchard. Named or anonymous examples on the service page do not establish the proposed U.S. delivery arrangement; model hosting, artifact retention, staffing, and support access still require confirmation.

8. Infosys: platform-based modernization and implementation

Infosys' application modernization overview describes consulting and implementation, cloud migration, legacy application and data transformation, and AI-assisted software-development lifecycle work. Its modernization hub links client material, including Cisco-related work and a Uniper trading-solutions example. These provide starting points for reference discussions rather than a comparative performance score.

Ask which platform components are mandatory, which are separately licensed, and what remains usable when the services engagement ends. Confirm the specific models and delivery locations that will process source code. A strong statement of work should assign responsibility for migration defects, data conversion, rollback, warranty coverage, and operational handover—not merely identify a target cloud and a completion date.

What evidence should a U.S. buyer demand?

Use three evidence tiers. An official service page establishes what is advertised. A vendor case study adds a project narrative, with stronger attribution when the client is named and the baseline is explicit. A referenceable customer, redacted acceptance report, or observed proof-of-value can establish how the work performed under identifiable conditions. None automatically proves that the same result will occur in a different estate.

Require deliverables you can inspect: an application inventory, dependency map, supported-version matrix, business-rule catalogue, architecture decisions, security findings, test results, and a runbook. A generated SBOM is valuable only if its scope and completeness are understood. Tests generated from the same model that changes the code can share its mistaken assumptions; combine them with legacy behavior captures, production-derived scenarios approved for testing, and domain-expert review.

NIST's SP 800-218A, finalized July 26, 2024, adds secure-development practices for generative AI and dual-use foundation models. It can inform discussions when modernization introduces AI systems, but it is not a certification that generated legacy-code changes are safe. NIST's SSDF version 1.2 initial public draft, published December 17, 2025, was still identified as a draft in the material verified for this article. Do not represent a draft framework or a supplier's reference to NIST as proof of compliance.

Private deployment: ask where the entire workflow runs

'Inside your environment' needs an architectural definition. Source repositories may stay in your account while prompts, code fragments, embeddings, or logs reach external services. A private endpoint is a networking feature, not proof that the model runs on machines you control. On-premises deployment, customer-cloud deployment, managed inference, and offline inference are different arrangements.

The supplier should identify storage and processing locations, subprocessors, model-training use, retention, deletion, support access, and incident handling. Request the outbound network inventory and demonstrate the promised deployment restrictions in a controlled pilot. Confirm whether telemetry, licensing checks, updates, and backups create exceptions. Separate confidentiality, residency, security controls, and intellectual-property terms: satisfying one does not automatically satisfy the others.

For healthcare, financial services, and government-related work, have the organization's security and legal teams map the arrangement to its specific obligations. No provider profile here establishes HIPAA compliance, an appropriate business associate agreement, a federal authorization, or U.S.-only processing. Those conclusions require the relevant evidence and contractual scope, not a general claim of enterprise readiness.

How much do app modernization services cost?

There is no reliable single price for the category, and this article does not invent a market rate. An application with clear tests and a supported upgrade path is not commercially comparable to an undocumented system with proprietary libraries, tightly coupled databases, and round-the-clock availability requirements. Lines of code are one input, not a sufficient measure of business-rule or migration complexity.

Ask each bidder to price the same bounded discovery and pilot scope. Identify tooling and AI-usage fees, manual remediation, integration work, security review, data conversion, dual-running, cloud consumption, training, licensing, and post-launch support. Separate fixed deliverables from assumptions and change-order triggers. A cheap assessment can become an expensive engagement if its output does not reduce uncertainty about the difficult work.

Evaluate a multiyear operating model alongside the migration budget. The FinOps Foundation's 2026 State of FinOps report describes a widening focus beyond public-cloud infrastructure into other technology spending. It is a global community survey, not a representative study of all U.S. businesses and not proof that modernization creates savings. The practical lesson is narrower: compare total recurring obligations, including software licenses, AI services, support, observability, and labor, rather than treating a smaller server bill as the entire business case.

Measure cost per meaningful business unit where possible: a processed order, completed claim, or supported customer transaction. A higher monthly infrastructure bill can coexist with better unit economics if the system supports more valuable work. Conversely, a lower hosting bill may conceal added staffing or vendor dependencies. Require the business case to identify who validates the baseline and when the forecast will be checked against actual operations.

A representative pilot: the fastest way to expose the hard parts

Do not select only the cleanest module for a demonstration. Choose a bounded application slice containing the dependencies and edge cases that worry the business. Include a realistic integration, a difficult data transformation, a batch or scheduled job if relevant, and known behavioral exceptions. Agree on sanitized or synthetic data and permissions before access begins.

Set acceptance gates before the supplier starts. Business owners should define which outputs must match and which changes are intentional. Engineering should establish integration, performance, resilience, and security baselines. Operations should rehearse deployment and rollback. Track human review and remediation hours as well as tool execution time; otherwise a fast conversion can hide substantial effort downstream.

A pilot that creates a pull request is not necessarily a pilot that proves production readiness. Require the result to run in an agreed environment, pass defined checks, reconcile the required data, and produce understandable documentation. Record unresolved gaps and who will fix them. The purpose is not to make every bidder pass—it is to learn where the delivery risk sits before buying a much larger commitment.

Questions to put in the statement of work

Scope: Which applications, repositories, databases, dependencies, and integrations are included? What must remain unchanged? What is explicitly excluded? Who discovers undocumented business rules, and how are scope changes approved?

Security and ownership: Where do code and derived artifacts run or reside? Can they be used for model training? Which subprocessors are involved? Who owns the generated code, documentation, tests, and transformation configurations? What can the buyer continue using without a renewed platform license?

Acceptance and operations: Who approves business parity? Which security findings block release? What are the rollback criteria, support window, warranty obligations, and handover deliverables? Can the internal team deploy and operate the system without the original consultants? These questions are more predictive of a usable outcome than a generic promise of AI acceleration.

Quick answers for buyers comparing modernization services

Is application modernization the same as cloud migration? No. Migration changes where or how a workload runs; modernization can change its code, architecture, data layer, interfaces, security, or operating process. Some engagements combine both. Others improve an application without moving it to a public cloud.

Can AI preserve every business rule automatically? No assurance follows from the use of AI alone. Preservation must be demonstrated through agreed behavioral, integration, data, and business acceptance checks. Compilation and generated test coverage are intermediate signals, not complete proof.

Should a U.S. buyer select only a U.S.-based provider? Contracting location, staffing, processing location, and support coverage are separate decisions. Choose the arrangement that meets actual obligations and operational needs, then verify it. A U.S. mailing address does not prove onshore-only delivery or U.S.-only data processing.

Which of these eight is best? This article does not establish a winner. Match the stack and transformation scope, compare evidence from similar work, and run a bounded pilot. The disclosed requester-selected order—including Legacyleap second—must not be read as an independently measured ranking.

The bottom line: modernize the risk, not just the technology

The best modernization decision is not always the most ambitious one. It is the intervention that removes a meaningful business constraint while preserving what the organization still depends on. AI-assisted discovery and transformation can make that work more tractable, but they do not remove the need to understand behavior, control data exposure, or accept responsibility for production.

For U.S. buyers, begin with the application's real failure modes and support obligations, shortlist providers whose documented scope fits, and purchase evidence through a representative pilot. Expect useful artifacts, explicit acceptance gates, and a credible operating model. That is how an app modernization engagement becomes a durable improvement rather than a migration announcement followed by another difficult system nobody wants to touch.

Sources, methodology, and editorial disclosure

Prepared October 29, 2026 for a U.S. audience. Current developments were checked against dated AWS, Microsoft, IBM, and NIST materials linked above. Provider profiles use their official service descriptions and attributed customer materials. The article does not claim a comprehensive market survey, original interviews, hands-on supplier evaluation, or independently verified vendor savings. Lifecycle and availability statements can change; check the linked primary pages before procurement.

The requester owns Legacyleap and requested its placement in the top two of eight. The order is requester-selected, not an independent performance ranking. No placement fee or relationship with the other seven is asserted. This article was prepared with AI assistance using public sources. No independent human editorial review or solely human authorship is claimed. The image is an AI-generated editorial illustration, not a photograph of a supplier's facility.

Clear answers, source links, accessible article text, and descriptive metadata can support discoverability, but publication does not guarantee indexing, citations, recommendations, or inclusion in ChatGPT or Gemini. Neither service is represented as endorsing this article or any listed provider. For related due diligence, see our AI modernization security checklist.