A UK-based financial services firm had been running its client portal on .NET 4.5 since 2012. The framework was end-of-life. Security patches had stopped. Performance was degrading. And the team couldn't integrate any modern tooling without hitting compatibility walls. Infomaze migrated the entire platform to .NET 8 — live, in production, without a maintenance window.
— The Situation
The client managed pension administration and investment tracking for mid-market funds across the UK. Their portal — built in ASP.NET WebForms on the .NET 4.5 framework — had been running quietly since 2012. For years, it worked. Then the problems started compounding.
Microsoft ended mainstream support for .NET Framework 4.5 in 2016. Extended support ended in 2022. By the time the client came to Infomaze, they were running financial software on a framework with no security updates, no compatibility with modern NuGet packages, and no path to containerisation or cloud-native deployment. A compliance audit had flagged the platform as a risk. Their insurers were asking questions.
The harder constraint was operational. The portal handled live client data — fund valuations, transaction histories, compliance reports, document storage. It processed over 2,000 authenticated sessions per day. A traditional lift-and-rewrite behind a maintenance window wasn't an option. Any planned outage during business hours would have breached their SLA with fund managers. The migration had to happen under live load.
.NET 4.5 had received no security updates since 2022. A vulnerability discovered today would remain unpatched indefinitely.
Every third-party library the team needed — from modern authentication providers to reporting SDKs — required .NET 6 or above. Integration was structurally blocked.
Report generation on the old stack was taking 8–14 seconds under concurrent load. Users were abandoning sessions. Support tickets had tripled in 18 months.
The client wanted to move to Azure App Service. ASP.NET WebForms and legacy HTTP modules are incompatible with the containerised hosting model.
ASP.NET FormsAuthentication — the login mechanism — is not supported in .NET Core. The entire auth layer needed replacing with a modern identity stack.
FCA-adjacent compliance requirements for data handling and infrastructure were increasingly difficult to satisfy on a deprecated framework.
— Migration Architecture
The answer to "how do you migrate a live finance portal without downtime" is: you don't migrate it all at once. Infomaze used the strangler fig pattern — a well-established technique where the new system is built around the old one, traffic is progressively routed to the new stack, and the legacy platform is retired module by module rather than replaced in one go.
The migration ran across six defined phases. Each phase delivered a fully deployable increment. At no point was the old system taken offline before its replacement was live and verified in production.
| Phase | Scope | Approach | Status | Traffic Split |
|---|---|---|---|---|
| 01 | Infrastructure & Reverse Proxy | YARP router deployed, both stacks live | ✓ Done | |
| 02 | Data Access Layer | EF Core replacing legacy LINQ-to-SQL | ✓ Done | |
| 03 | Authentication Layer | FormsAuth → ASP.NET Core Identity + JWT | ✓ Done | |
| 04 | API Services | WebForms code-behind → minimal API endpoints | ✓ Done | |
| 05 | UI Layer (Razor Pages) | WebForms .aspx → Razor Pages, migrated screen-by-screen | ✓ Done | |
| 06 | Legacy Decommission | Old IIS host retired, Azure App Service live | ✓ Done |
— Technical Deep Dive
The first move was infrastructure, not code. Infomaze deployed Microsoft's YARP (Yet Another Reverse Proxy) in front of both the legacy .NET 4.5 application and the new .NET 8 application. This meant both systems ran simultaneously on the same production load. YARP routed traffic to the old system by default — the new system received zero traffic until each migrated module was verified.
This was the architectural foundation that made zero downtime possible. At no point did users hit a maintenance page. Route-by-route, the traffic weight shifted from old to new as each module passed production verification.
// YARP route config — initial stateThe legacy application used LINQ-to-SQL — a data access technology that shipped with .NET Framework 3.5 and is not available in .NET Core. Before any UI or API work could begin, every data interaction needed to be rewritten using Entity Framework Core, which is the .NET 8-native ORM.
This was not a mechanical rewrite. The legacy data model had 14 years of accumulated schema decisions — nullable columns that behaved as flags, stored procedures called from both application code and scheduled SQL jobs, and a handful of LINQ queries with subtle ordering dependencies that affected pagination logic. Each query was audited, documented, and rewritten with the EF Core equivalent, then run in shadow mode against the live database before replacing the legacy version.
Shadow mode testing: the new EF Core queries ran against a read replica of the production database for two weeks, with outputs compared to the LINQ-to-SQL results on every request. Zero discrepancies before the switch was made.
This was the most technically demanding phase of the migration. ASP.NET FormsAuthentication — the login and session mechanism used by the legacy portal — is completely removed in .NET Core. There is no compatibility shim. The replacement had to be built from scratch using ASP.NET Core Identity, with JWT tokens for API calls and a session bridge to allow users already authenticated on the old stack to continue without re-login.
The team built a token exchange endpoint: when a user with a valid FormsAuth cookie hit the YARP router, the proxy called the exchange endpoint, which validated the legacy cookie against the old session store and issued a new JWT. From the user's perspective, nothing changed. The session lived on without interruption.
ASP.NET WebForms mixes UI markup and server-side logic in .aspx and .aspx.cs code-behind files. Neither can be ported to .NET Core — the WebForms rendering pipeline doesn't exist in the new runtime. The team decomposed each WebForms page into its constituent logic: data fetching, business rules, validation, and presentation. The logic became minimal API endpoints. The presentation became Razor Pages.
Rather than rewriting all 47 pages at once, the team prioritised by traffic. The six highest-traffic pages — dashboard, fund summary, transaction history, document download, account settings, and the report generator — were migrated in the first sprint. Each completed page had its YARP route flipped to the .NET 8 stack. The other 41 pages continued serving from the legacy stack until their turn.
Once all 47 pages had been migrated and verified in production, the YARP router was updated to send 100% of traffic to the .NET 8 stack. The legacy IIS server was kept running in standby for 72 hours — not serving traffic, but available for instant rollback if a production issue emerged. After 72 hours with no incidents, the legacy host was shut down and decommissioned. The portal moved to Azure App Service with auto-scaling, health probes, and deployment slots enabled for future zero-downtime deployments.
— Before & After
— Measured Outcomes
On performance: The throughput gains are partly .NET 8's Kestrel server (which is substantially more efficient than IIS/System.Web), and partly the architectural cleanups made possible during the migration — removing redundant ViewState, eliminating synchronous database calls, and moving report generation to background workers via hosted services.
— FAQ
Most can, using the strangler fig pattern — but the approach depends on the application's architecture. WebForms applications like this one require more significant restructuring than WCF services or MVC applications, because WebForms has no .NET Core equivalent. The determining factors are how much of the application's logic is in code-behind files, whether the data access layer is LINQ-to-SQL or Entity Framework, and what the authentication mechanism is. Infomaze assesses all of these in an initial architecture review before committing to a migration plan.
The strangler fig pattern, named after a tree species that grows around and eventually replaces its host, involves building a replacement system around the existing one rather than replacing it wholesale. In a .NET migration, this means deploying the new .NET 8 application alongside the old .NET 4.5 application, routing traffic progressively to the new stack module by module, and retiring the old system only after every module has been verified in production. It eliminates the "big bang" risk of deploying a full rewrite in one go.
FormsAuthentication is not available in .NET Core at all — it was removed, not deprecated. The approach is to build a token exchange bridge: authenticated sessions on the legacy stack are converted to JWT tokens on the new stack without requiring users to re-login. This involves a shared session store (typically Redis or SQL-backed) accessible to both stacks during the transition period, and a token exchange endpoint that validates legacy credentials and issues modern tokens.
For a portal of this scale — 47 pages, 14 years of accumulated code, live financial data — the migration ran across approximately four months of engineering time. Simpler applications with fewer pages and a cleaner architecture can be done in six to eight weeks. The timeline is primarily driven by the number of WebForms pages, the complexity of the data access layer, and the volume of integration testing required. Infomaze provides a scoped timeline after an initial codebase review.
Neither entirely. Business logic — the rules governing calculations, validation, workflows — is typically preserved and refactored rather than rewritten. What is rewritten is the presentation layer (WebForms to Razor Pages or React), the data access layer (LINQ-to-SQL to EF Core), and the infrastructure layer (System.Web to ASP.NET Core middleware). Think of it as keeping the engine and rebuilding the chassis and bodywork around it.
Infomaze migrates legacy .NET applications to .NET 8 without downtime. ISO 27001 certified. NDA from day one. 23 years of .NET engineering.
See All Legacy WorkGUIDE ✦ OFFSHORE DEVELOPMENT ✦ UK · US · AUSTRALIAs 8 min read · 2026…
ERP Solutions ✦ Odoo ✦ ERPNext ✦ United Kingdom & Australia 8 min read ·…
Business Intelligence ✦ Predictive Analytics Development ✦ Data Visualisation ✦ United States 8 min read…
Offshore Development ✦ Custom Application Development ✦ UAustralia & UK 8 min read · 2026…
Custom Application Development ✦ SaaS vs Custom Build ✦ United States 8 min read ·…