Legacy .NET modernization

Move from .NET Framework 4.8 .NET 10 without stopping the business.

Legacy Upsize modernizes the .NET applications your company already runs on. Incremental migrations, in production, with the lights on — no big-bang rewrite, no two-year freeze.

Two-week audit · fixed price · you keep the report either way

src/Services/OrderService.cs +4 −4
@@ Upsizing OrderService @@
<TargetFramework>net48</TargetFramework>
+<TargetFramework>net10.0</TargetFramework>
 
public class OrderService : WebService
{
    [WebMethod]
    public DataSet GetOrders() …
+public sealed class OrderService(AppDb db)
+{
    public async Task<List<Order>> GetOrdersAsync(
        CancellationToken ct)
        => await db.Orders.ToListAsync(ct);
}  // last meaningful commit: 2014
+}  // tested, deployed, still serving traffic

Build output: 5 warnings, 0 errors. For now.

Legacy apps rarely fail loudly. They accumulate warnings until one of them becomes an outage, an audit finding, or a hiring problem.

  • warning LU001: TargetFramework 'net48' has received no new features since 2019 — security fixes only.
  • warning LU002: 14 dependencies were last published before their maintainers changed careers.
  • warning LU003: The only person who understands 'OrderProcessor.vb' retired in 2022.
  • warning LU004: Deployment requires Remote Desktop, a 14-step checklist, and a Saturday.
  • warning LU005: "It works, don't touch it" is not a supported architecture.

We turn this list into a migration plan with effort estimates — then execute it.

Migration paths

What we upsize, and to what.

ASP.NET WebForms Blazor or ASP.NET Core MVC
WCF services gRPC & minimal APIs (CoreWCF when contracts must stay)
.NET Framework 2.0–4.8 .NET 10 LTS
VB.NET C#
Entity Framework 6, DataSets, raw ADO.NET EF Core
Windows Services + MSMQ Worker Services + Azure Service Bus / RabbitMQ
Hand-fed IIS on aging Windows Server Azure App Service or containers, with CI/CD

Something else in the solution? WebForms hiding COM interop, ClickOnce installers, SSRS, classic ASP in the same site — we've seen it. Ask.

Process

Strangler fig, not big bang.

The old application keeps serving traffic while we migrate it slice by slice. Order matters here — each step de-risks the next.

  1. Assess

    A two-week portability audit: every project, dependency, API surface, and database call. You get a written migration plan with effort ranges — useful whether or not you hire us for the rest.

  2. Stabilize

    Characterization tests and CI around what the system does today, before anything changes. If nobody can say what "correct" means, we pin down current behavior and call that the contract.

  3. Migrate

    Side-by-side, one vertical slice at a time. A reverse proxy routes traffic between old and new, so every slice ships to production the week it's finished — and can be rolled back the same day.

  4. Modernize

    Once behavior matches, we spend the dividend: performance, cloud cost, observability, and a codebase your next hire can actually work in.

Bring us your worst .sln

A 30-minute call. Tell us what it runs on, what it's blocking, and what you've been afraid to touch. We'll tell you honestly whether it's worth migrating — some apps aren't.

Start the conversation