Most people want a number before the project even starts. A flat fee. A go-live date. Something to hand to finance before anyone has opened the codebase. And just for the record, that's completely fair.
But cloud application modernization doesn't price out like a fixed quote. The real cost and timeline depend on what's actually running inside the system you're modernizing, not the project title. So in this guide, I'll discuss ranges to keep in mind, what changes them, and how to get a number you can plan around.
Cloud application modernization means moving an existing application into the cloud, or further into it, so it runs faster, costs less, or is easier to build on.
The most common misconception is that this is basically a hosting change: pick the app up, set it down in the cloud, done.
A simple rehost can be that straightforward. Real modernization usually isn't. It can involve replatforming, refactoring, rearchitecting, database changes, security updates, observability, CI/CD, and changes to how the application actually runs day to day.
Microsoft's guidance describes replatforming, refactoring, and rearchitecting as a continuum: Each step up costs more, carries more risk, and takes more testing than the one before it.
The simplest end of that continuum is a lift-and-shift: move the app to the cloud with almost no changes. The most involved is a full rebuild: rewrite the application as cloud-native software from scratch. In between, replatforming makes targeted upgrades so the app can use cloud features without touching its core architecture, and refactoring restructures the application itself, often breaking one large program into smaller services.
So many projects start with a loose scope and an optimistic estimate. Then the unknowns start to turn up mid-project:
A compliance requirement no one caught
Costs start climbing from there.
But the solution isn't a bigger contingency line. It's a clearer scope before the estimate gets written down.
After over 20 years in the business, I can say with confidence that three things move the number more than anything else.
Applications rarely run alone, and a tightly coupled architecture takes more work to untangle than a modular one.
A simple-looking web app might depend on an ERP system, Active Directory, shared file systems, APIs, message queues, scheduled jobs, or a reporting platform.
These dependencies have to be mapped before you sequence the work, because separating connected systems in the wrong order can cause outages. Dependencies are the most underestimated line item in almost every modernization estimate.
Technical debt, obsolete frameworks, unsupported libraries, tightly coupled code, and undocumented business logic all add engineering and testing time.
Technical debt is one major reason to choose refactoring over a simpler migration, since the code often isn't in good enough shape to just move as-is.
Moving a database is rarely a copy-paste job. It takes a real look at licensing and the shape of the data itself.
Moving off a licensed SQL Server database to open-source PostgreSQL is a different project than moving that same data into a NoSQL database.
Handled carelessly, it's also the easiest place to lose data or rack up downtime.
There's no universal number, but the range is fairly well established.
| Project Size | Traditional Approach | AI-Assisted Approach |
|---|---|---|
| Small (single application) | $50,000–$150,000 | $25,000–$75,000 |
| Medium (multiple connected systems) | $180,000–$270,000 | $75,000–$150,000 |
| Enterprise (portfolio-wide) | $500,000+ | $250,000+ |
Treat these as a guideline, not a quote. Your real estimate still depends on the cost drivers I outlined above, as well as the complexity of your setup. But at Capmation, AI-assisted delivery is one of the ways we’re changing the cost as well as cutting timelines up to 50%.
But to be clear, AI isn't a shortcut that skips discovery. What it allows is for discovery and execution to happen faster, because more of the repetitive analysis work is automated.
Timeline follows the same logic as cost.
A single, well-defined application can move through discovery, migration, and testing in a few months. An enterprise-wide program that touches a full application portfolio typically runs 12 to 36 months.
People want one clean cutover: flip a switch, done. In practice, a single big-bang cutover is riskier than it looks, and phased work almost always wins.
A common pattern for this is called the Strangler Fig approach, named after the strangler fig plant, which grows around a host tree until it eventually replaces it entirely. Applied to software, you build the modernized version of one piece of the application, redirect that piece of traffic or functionality to it, and leave everything else running on the legacy system in the meantime. Repeat that, piece by piece, until every part has been rebuilt and redirected. Only then does the legacy system get switched off.
Working in phases isn't just risk management. It's what makes a 12-to-36-month program manageable for the team doing the work. Nobody wants every system mid-migration at once.
At Capmation, we start with the outcome, not the technology. Always.
In an app modernization project, before recommending an approach, we find out what our client is actually trying to fix. The right modernization approach depends on the answer.
We also ask two separate questions:
1. Where should a workload run?
2. How much of it should change before it gets there?
Sometimes the right call is to migrate first and modernize later. Sometimes the codebase is in bad enough shape that modernizing during the move is unavoidable. Treating these as one decision is how projects end up over-scoped or under-scoped from day one.
Discovery is where we replace assumptions with evidence: an inventory of the architecture, code, integrations, databases, infrastructure, security requirements, and usage patterns, before we commit to a number.
Skipping that work is the fastest way to make a project more expensive than it needed to be.
We use AI, but highly skilled, seasoned engineers still drive the decisions.
AI helps our engineers understand unfamiliar legacy code faster: mapping dependencies, explaining business logic buried in old code, and generating documentation.
It also handles well-defined, repetitive work like upgrading framework versions, replacing deprecated libraries, converting older code patterns to current standards, generating infrastructure and deployment configuration, and generating tests that protect existing business behavior before we touch anything.
A few quick answers to the questions that come up most.
Costs typically run $50,000 to $150,000 for a single application with a traditional approach, or $25,000 to $75,000 with AI-assisted delivery. Enterprise-wide, portfolio-level programs run $500,000 or more traditionally, or $250,000 or more with AI-assisted delivery.
The biggest factor isn’t company size. It’s dependencies, codebase condition, and whether a database needs to move too.
A single, well-scoped application generally takes a few months, from discovery through testing.
An enterprise-wide program that modernizes a full application portfolio typically runs 12 to 36 months. That’s delivered in phases, though, not as one long wait. Each piece goes live and starts paying off as it’s finished, and AI-assisted delivery can help speed up each one.
No. Without the right analysis, a lift-and-shift can end up costing more in the cloud than it did on-premises. A workload that isn't adjusted to actually take advantage of cloud infrastructure doesn't get the cost or performance benefits people expect. It just moves the same inefficiencies to a more expensive environment.
Cloud application modernization services typically cover the full cycle: a discovery phase to map the current system and its dependencies, an architecture and migration plan, the actual development or refactoring work, testing, deployment, and support afterward. Discovery is the phase most often skipped. It's also the one that determines whether the cost and timeline estimate holds up.
Yes, when it's applied to the right parts of the process. A lot of the added speed comes from using AI to understand legacy code faster and automate well-defined, repetitive work, not from skipping discovery.
There's no honest single number for what cloud application modernization costs or how long it takes. In fact, if you receive an estimate that skips past this, that's a red flag.
Before you sign off on a budget or a deadline, look for a partner willing to open up your systems and show you the real scope, not one quoting a number off a project title.
If you like, my team offers complimentary Whiteboard Sessions to provide more realistic timeline and budget numbers.
They're also a great way to get a preview of how our team would approach a software challenge and anything we'd suggest to add more ROI.