How to Estimate the Cost of a .NET Modernization Project

A .NET modernization cost estimate gives you a defensible budget range before you commit to a rewrite or Azure migration. This guide, part of our technical guides series, walks through a six-step process, from codebase audit to Azure run cost, so you can present a grounded number to stakeholders.

What you need before you start

• Codebase and build script access: Read access to every .NET solution file, project file, and build script in scope. Without this, any estimate is a guess.
• Integration inventory: A written list of every system the application calls or is called by: databases, external APIs, file shares, MSMQ queues, COM objects, and scheduled tasks.
• Azure account with Contributor rights: Required to create an Azure Migrate project and run dependency analysis scans in the Azure portal.
• .NET Upgrade Assistant installed: Install via dotnet tool install -g upgrade-assistant. It scans solution files and generates a compatibility report for your migration to .NET 8. See the official .NET Upgrade Assistant documentation for setup details.
• Azure Migrate project created: In the Azure portal, go to Azure Migrate > Servers, databases, and web apps and create a new project. You will use this to discover application dependencies and generate infrastructure assessment reports.
• Azure Pricing Calculator open: A free Microsoft tool used in step 4 to model the recurring infrastructure cost of your target Azure architecture.
• Team rate information: Know whether you are using in-house staff, an external vendor, or a hybrid arrangement. Rates vary significantly and directly affect total build cost.

Step-by-step: estimating your .NET modernization cost

1. Size the codebase and count integration points. Run .NET Upgrade Assistant against your solution files to generate a compatibility report and line count. Then build your integration inventory manually by reading connection strings, service references, and configuration files. The integration count predicts effort better than line count: a 50,000-line application with 12 external integrations costs more to modernize than a 200,000-line application with two.
2. Classify each component as rehost, replatform, or rebuild. For each service, module, or application layer, assign one stance. Rehost (move to Azure VMs as-is) costs the least but delivers the least long-term benefit. Replatform (move to Azure App Service or Container Apps) requires more effort but reduces ongoing maintenance overhead. Rebuild (rewrite in .NET 8 with clean architecture) costs the most upfront and produces the largest reduction in future maintenance cost. Cost per component varies two to four times across these three categories, so classify carefully before aggregating totals.
3. Estimate engineering weeks per slice using a strangler-fig sequence. Do not estimate the entire application as a single block. Identify the first domain boundary you can extract behind an API gateway and estimate the engineering weeks for that slice alone. Then move to the next slice. This produces a phased cost schedule that stakeholders can fund by quarter rather than requiring a single large commitment upfront.
4. Add the recurring Azure run cost using the Azure Pricing Calculator. Model your target architecture in the Azure Pricing Calculator. For a mid-sized .NET 8 workload on App Service (P2v3, two instances), Azure SQL Database (General Purpose, four vCores), and Application Gateway, expect $800 to $2,500 per month. Add Application Insights, Azure Key Vault, and Blob Storage. This monthly cost is separate from the one-time build cost and must appear as its own line item in the business case.
5. Budget for data migration, parallel-run time, and integration testing. Data migration from SQL Server to Azure SQL typically adds 10 to 20 percent to total engineering effort, depending on schema complexity, stored procedure count, and data volume. Plan for four to eight weeks of parallel running where both legacy and modern environments operate before cutover. Budget 15 percent of total build cost as a contingency for integration testing, which consistently runs longer than initial estimates.
6. Add a contingency for unknowns discovered once the legacy code is open. Legacy .NET applications routinely contain undocumented business logic in stored procedures, COM interop dependencies, hardcoded environment paths, and embedded configuration that only surfaces during development. Add 20 to 30 percent contingency on top of your bottom-up estimate. Without a formal paid discovery phase, use 30 percent.

Understanding the main cost drivers

A .NET modernization budget splits into two categories: one-time build cost and ongoing Azure run cost. Most estimates that go wrong conflate the two or leave the second out entirely. Here is how the main drivers break down:

Full modernization engagements typically run $60,000 to $500,000 over 16 to 52 weeks. For a detailed breakdown by project size, see our .NET modernization cost guide.

Where this gets tricky

Three patterns account for most modernization projects that exceed their budget.

Quoting a fixed price before the codebase is assessed. It is not possible to give a defensible fixed price without completing a codebase review. Any vendor who quotes a firm number from an initial conversation is either guessing or building in a large buffer. Require a paid discovery phase (typically two to four weeks) before a firm statement of work is signed.

Forgetting the recurring Azure run cost. The one-time build cost is visible in the statement of work. The monthly Azure bill often does not appear in the original business case. A $200,000 modernization that adds $2,500 per month in Azure infrastructure costs $230,000 in year one and $260,000 by year two. Build the Azure Pricing Calculator output into the business case from the start.

Ignoring the integration surface. Line count is a weak predictor of modernization effort. Every API, database, file drop, message queue, and third-party service the application touches is a potential budget risk. A thorough integration inventory completed in step 1 is the single highest-value activity in the estimation process.

How QServices helps with .NET modernization

QServices has modernized .NET applications across manufacturing, financial services, and enterprise software. We use a strangler-fig migration pattern on .NET 8 and Azure, extracting domain slices behind an API gateway rather than attempting big-bang rewrites. Our engagements run 16 to 52 weeks and $60,000 to $500,000 depending on application scope, integration complexity, and data migration requirements.

We modernized a global VB.NET monolith for an environmental health and safety software company, rewriting it in .NET 8 and React on Azure to improve scalability and unblock features the legacy stack could not support:

We also rebuilt a stock analytics platform on ASP.NET Core and Azure SQL, replacing manual spreadsheet workflows with an automated, role-authenticated dashboard with real-time financial metrics:

If you are preparing a modernization business case, browse our technical guides or contact us for a scoped discovery engagement.

How do I know if a .NET modernization estimate is reliable?

A reliable estimate is based on codebase access, not a conversation. Ask the vendor to break out discovery cost, build cost by migration stance (rehost, replatform, rebuild), data migration, integration testing, and ongoing Azure run cost as separate line items. If they cannot do that, the number is not grounded in the actual work.