Technology
Bring your .NET system up to date, one route at a time
Most .NET estates mix .NET Framework code, WCF services and data access written for a smaller load. We move them to modern .NET behind a reverse proxy, fix what slows them down and keep every step reversible.
- Duration
- 4 to 12 weeks per stage
- Model
- Staged programme
- Output
- Measured services on modern .NET
Signs you need this
Each of these can be seen in the code, the logs or a dashboard.
- Part of the system still runs on .NET Framework and IIS, so it cannot move to Linux containers with the rest.
- WCF services sit in the middle of key flows, and nobody wants to change their contracts.
- Under load, response times jump while CPU stays low, and
.Resultor.Wait()calls are spread through the code. - One page sends dozens of queries, or one EF query returns far more rows than the screen shows.
- Background work runs in
Task.Runinside web requests and disappears when the process recycles. - Every project references every other, so a change in billing breaks the build in reporting.
- There are logs but no traces, so nobody can follow a slow request from the API to the database.
Why .NET systems stall, and why a rewrite rarely helps
A .NET system seldom slows down because of the language. It slows down because of habits that were harmless at a smaller load: blocking on async calls, lazy loading in loops, one DbContext shared by every feature, work hidden in web requests. Moving that code to a newer runtime unchanged moves the problems too.
The usual answer is a rewrite on the latest version. It freezes feature work for months while the old system keeps changing. We take the incremental route: a reverse proxy such as YARP sits in front of the old application, routes move to modern .NET one at a time, and the System.Web adapters share authentication and session while both sides run. Any route can go back to the old code with a routing change.
This service covers the engineering inside .NET. When the question is wider, such as which parts of a mixed estate to modernise first, System Modernisation is the programme around it.
What is included, and what is not
Included
- Upgrade path from .NET Framework to the current long-term support (LTS) release
- Incremental routing through YARP, with shared authentication during the move
- Replacement plan for WCF, Web Forms, .NET Remoting and other Framework-only APIs
- EF and EF Core query review: N+1 patterns, change tracking, split queries, indexes
- Async review, with blocking calls removed and thread-pool behaviour measured under load
- Background jobs moved to hosted services or a queue, with retries and idempotency
- Module boundaries checked in the build, Linux container images, OpenTelemetry
Not included
- Porting the system to another language
- Upgrading desktop clients built with WinForms or WPF
- Visual redesign of existing screens
- Running the system in production after handover
How the work runs
- Weeks 1 to 2Map the estate. With read-only access to repositories, pipelines and dashboards, we list every project, target framework and Framework-only API in use. Hot paths are measured under real load, so the upgrade order follows risk.
- Weeks 2 to 4Put the proxy in place. A YARP proxy goes in front of the old application, with a modern .NET host beside it. At first every request passes straight through, and OpenTelemetry traces cover both sides.
- Weeks 4 to 12Move route by route. Routes, services and jobs move in small groups, each behind a switch and compared with the old behaviour before traffic shifts. Query and async fixes ship in the same pull requests, measured before and after. Every stage ends with a working system.
- ThroughoutKeep access narrow. Access is read-only by default. Any write access needed to ship changes is removed when the stage ends.
What you get
All outputs belong to you: code, reports, diagrams and their source files, kept in your repositories.
When this is not the right service
- Systems due to be retired within a year or two. Keeping them on .NET Framework 4.8, still supported as part of Windows, costs less than moving them.
- Teams that have already chosen a full rewrite in another stack. We move and improve .NET code rather than replace it.
- Slowdowns that are not specific to .NET, such as an undersized database. Performance and Scalability looks across the whole stack.
Frequently asked questions
Which .NET version should we target?
Usually the current LTS release. A new LTS arrives every two years with three years of support, so builds and tests are set up to make the next upgrade routine.
What happens to our WCF services?
It depends on who calls them. Internal services usually move to gRPC or plain HTTP APIs. Services whose external callers cannot change can run on CoreWCF, the open-source port of WCF’s server side to modern .NET.
Can we keep shipping features during the upgrade?
Yes. The old application keeps serving every route that has not moved, and new features can go straight to the new side. If a moved route misbehaves, the proxy sends it back.
How much of our team’s time does it take?
Your engineers review and merge every change and pair with us on the first routes, so the pattern becomes theirs. For longer programmes, an embedded architect works with the team 2 to 3 days a week.
What happens after a stage ends?
You keep the code, decision records and runbook, and any write access is removed. Your team can move the remaining routes with the same pattern, or plan the next stage with us.
Start with a short technical conversation
Thirty minutes. You describe the .NET system, and the architect who would run the work tells you where we would start.