Why .NET Modernization Programs Stall at Scale (and How to Increase Throughput)

You’ve made the investment. You’ve allocated resources. You’ve set deadlines. But now… You’re stuck in a perpetual state of .NET modernization.

Years pass. Your development team keeps rewriting code for one application after another. Yes, some of your .NET Framework applications are now running on the latest .NET Core version. But dozens of other legacy apps are still in the backlog, waiting for their turn. What was supposed to be a short-term project has turned into a never-ending drag.

Sounds familiar? At Exoft, we’re no strangers to helping clients exit this very modernization purgatory. Our solution is hardly revolutionary: we set out to make every migration as repeatable as possible instead of treating each application as a separate rewrite.

Here’s how to put this approach to practice to get your large-scale .NET migration out of the modernization limbo. Spoiler alert: AI helps automate routine, but it’s not a silver bullet.

Why .NET Modernization Slows Down Across Large Application Portfolios

Keeping a legacy .NET app portfolio as-is isn’t just an inconvenience; it’s a business risk with hidden costs like:

• Slow releases even for tiny changes
• Integrations so complex you decide to put them off
• System workings becoming tribal knowledge
• Slow root-cause analysis after incidents

In fact, security, reliability, and scalability are the top three reasons why companies modernize their portfolios:

Source: Red Hat 2024, Security, reliability, and scalability are the main reasons for modernizing legacy applications

Large-scale .NET application modernization projects rarely stall because migration itself is slow. They usually stall because decision-makers don’t approach it as a single portfolio modernization initiative.

«If you have 50 applications to modernize, you don’t have 50 migration projects. You have one modernization system to design.»

Taras Iaremkiv, CTO at Exoft

If you want to speed up modernization, rethinking your approach is the first step — but it’ll be effective only if you apply it to both strategy and execution:

• Strategy decides what gets modernized, in what order, and when. It also defines stakeholders, allocates resources, and ensures the project aligns with your risk tolerance. Without a roadmap and strategy for the whole portfolio, budgets and deadlines become unpredictable fast.
• Execution determines whether your teams will waste time and effort on repeated tasks. Running migration in parallel is also a time-saver, and it’s Microsoft’s recommended approach for portfolios of 5+ repositories.

Without a portfolio-wide roadmap and strategy, you spend a lot of time deciding which application to modernize next. Budget overruns and delays become mundane because it’s hard to predict both deadlines and costs. Modernization diverts resources from ongoing support, maintenance, new development, or other engineering priorities.

In a similar vein, without a portfolio-wide execution approach:

• Every application gets assessed separately, from scratch.
• Developers waste time implementing the same fixes across different repositories (e.g., replacing ASP.NET Web Forms).
• Senior engineers have to take on too many routine decisions instead of focusing on high-level tasks.

How to Accelerate .NET Modernization Across a Large Application Portfolio

You might be tempted to jump straight to automating migration tasks or incorporating AI into your workflows. But that’s only part of acceleration — and it won’t be the first step.

1. Assess the Portfolio Before Accelerating It

How will you know which apps to modernize first or where you can automate .NET Framework migration? Taking stock of your legacy applications first — that’s how.

The portfolio assessment is a two-part affair:

1. How critical is each application to your business operations? This knowledge will guide your roadmap priorities. It also opens the path to app rationalization (retiring or replacing certain applications).
2. How predictable and repeatable is modernization work? This knowledge will tell you how much dedicated effort each app will need. Here’s your checklist for assessing application criticality:

Category	What to assess
Business impact	Revenue Customer experience Impact on daily operations Compliance Downtime risk and tolerance
Technical complexity	Architecture Integrations Shared databases Dependencies No-longer-supported components
Modernization urgency	Security risks from not modernizing Unsupported technologies Infrastructure constraints Legacy maintenance costs
Modernization order	Dependencies in interconnected systems
Modernization disposition	App rationalization (modernize, replace, retire, consolidate, or retain?) Engineering effort required Expected modernization costs
Resources	In-house engineering capacity Budget Timeline

Use this analysis to organize migration waves. For example, AWS suggests five ways to do it:

• By migration strategy or technology stack
• By business domain
• By technical capability
• By environment
• By business priority

As for assessing the modernization work required, consider .NET Framework upgrade path predictability, similarity in dependencies or architecture, exceptions, and business criticality. Then, sort your apps into these five groups:

