Article
How to Choose a .NET Modernization Partner: The Questions That Actually Matter
Most vendor pitches for legacy modernization sound similar - "proven process," "seamless migration," "minimal disruption." None of that tells you whether a partner can actually deliver on a system that's been running your business for a decade. Here's what to actually ask before you sign anything.
"Walk me through how you'd assess our system before proposing a timeline or a price"
If the answer is a generic phased-migration slide deck rather than a description of an actual assessment process, that's a signal. A legacy system that's been running for years - especially one with thin or missing documentation - can't be scoped honestly from a sales call. The first real deliverable in a serious engagement is an assessment: what's actually in the system, what it depends on, and where the real risk sits. Timelines and cost estimates that come before that step are guesses dressed up as commitments.
"What happens if something breaks after go-live?"
This is really a question about how cutover is handled. A vendor that plans a single, all-at-once cutover is accepting a level of risk you probably shouldn't accept on their behalf. Ask specifically whether they run the new and legacy systems in parallel before switching over, and whether cutover happens in stages (database, then services, then frontend, for example) rather than as one leap. Phased, validated cutover costs more calendar time. It's also what keeps a mission-critical system running while it's rebuilt.
"Show me a system you've modernized that was in a similar state to ours"
Not a polished demo - the actual starting condition. Was there documentation? Was it a single monolith or already loosely coupled? Undocumented, decade-old systems require a fundamentally different approach than ones with clean specs. A partner who's only ever worked on well-documented systems may not have dealt with the harder, more common reality: inheriting code nobody currently at the company wrote.
"What's your position on rewriting everything versus modernizing incrementally?"
Be suspicious of a vendor whose default answer is always "rewrite." A full rewrite is sometimes the right call, but it's rarely the first option a responsible partner should reach for on a system that's actively running the business - the risk of a big-bang rewrite is that you're betting the whole outcome on one delivery, instead of de-risking it in stages.
"Who exactly will be doing the work, and for how long?"
Modernization engagements that span months need continuity, not a rotating cast of names. Ask who your actual point of contact is, whether the same engineers stay on the project end to end, and what happens if key people roll off partway through.
"What technology are you actually comfortable modernizing away from?"
A vendor who can list specific legacy stacks they've worked with - old ASP.NET Forms applications, deprecated browser-plugin frontends, aging SQL Server databases, legacy APIs - is speaking from experience rather than a generic pitch. If they can't name the technology, they probably haven't touched it.
What this looks like in practice
None of this is about finding the cheapest quote or the fastest promised timeline. It's about finding a partner whose process assumes your system is going to surprise them - because it will - and who has a real answer for how they de-risk that, rather than a slide that says "seamless."
If you want to see what an actual assessment looks like before committing to anything, that's the right first step - not a full engagement, just an honest look at what you're working with.
Request a Legacy System Assessment