A shortlist in 72 hours, contributing inside two weeks, and a 30-day guarantee if the fit is wrong.
72-hour shortlist · 30-day replacement guarantee · Month-to-month
The Microsoft ecosystem went through a genuine break, and the hiring market still reflects it.
A developer whose experience is .NET Framework 4.x with Web Forms or older MVC, running on Windows and IIS, has real skills that transfer partially. A developer who learned on .NET Core and now .NET 10 works cross-platform, containerised, with a different configuration model, different dependency injection, and different deployment assumptions.
If you’re maintaining a Framework application, someone who has only worked in modern .NET will find the codebase alien. If you’re building new, someone rooted in Framework habits will write code that works and doesn’t fit.
The version question does not stop at the divide. Modern .NET alternates long-term and standard-term releases, and the difference is eighteen months of support against three years. Teams that default to the newest number end up upgrading annually on someone else’s schedule. For most line-of-business applications the current LTS is the right target, and it is worth being explicit about which release you are on before a candidate assumes otherwise.
We ask which side of that divide your codebase sits on before anything else. It matters more than years of experience.
Async/await used correctly, LINQ that doesn't quietly enumerate three times, and generics beyond the basics.
Middleware pipeline, dependency injection, configuration, and hosting model. The mental model differs meaningfully from Framework.
Knowing when EF is right and when it's generating something expensive. Change tracking is where most performance issues start.
Most .NET work lands on Azure. App Service, Functions, Service Bus, and Key Vault come up constantly.
xUnit or NUnit, plus integration testing. Enterprise .NET codebases without tests age badly.
If your work involves moving off Framework, having done it before is worth more than any other single factor.
The expensive .NET failure is a migration that stalls halfway.
It starts reasonably. The team agrees Framework 4.8 is a dead end and begins moving to .NET 10. Then they hit the parts that don’t port: a dependency with no .NET Standard version, WCF services with no direct equivalent, or System.Web assumptions threaded through the codebase. Progress stops with half the solution on each side. Now you maintain two build pipelines, two hosting models, and a team that has to hold both in their heads. This state is materially worse than either endpoint, and organisations stay in it for years.
The other recurring cost is Entity Framework change tracking. A developer loads ten thousand entities to update a field, EF tracks every one, and memory and CPU both spike. AsNoTracking, or a set-based update, turns a thirty-second job into under a second. It’s a one-line difference that a Framework-era developer who learned on smaller data sets often doesn’t reach for.
Someone who has completed a migration knows to inventory the blockers first — and will tell you in week one if the answer is that some of it should stay where it is.
The staffing problem tends to arrive before the technical one. The pool of developers willing to spend the next three years in Framework-era code is shrinking, and the ones who accept it increasingly price the tedium in.
Mid-level (3–6 years). Builds features against existing architecture. Comfortable with ASP.NET Core and EF. Needs direction on design decisions.
Senior (6–10 years). Designs services, makes persistence and hosting decisions, handles performance work and leads migrations.
Lead / Architect (10+ years). Owns architecture, makes platform decisions, handles the legacy strategy conversation with stakeholders.
ASP.NET Core APIs and web applications. The largest share of requests.
Framework to .NET 10 migration. Common, slow, and much easier with someone who has done it before.
Azure integration. Moving workloads to managed services, or building cloud-native from the start. Often alongside cloud and DevOps work.
Blazor. Growing steadily. Screen for it separately — it’s a different model from traditional web development.
Enterprise integration. Message queues, background processing, third-party system integration. See enterprise applications.
Windows-to-Linux hosting moves. Usually driven by cost and usually straightforward once the framework question is settled, though file paths, scheduled tasks, and anything touching the registry reliably surface late.
Week one. They get the solution building and the tests running, and identify the target framework of every project in it. On a mixed codebase that inventory is the most valuable artefact anyone can produce. Expect questions about hosting, how configuration and secrets are handled, and whether Azure resources are provisioned by hand or by template.
Weeks two to four. They ship a feature with tests, and if migration is the goal, they move one self-contained project and prove the pipeline end to end rather than starting with the hardest module. Expect them to flag an EF query doing something wasteful, or a synchronous call blocking a thread in an async path.
The warning sign is async/await used as decoration. Methods marked async that call .Result or .Wait() inside deadlock under load and are a reliable indicator that someone learned the syntax without the model. It is worth checking for explicitly in their first pull request.
Expect an early read on where the application is actually slow. In most .NET codebases of any age the answer is data access rather than application code — an N+1 pattern behind an ORM, or a query with no supporting index. A developer who profiles before optimising, and shows you the evidence, saves you more in month one than one who arrives with opinions about architecture.
Believing the migration is mostly mechanical. Project files and package references are the easy part. The work is in what has no modern equivalent — WCF, Web Forms, some third-party components — and that inventory should happen before anyone commits to a timeline. Teams that skip it are the ones who stall halfway.
Assuming Azure experience comes with .NET. Plenty of strong .NET developers have only deployed to IIS on a Windows server. If your workloads sit on App Service, Functions, and Service Bus, screen for it as a separate requirement rather than an assumed bonus.
Hiring a backend .NET developer and expecting Blazor. Blazor is C#, which makes it sound like a small step. It’s a component model with its own render lifecycle and two hosting models that behave very differently. Treat it as a distinct skill, the same way you’d treat React.
Postponing the framework decision indefinitely. Staying on .NET Framework is a legitimate choice when the application is stable and the business case for moving is weak. What costs money is refusing to decide — new work gets written to hedge both directions, developers who want modern experience leave, and the eventual migration is larger than it needed to be. Choose deliberately and write down the reason.
Rates depend on seniority, stack breadth, and engagement length. Tell us the role and we’ll give you a firm number.
Tell us the role and we will send a shortlist within 72 hours.
Tell Us the RoleTell us the role. Three to five profiles within 72 hours.