• Straightforward applications with known, predictable upgrade paths
• Groups of applications sharing similar dependencies or architecture
• Systems with recurring but known exceptions
• Highly coupled or business-critical systems requiring dedicated engineering attention
• Applications that may be better to retire or replace

Exoft’s experience: When we modernized a .NET Framework platform for a fitness club chain, we had to preserve the code that couldn’t be modified. Built in the early 2000s, the platform included services, modules, subsystems, and decades of data. So, we completed a full system audit before doing anything else to determine what could be modernized and what had to be left intact.

2. Turn Successful Modernizations Into a Reusable Playbook

What do you expect from a successful modernization? Your knee-jerk response is probably, “A modernized app that works.”

While it makes sense, that’s not the only thing you should focus on. You should also draw lessons from the modernization process itself. Those lessons become reusable knowledge on how to scale .NET modernization for the rest of the portfolio, saving your engineers time.

When you modernize multiple .NET Framework applications, a post-modernization review can reveal:

• What worked and what didn’t
• Where you ran into bottlenecks
• Which team or team member excelled at which tasks
• Which tasks would be better off delegated to technology partners
• Whether you need to adjust your budget or timeline expectations
• Which technical decisions can be reused for other apps

The latter can be a real time-saver since your engineers won’t have to solve the same problem over and over again. These repeated patterns make up 20% to 50% of an average enterprise application portfolio.

Here’s what you may be able to reuse:

• Dependency replacement mappings
• Recurring API transformations
• Configuration templates CI/CD templates
• Test and validation patterns
• Common remediation rules
• Architecture decisions
• Known exceptions and their solutions

For example, when Microsoft had to migrate around 300 projects to modern .NET, the team tested two AI-assisted approaches. They moved forward with the approach that supported concurrent conversions, as the other one was taking as long as manual conversions.

Source: Microsoft Dev Blog, Project burndown speed went below the target after introducing concurrently running AI scripts during Microsoft’s .NET modernization

3. Incorporate AI in .NET Modernization

Everyone knows that AI can generate code. But that’s not the only way AI can speed up enterprise application modernization. It can also help teams document and structure modernization knowledge — and put it to work through Claude agents with specific skills.

Of course, AI coding assistants can help developers complete specific tasks faster. But, as we covered in our AI-SDLC guide, AI is a real efficiency multiplier only if you deploy it across the whole process.

That’s why AI-assisted .NET modernization doesn’t equal AI-assisted coding. It means incorporating AI in assessment, planning, transformation, validation, and reusable knowledge management across multiple applications, too.

In fact, coding assistance ranks only fifth among AI use cases during app modernization:

Source: Red Hat 2024, Companies mostly use AI to optimize performance, reduce or eliminate manual work, and automate QA and testing during app modernization

In practice, AI can:

• Analyze application architectures, codebases, and dependencies and pinpoint similarities
• Identify incompatible APIs and packages
• Prepare migration plans based on existing knowledge
• Apply recurring transformations and conversions
• Generate or update test scenarios and scripts for automated testing
• Analyze build and runtime failures and identify possible root causes
• Document code changes and technical decisions

«Companies used to accept that a large legacy portfolio would take years to modernize. With the automation and AI tools we have now, I don’t think that should be the default assumption anymore.»

Oleg Maykher, CEO at Exoft

f

4. Parallelize the Modernization Program

You might believe that you must modernize one app after another, like so: App 1 → App 2 → App 3 → App 4.

That’s a misconception. You can modernize similar apps in parallel — but only after you know which applications can follow the same modernization process and which ones need special attention.

Under a portfolio approach, you run several streams in parallel:

• Automated/repeatable upgrade stream handles standardized upgrades that don’t need much manual work.
• Known-pattern modernization stream is dedicated to apps that require engineering effort but follow reusable modernization patterns.
• Complex engineering stream is the high-effort, low-automation one. It handles applications that need dedicated analysis or advanced problem-solving (e.g., to change enterprise application architecture).
• Validation/testing stream verifies that the work completed across three other streams meets quality standards.
• Retirement/replacement stream is meant for applications that are better off retired, replaced, or consolidated.

For example, Thomson Reuters increased .NET modernization velocity by 300% with agentic AI. Running multiple jobs in parallel was largely to thank for it.

