How to Choose a
.NET Modernization Partner

By Sukhpinder Singh – .NET Technical Architect, SourceFuse

In a Nutshell: Choosing a .NET modernization partner is a delivery-risk decision, not a credentials decision. The seven questions below on dependency mapping, modern.NET migration depth, non-linear migration paths, day-two operations, MAP/MMP funding, named delivery teams, and how a partner behaves when things go wrong separate partners who have done your migration many times from those selling a slide deck.

Twelve months in. One application migrated. Three are behind schedule. Four have not started. $3.2 million already spent. That is not a cautionary hypothetical; it is a conversation I have had, more than once, with a CTO who did everything right. They ran a competitive process. They shortlisted credentialed partners. They checked references. And they still ended up on the phone asking someone else to finish what a well-known firm had started.

Here is the uncomfortable pattern behind stalled modernizations: the technology is rarely what sinks them. The partner is.

Every partner looks credible on paper. AWS certifications, a deck full of logos, and case studies that sound compelling. The problem is that a credential is a threshold, not a predictor. It confirms a partner has done serious work; it says nothing about whether they have done your migration, at your scale, recently enough for it to count.

The seven questions below are the ones our architects and practice leads ask when we vet a subcontractor or technology partner.

Question 1: Show me your dependency-mapping process before you touch a single line of code

This is the question that separates engineers from salespeople.

Every .NET Framework application has dependencies that nobody documented. Third-party libraries compiled against specific framework versions. COM interop components buried in production. Windows Registry calls nobody remembers writing. Internal NuGet packages were last updated in 2014. GDI references for image manipulation with no direct modern .NET equivalent.

A partner who starts writing code before mapping all of this will spend the next six months discovering surprises on your budget and your timeline.

At SourceFuse, discovery comes before we move a single file. In the Discovery phase, we use AWS Transform, the AWS agentic code-transformation service, to analyze the legacy codebase, generate 4+1 architecture view models, map dependencies, and extract a migration backlog, with Claude producing the supporting architecture documentation. This compresses what used to be a multi-week manual discovery exercise into a days-long automated analysis, so the estate is understood before kickoff, not in week eight.

On a recent engagement, this discovery surfaced two dozen undocumented dependencies in an application the client’s own team believed they knew inside out. Several had no clean modern .NET equivalent and needed custom replacements. Because we found them up front, we built them into the plan instead of into the overruns.

Question 2: How many .NET Framework-to-.NET 10 migrations have you completed in the last 18 months, and can I speak to the engineering lead on one?

The engineering lead will tell you what the sales team won’t, that is, how often scope changed, whether the timeline held, what they actually found in the codebase, and how support worked after go-live.

Then test currency. The .NET release train moves every November, alternating long-term-support (LTS) and standard-term-support (STS) versions, and LTS releases get three years of patches (Microsoft .NET support policy). That cadence has a consequence a lot of proposals haven’t caught up to: as of 2026, .NET 10 is the current LTS, supported through November 2028, while .NET 8 and .NET 9 both reach end of support on November 10, 2026 (Microsoft Lifecycle). This is exactly why SourceFuse recommends .NET 10 as the default migration target. It gives you the longest support runway and avoids a second forced upgrade within months of go-live. A partner still defaulting to “.NET 8” would land you on a runtime that is already in its final months of maintenance. So ask which LTS they migrate to and why, and if the answer isn’t .NET 10, ask what justifies the shorter runway.

CASE STUDY – Tuned Global | Technology, Information & Media

33% lower database operating costs · 10x ingestion capacity · 25% less DevOps friction

Migration from Microsoft SQL Server to Amazon Aurora PostgreSQL Serverless, decoupling compute from storage for elastic scale. ~2,000 SQL queries rewritten and schema converted via AWS SCT, with a controlled cutover using AWS DMS and Change Data Capture. ETL was re-platformed from SQL Server Agent jobs to serverless AWS Glue; ingestion scaled from 2M to 20M+ tracks/day, absorbing bursts of 10M+ API calls.

Question 3: Walk me through what happens when .NET Framework-to-.NET 10 is not a straight migration

This question has two right answers and many wrong ones.

Applications using Windows Workflow Foundation have no direct equivalent. WCF services in complex configurations do not port cleanly. ASP.NET WebForms simply do not exist in .NET 10. And applications with heavy SQL Server stored-procedure dependencies, often 80-95% of the business logic sitting in the database layer, require a strategy decision that goes beyond framework migration.

We have walked into engagements where the right answer was to split a monolith before touching the framework. One financial-services client had roughly 95% of business logic in SQL Server stored procedures, a pattern we see repeatedly. We moved that logic to API layers first, then handled the framework migration as a separate phase. It changed the timeline but produced a far better outcome than forcing a big-bang approach.

