Budgeting for application modernization usually has a common problem: you get a range so wide it's useless, or a number with no reasoning behind it. This piece gives the market ranges by approach whether it’s a rehost or a rewrite, what impacts those numbers, and the questions that tell you whether a partner has read your system or is just selling a rewrite. If you're weighing in-house against a partner, that's here too.
What are application modernization services?
Application modernization services cover the work of updating an organization’s existing software i.e. moving it to new infrastructure, restructuring its code, or rebuilding it outright, so it can run on current platforms, integrate with modern tools, and scale the way the business needs it to. This work is delivered by a specialized engineering team (in-house, an outside partner, or a mix of both) rather than bought as a single off-the-shelf product, because every legacy system carries its own code and business logic.
The work maps onto the same five modernization strategies: Rehost, replatform, refactor, re-architect, and full replacement covered in depth in our companion piece, AI-Native vs. AI-Enabled: What’s Better for your Legacy System Modernization Needs? . This blog focuses on what those approaches cost and how to evaluate a partner to execute them.
How much do application modernization services cost?
Across publicly available vendor case studies and cost breakdowns, application modernization projects fall between $25,000 and $2 million or more per application, with the modernization approach and the size or age of the legacy codebase as the two biggest variables.
Note: The following has been compiled from published cost breakdowns across several modernization and engineering services providers, plus public-sector procurement records. Aggregated so no single provider's pricing is represented. Directional only. Please confirm with a scoped assessment of your own system.
Cost by modernization approach
| Approach | What it involves | Market range, SMB (under ~250 staff) | Market range, mid-market to large (250–5,000) | Typical timeline |
|---|---|---|---|---|
| Rehost (“lift and shift”) | Moving the app to new infrastructure with minimal code changes | $25K–$75K | $75K–$250K | 2–6 months |
| Replatform | Moving to new infrastructure with some code adaptation for performance or scale | $75K–$150K | $150K–$500K | 3–9 months |
| Refactor | Restructuring the existing codebase without changing what it does | $150K–$400K | $400K–$1.5M | 6–18 months |
| Rewrite | Rebuilding the application from scratch | $300K–$750K | $750K–$1.5M | 12–36 months |
How to read this table
- They are market benchmarks, so you can sanity-check any quote, including ours. Our pricing follows the scope: codebase condition, compliance requirements, and how much your team carries.
- Treat the ranges as a floor, not a quote. A bid meaningfully below the bottom of a band usually means the scope has not been looked at properly yet. That is the more expensive outcome, not the cheaper one.
- The two variables that move the number most are integration count and compliance scope. Both are knowable in a short assessment, before anyone commits a budget.
- Enterprise pricing is excluded on purpose. Systems at 5,000+ staff carry procurement and validation overhead that makes their numbers useless as a benchmark for everyone else.
What drives the cost up or down for app moderization
- Codebase age and size - more integrated systems and more lines of code mean more to test and migrate.
- Specialized platform requirements - systems built on older, less common platforms require harder-to-source engineering skill, which raises cost.
- Compliance and regulatory scope - healthcare, financial services, and government systems carry added validation and documentation requirements.
- Data migration complexity - the volume and cleanliness of the data being moved affects both cost and risk.
- Cutover risk tolerance - a phased migration that keeps old and new systems running in parallel costs more up front than a hard cutover, but reduces downtime risk.
How do the old and new systems overlap during migration?
Through most of a modernization project, both systems run at the same time. The new one takes real traffic while the old one still serves users, and the data layer writes to both. That period is the migration window, and it runs from a few weeks to several months depending on how many integrations have to move.
The cost consequence is direct. You pay for both systems, plus the engineering time to keep them in sync, for the entire overlap. Most estimates price the build and skip this.
Two questions worth asking any partner about this phase:
Where does the overlap window start and end on your plan, and what does it cost?A partner who has done this will answer in weeks and dollars. A partner who has not will treat cutover as a single day.Where is the rollback point?After a certain moment, reversing the migration means reconciling data written to both systems, which is a project of its own. If the answer is "we don't plan to roll back," the migration has not been planned.
Why modernization budgets overrun
A Wakefield Research survey of 250 software developers and architects at U.S. companies with 5,000+ employees found that 74% put the average cost of an application modernization project at nearly $1.5 million, and 79% said at least one of their organization’s modernization projects has failed outright. On timeline, 58% reported an average of 16 months to complete a project, and 27% reported two years or more. The most commonly cited failure reasons were incorrect expectation-setting (43%) and the need for organizational structural changes partway through (37%).
Ritu Jyoti, former GM/GVP of AI and Data at IDC, writing in CIO on why lift-and-shift alone isn't real modernization: "It moves the complexity, but doesn't solve it."
Most overruns trace back to one decision made too early: picking an approach before anyone has read the code.
How to choose an application modernization partner
The clearest signal is a vendor who names a rehost, replatform, refactor, or rewrite recommendation for your system and explains the reasoning behind it. This is our own recommendation based on how these engagements play out.
Questions to ask before you sign
| Ask | A real answer sounds like | A warning sign sounds like |
|---|---|---|
| Which approach do you recommend for our system, and why? | Names the approach, names the specific modules driving it, and says what they would need to see to confirm | “We’d recommend a rewrite” before anyone has read the code |
| Have you modernized a system of similar age, scale, and regulatory profile? | Names the stack and the constraints, and offers an engineer from that project for a call | A logo slide, or a case study with no technical detail |
| Who owns the code, architecture decisions, and data when the engagement ends? | “You do.” Points at the clause in the contract | “Shared IP,” “our platform,” or any hedge |
| How do you secure the migration itself, not just the finished system? | Explains access scoping, who touches production data, and how the parallel-run window is protected | Pointing at a SOC 2 certificate as the entire answer |
| Who is actually assigned to this project? | Named people, seniority mix, time commitment, and what happens if someone rolls off | Company headcount |
| How do you price, and what happens when scope changes? | A fixed-fee assessment first, then a scoped estimate with a named change process | A flat package quoted before any assessment |
Buy the assessment before you buy the project. A scoped assessment is a small, bounded purchase that produces a document you own and can take to any vendor, including a different one. A partner who will not sell you an assessment without a commitment to the build is selling the build.
Red flags to watch for
- A single proposed approach (usually "rewrite") regardless of your system’s condition.
- Vague or evasive answers about who retains ownership of the resulting codebase.
- No plan for how the legacy and modernized systems coexist during the migration window.
- A flat, pre-set "package" price with no scoped assessment behind it.
Build in-house or bring in a partner?
Build in-house if your team already has hands-on migration or refactoring experience on a comparable stack. Bring in a partner when your team is missing a skill the system needs, such as refactoring mainframe COBOL or containerizing a Java monolith. This mirrors the build-vs-buy framework covered in our Custom AI Development article: the deciding question isn’t "could we eventually hire for this," it’s "do we have it today, on this system." If you do bring in an outside partner, confirm explicitly in the contract that you retain ownership of the resulting code and architecture, otherwise a legacy-system lock-in risks being traded for a new vendor lock-in.