Exoft’s experience: Our client needed to upgrade its B2B accommodation booking platform before entering the U.S. market, but a full rewrite was too risky. So, we gradually updated parts of the system, migrating smaller .NET Framework services to .NET Core in parallel with product development.

5. Don’t Ignore Testing

The number of code changes won’t ever reflect how successful migration was or whether the modernized application works as intended. So, track the number of safely migrated applications instead — and pay attention to testing.

Testing ensures nothing breaks post-modernization. Plus, keep in mind: if you can’t test and validate your code changes as fast as they’re written, deployment velocity can actually go down.

Here’s your testing and QA checklist for .NET modernization:

Type	Why it’s important
Automated builds	Reveals issues at the pre-build phase Ensures all validation steps are made in the right order on every build
Unit testing	Catches bugs and errors on the function level early on
Integration testing	Prevents system-wide issues because modules don’t interact as intended
Regression testing	Ensures code changes don’t break the existing functionality
Behavioral validation	Validates that the application meets end-users’ needs
Security checks	Maintains compliance, protects sensitive data, and prevents security weaknesses
Production-like testing (where appropriate)	Uncovers environment-specific issues, which helps prevent production downtime or performance bottlenecks
Human review for high-risk systems	Reduces risk in cases where the cost of failure is high

Exoft’s experience: When migrating a marketing campaign platform from .NET Framework 4.8 to .NET 8, we ran a delivery and feature validation process alongside code conversion. We also wrote integration and unit tests and improved CI/CD pipelines with trunk-based version control.

6. Measure Modernization Velocity

As DORA likes to remind us, if you set metrics as goals, teams can and will try to game them. You also shouldn’t make all your decisions based on a single metric.

These lessons apply to .NET modernization projects, as well. Yes, it’s important to track how many applications you’ve migrated. No, it shouldn’t be the only velocity metric on your to-watch list — and no, you shouldn’t use any of them as a goal in and of itself.

When chosen right, metrics help you see whether your modernization speed and capability are indeed improving. That’s the end goal: visibility.

So, track:

• Number of applications modernized per quarter
• Average cycle time per application
• Engineering hours spent per migration
• Size and rate of reduction of the legacy backlog
• Percentage of work completed using automation or reusable patterns
• Number of migrations that can run concurrently
• Build/test success after transformation
• Changes in the forecasted date for completing the portfolio

Where to Start If Your .NET Modernization Is Already Behind Schedule

Delays and cost overruns have slowly become business as usual? That doesn’t mean you have to just accept it. You can still save the project.

Here’s our playbook for doing exactly that:

1. Identify bottlenecks. First, you need to know where you’re wasting time. Too many approvals? Get rid of redundant ones. Not enough senior engineers? Hire technology partners with app modernization expertise.
2. Start small. Pick one group of applications with similar dependencies and complexity; don’t try to standardize everything in one go. Work out the repeatable path for this group.
3. Turn repeatable patterns into reusable assets. Review what worked for this group of applications and make it reusable. Common assets include dependency mappings, test patterns, migration rules, scripts, templates, and recurring fixes.
4. Add capacity if that’s the bottleneck. Sometimes, delays happen because your team is spread too thin between modernization and ongoing product work. In that case, consider turning to an external partner.

Speaking of external partners. Only about a third (34%) of organizations expect to handle modernization completely in-house. Most plan to hand over the whole project (31%) or some of its scope (35%) to external partners.

Source: Red Hat 2024, Only a third of organizations plan to handle application modernization completely in-house

Another report, this time by Ensono, sheds light on why companies turn to external partners during modernization: internal talent gaps. The most prevalent ones concern roles in cloud architecture and migration (27%), application modernization itself (19%), and cybersecurity (14%).

During .NET modernization, an IT outsourcing company can:

• Assess specific application groups
• Migrate repeatable or lower-risk applications
• Create reusable patterns and templates
• Automate tests and validation
• Update the infrastructure and CI/CD pipelines
• Provide extra .NET engineering capacity for parallel workstreams

Conclusion

If you treat every application as a separate modernization project, you’re missing out on tons of automation opportunities. That’s why the shift to a portfolio mindset — both in strategy and execution — has to come first.

Already made this first step and identified your key bottlenecks? Let’s remove them together. Exoft can take on a specific scope of work — CI/CD updates, test automation, application group migration — all while helping you speed up modernization with our experience-backed insights.