On another engagement, a global fintech running .NET Framework 3.5 MVC, the application relied on an Excel COM library whose vendor had gone out of business. No .NET Core equivalent existed, so we rebuilt it. That is the kind of situation a partner with real .NET depth has a plan for. A partner who has not seen it does not.

Question 4: What does your day-two operations model look like after go-live?

Most enterprises think about the migration. Almost nobody thinks about the morning after.

Day-two is when your application is running on .NET 10 on AWS, and the migration team has left. Who monitors it? Who handles the first production incident? How does your team get upskilled on a modern .NET codebase after a decade on framework apps?

Partners who end the conversation at go-live have not finished thinking about the project. The gap between a migration team and a separate ops team creates a specific failure mode: the people who understood your codebase deeply are gone, and the people now responsible for it were not there when the decisions were made.

At SourceFuse, NYX, our multi-agent AIOps platform, built on LangGraph and LangChain, handles day-two for modernization clients, and it is configured during the migration engagement itself, not bolted on afterward. NYX reasons across Jira, GitHub, Kubernetes, security scanners, cloud billing, and observability tools to deliver natural-language root-cause analysis and remediation guidance. By go-live, monitoring, alerting, and automated remediation are already in place, informed by migration-phase knowledge. In production, NYX clients see MTTR fall from hours to minutes against SLA-driven availability targets of 99.99%.

Question 5: How do you handle AWS MAP and MMP funding, and what is your track record with it?

AWS’s Migration Acceleration Program (MAP) and the Microsoft Modernization Program (MMP) exist specifically to reduce the cost of moving off legacy Microsoft platforms to cloud-native and open-source targets. The programs and partner tiers are verifiable on AWS’s partner site. Most enterprises don’t know they qualify, and some partners skip the paperwork because it slows the sale. That gap is either money left on the table or money in your budget, depending on who you hire.

CASE STUDY – Service Stream | Essential Infrastructure (Australia)

15% lower annual AWS spend · 20% faster migration · near-zero downtime

Migration from VMware Cloud on AWS to a fully AWS-native environment on Amazon EC2, eliminating VMware platform overhead and Windows Datacenter licensing exposure ahead of Broadcom licensing changes. Dependency-aware migration waves planned with AWS Transform for VMware; near-zero-downtime cutover via AWS Application Migration Service (MGN), followed by workload right-sizing for cost optimization.

Question 6: Who specifically will be on my engagement and can I meet them before we sign?

The industry practice of pitching senior architects and delivering junior developers is well known and widespread. In a migration that requires deep framework knowledge, architectural decision-making, and real codebase archaeology, the difference between a principal architect and a mid-level developer is measured in months of timeline and percentage points of cost overrun.

Ask specifically about who the technical lead on this engagement is? What migrations have they led as the primary architect? Can I meet them in a technical call before contract signature? At SourceFuse, named architects are put on every engagement and introduced before the contract is signed; the ease with which a partner accommodates this request is informative in itself.

Question 7: Tell me about a project that didn’t go to plan and what you did in the first 48 hours.

Every partner has success stories. The stories of what happened when things went sideways reveal how a partner actually behaves under pressure, which is the environment you will be in when your project hits a problem. And every migration project hits a problem.

We have had projects where our estimates were wrong. On one fintech engagement, the core processing application depended on a Windows COM Excel library whose vendor had ceased operations. No modern equivalent existed, so we rebuilt it from scratch. It added six weeks. We absorbed part of the cost because our estimation should have caught it during discovery, and we were transparent about it from day one. That client has been with SourceFuse for three years.

On another engagement, a client’s team was building feature enhancements on the old codebase while we migrated modules, so we had to synchronize delta changes almost monthly. The lesson: scope the client team’s BAU activity before you agree to a migration timeline, not after.

Key Takeaways

• Evaluate for delivery risk, not credentials. Premier status is a threshold, not a ranking.
• Insist on the engineering lead, named architects, and a meeting before you sign.
• Demand discovery before code, a plan for non-linear migrations, and a day-two operations model.
• Confirm MAP/MMP fluency; funding can offset 20-40% of the cost.
• The partner who hesitates on Questions 3 and 7 is telling you more than the proposal does.

Ready to start the evaluation?

SourceFuse offers a free Application Modernization Discovery Sprint (2-4 weeks). We map your estate with AWS Transform, surface the dependencies nobody documented, and hand you a migration roadmap with cost modeling before you commit to anything.

Related reading: Application Modernization | Database Modernization | Accelerators & Agents

Frequently Asked Questions

About the Author

Sukhpinder Singh is a .NET Technical Architect at SourceFuse with over 12 years of experience architecting, debugging, and modernizing large-scale .NET applications on AWS and Azure. He has successfully delivered 50+ application migrations, helping organizations improve scalability, reduce latency by nearly 50%, and lower infrastructure costs by around 30%. Sukhpinder also contributes to AI-assisted development initiatives and actively shares his expertise through technical communities, including HackerNoon, Medium, and GitHub.