Service

.NET modernization without the big-bang rewrite

Most legacy systems are not broken. They run the business every day, they hold twenty years of rules nobody wrote down, and they are getting harder to change, deploy and staff. A VB6 front office, a WinForms desktop tool, a set of WCF services on .NET Framework 4.x: each still works, and each now costs more to keep than it should.

The usual answer is a full rewrite. It is also the usual way these projects fail: two years of parallel work, a second system that never quite catches up with the first, and a business that loses patience before the switch-over. We take a different route.

The problem we solve

• Desktop applications in VB6 or WinForms that only one or two people still understand.
• WCF and ASMX services that block a move to containers, Linux hosting or the cloud.
• .NET Framework code that cannot take current security patches, libraries or tooling.
• Business logic buried in forms, stored procedures and batch scripts, with no tests around it.
• A release process that needs a specific build machine and a long checklist.

Our approach: one module at a time

We use the strangler-fig pattern. A thin routing layer sits in front of the old system, and new .NET 10 services take over one capability at a time: pricing first, say, then accounts, then the nightly batch. Each step ships to production on its own, and the old code for that capability is switched off only when the new one has proven itself on real traffic.

That keeps the risk small and the progress visible. The business keeps its roadmap, users see improvements every few weeks instead of at the end, and if priorities change halfway through, everything already delivered is still in use.

• Characterize before changing. We wrap existing behaviour in tests first, often by recording real inputs and outputs, so the new code matches what the business actually depends on, including the odd cases.
• Move the logic, not just the screens. Rules come out of forms and procedures into plain, testable C# services with clear APIs.
• Keep the data honest. Schema changes are done in small, reversible migrations, and the old and new systems can read the same database while both are live.
• Modern delivery from day one. Every new service gets automated builds, tests and repeatable deployments, so the new platform is easier to change than the one it replaces.

What an engagement looks like

1. Assessment, one to three weeks. We read the code, map the modules and their dependencies, find where the business rules live, and rank the pieces by value and risk. You get a written migration map with a recommended first slice, an estimate, and the risks we see. It is useful on its own, even if you do the work in-house.

2. First slice, four to eight weeks. We migrate one meaningful capability end to end: routing layer, new service, tests, deployment and switch-over. This sets the pattern and proves the approach on your system rather than on slides.

3. Steady migration. We continue slice by slice, at the pace your team and budget allow, with a written status every week and working code in your repository. Your developers can work alongside us, and the patterns are documented so they can carry on without us.

Technology we work with

On the legacy side: VB6, WinForms, WPF, ASP.NET Web Forms and MVC, WCF, ASMX, COM interop, Crystal Reports and SQL Server stored-procedure-heavy designs. On the modern side: .NET 10, ASP.NET Core minimal APIs and controllers, worker services, Entity Framework Core and Dapper, SQL Server, Docker, and CI pipelines on whichever platform you already use. When the user interface has to move too, we can rebuild it in Angular, React or WPF.

A recent example

At a global investment bank, we helped retire a long-running VB6 platform onto .NET, REST APIs and SQL Server. The work included the Windows worker-service scheduling platform that produces time-critical NAV files and batch reports, where a late or wrong file is not an option.

Is this a fit?

It usually is if the system is important, the team that built it has moved on, and a full rewrite feels too risky or too slow. It is less of a fit if the application is small enough to replace with an off-the-shelf product, or if nobody in the business can tell us what it is supposed to do. We will say so in the assessment.