Software Development
How to Evaluate a .NET Modernization Partner
Two dates matter if your business runs on .NET. Microsoft’s support policy lists .NET 8 and .NET 9 both reaching end of support on Nov. 10, 2026, and .NET 10, the current long-term support release, supported through Nov. 14, 2028. Applications on .NET Framework 4.6.2 and later follow a different clock: support tracks the Windows version they run on.
For a lot of mid-market companies that means a line-of-business application written years ago, patched continuously, and now sitting on a runtime that will stop receiving security fixes within weeks or a few years. The decision to modernize is usually not hard. The decision about who does it is, because most firms that bid on this work describe it the same way and their differences only show up after the kickoff call and initial investment.
What we have created is a method for telling them apart before you sign. We deliberately chose to create a scoring method, rather than release a stack ranked list of companies, because the right partner depends on your application, your team, and your tolerance for disruption. To use it, simply score your candidates against the eight criteria, weigh them for your situation, and note those that rise to the top.
First, Know Which Project You Are Buying
“Modernization” covers three very different projects, and a partner who does not ask which one you need is already a yellow flag.
| Project | What it is | Typical shape | When it fits |
|---|---|---|---|
| Runtime upgrade | Move from .NET Framework or an older .NET to .NET 10, keep the architecture | Weeks to a few months; mostly compatibility work and testing | The application does its job; you need supported runtime and security patches |
| Incremental re-architecture | Upgrade the runtime and carve out the parts that hurt (a monolith module, a brittle integration, a reporting layer) one at a time, side by side with the live system | Months, delivered in slices that each ship | The application works but specific parts block the business; you cannot afford a freeze |
| Rewrite | Replace the application | A year or more; a second system running in parallel | Rarely. Usually only when the domain has changed so much the old model is wrong |
Most mid-market applications can benefit from the first or second modernization method. Partners who lead with the third are often selling the project they prefer to build rather than the one you need. Rewrite projects fail at a rate that should make everyone pause; roughly 70% fail to meet the budget, be delivered on time, or just outright fail to be completed. If a candidate proposes a rewrite, ask them to make the case for the incremental path first and explain why it does not apply. (For what the incremental path looks like in practice, see modernizing legacy systems without a rewrite.)
The Eight Criteria
For each criterion: what to ask, what a good answer sounds like, and what a weak one sounds like. Assign each a score from 1 to 5.
1. They Start With the Business, Not the Codebase
Ask: “What do you need from us before you can estimate?”
Good: They want to talk to the people who use the application daily, understand which workflows are revenue-critical, and see how the application fits into the rest of your systems. The code review comes second.
Weak: They ask for repository access and promise a quote in a week. A quote built only from code will likely miss the integration nobody documented and the critical report the CFO runs every Friday.
2. They Propose an Assessment Before a Fixed Price
Ask: “Will you give me a fixed price for the whole project today?”
Good: A short, fixed-price assessment first (two to four weeks), producing an inventory of what exists, a risk list, and a phased plan with estimates per phase. They explain that pricing the whole thing before the inventory is guessing.
Weak: A confident fixed price for the whole migration based solely on a singular discovery call. Bonus points if it’s delivered within a couple of hours of said call. Either they are padding heavily or the number will move later, and both will cost you.
3. They Have an Incremental Delivery Strategy
Ask: “How do we keep running the business while this happens?”
Good: They describe running old and new side by side, routing specific functions to the new system as each is ready, and keeping a rollback path at every step. They can name what ships in the first thirty days.
Weak: A long build followed by a cutover weekend. Ask what happens if the cutover fails on Monday morning.
4. They Have a Plan for Code With No Tests
Ask: “Our application has almost no automated tests. How do you know you have not broken something?”
Good: They expect this. They talk about characterization tests that capture current behavior before changing it, parallel runs comparing outputs, and which workflows they will test by hand with your staff. They treat your users’ knowledge as part of the test plan.
Weak: “We will add tests as we go.” This approach points towards a hopeful mindset, but it is not a plan.
5. They Inventory Integrations and Data Before Touching Code
Ask: “What is the first artifact we will see from you?”
Good: Provides an inventory: every database, scheduled job, file drop, EDI feed, reporting service, authentication dependency, and third-party API the application touches, with an owner for each. Integrations that aren’t identified before the work begins often lead to unpleasant surprises for mid-market enterprise application users.
Weak: Prepares a project plan with phases and dates, but it doesn’t include a list of what the application is connected to.
6. They Leave Your Team Able to Run It
Ask: “What does our team know how to do when you leave?”
Good: They are comfortable with the idea that you might not need them afterward. Documentation is written during the project, not after; your developers paired on the work (if you have them); a runbook for deployment and recovery; a defined handover.
Weak: Seems uneasy when speaking of their handoff and documentation practices. Vague references to “knowledge transfer at the end,” or a support contract positioned as the only way to keep the lights on.
7. Their Pricing and Rates Are Legible
Ask: “How do you price, what are your rates, and what changes the number?”
Good: Gives you a plain answer. Fixed price for the assessment, phased pricing for the build with the assumptions written down, hourly rates stated, and a clear statement of what triggers a change order. Some firms publish typical ranges on their website; that transparency is a good sign.
Weak: Pricing that only exists in a proposal, cannot be explained in a sentence, or shifts depending on who you talk to.
8. They Can Tell You About a Project That Went Wrong
Ask: “Tell me about a modernization that did not go to plan and what you did.”
Good: A specific story, told without blaming the client, ending in what they changed in their process. Every firm doing this work has one.
Weak: “That has not really happened to us.” Either they have not done much of this or they are not going to be honest when it happens to you.
The Scorecard
These weights are a starting point. If you have an in-house developer, raise the weight on criterion six. If your application has heavy integrations, raise five. If budget certainty matters most, raise two and seven.
| Criterion | Weight | Why it predicts outcomes |
|---|---|---|
| 1. Business first | 10% | Scope misses come from unknown workflows, not unknown code |
| 2. Assessment before fixed price | 15% | Estimates built on an inventory hold; estimates built on a call do not |
| 3. Incremental delivery | 15% | Reduces the cost of being wrong at any single step |
| 4. Testing strategy for untested code | 15% | The leading cause of post-migration defects |
| 5. Integration and data inventory | 15% | Where the budget surprises are |
| 6. Team capability at handover | 10% | Determines what the engagement costs you after it ends |
| 7. Pricing transparency | 10% | Correlates with how change orders are handled later |
| 8. Honest failure story | 10% | Predicts communication quality when something slips |
Multiply each score by its weight and compare totals. A candidate who scores poorly on criteria two, three, and four together is a risk regardless of the rest. Those three are the project; everything else is the relationship.
Red Flags That Override the Score
- A proposal to rewrite from scratch without first making the case against an incremental path.
- A fixed total price delivered before anyone has looked at the integration inventory.
- No mention of rollback, parallel running, or what happens if cutover fails.
- A support contract presented as mandatory rather than optional.
- Nobody on the proposed team has shipped a .NET Framework to modern .NET migration specifically. The compatibility work is its own specialty.
- A sales conversation that uses the word “AI” more than the word “users.”
Questions for the First Call
If you only have thirty minutes, these five cover most of the scorecard.
- What would you need to see before you could estimate this, and how long would that take?
- How would you keep our business running while the work happens?
- Our application has few tests. How do you know you have not broken something?
- What will our team be able to do without you when this is done?
- Tell me about a modernization that went sideways.
One More Thing to Ask Yourself
Which of your people will own this project internally? A good partner makes that person’s job easier and leaves them more capable. A weak one makes them a go-between. If you cannot name the person, that is the first thing to fix.
Where to Start
If you are weighing partners now, or weighing whether the November date matters for your application, we are happy to be scored against this list. We start with a short, fixed-price assessment that produces the inventory, the risk list, and a phased plan you can take to anyone, including a competitor. See how we approach custom software and modernization, or book a discovery call.
Newsletter
Subscribe to newsletter
Subscribe to receive the latest blog posts to your inbox every week.
