Web Forms naar Blazor migreren: scherm voor scherm, zonder alles in één keer te herschrijven

Veel bedrijven draaien nog steeds een belangrijke applicatie op ASP.NET Web Forms: een bestelportaal, een intern systeem voor het magazijn of de administratie, iets dat al vijftien jaar werkt. Het werkt nog steeds. Maar elke wijziging duurt langer, de ontwikkelaars die het kennen vertrekken, en niemand wil degene zijn die eraan zit.

Het goede nieuws: overstappen op Blazor hoeft geen jaar herschrijven te betekenen terwijl het bedrijf wacht. De applicatie kan scherm voor scherm verhuizen, terwijl gebruikers gewoon doorwerken en er nauwelijks iets van merken.

Waarom Web Forms niet gewoon te upgraden is

Web Forms bestaat niet in modern .NET. Het is nooit naar ASP.NET Core overgezet, dus er is geen knop “upgrade naar .NET 10”. De pagina’s moeten opnieuw worden gebouwd.

.NET Framework 4.8 wordt nog ondersteund zolang de Windows-versie waarop het draait wordt ondersteund, dus morgen gaat er niets uit. Maar het krijgt geen nieuwe functies, nieuwe bibliotheken slaan het steeds vaker over, en ontwikkelaars die in Web Forms willen werken zijn elk jaar moeilijker te vinden.

Twee wegen: alles in één keer, of scherm voor scherm

Alles in één keer lijkt eenvoudiger: naast de oude applicatie wordt een nieuwe gebouwd, en op één dag wordt er overgeschakeld. In de praktijk betekent dat maanden zonder nieuwe functies in de oude applicatie, twee applicaties die parallel onderhouden worden en een livegang waarbij alles op hetzelfde moment moet werken.

Scherm voor scherm draait dat om. Voor de oude applicatie komt een proxy, en elk scherm dat naar Blazor verhuist, wordt vanaf dan door de nieuwe applicatie geleverd. Gebruikers houden hetzelfde adres en dezelfde login en gaan van oude naar nieuwe schermen zonder het te merken.

1. 1Inventaris van alle schermen
2. 2Proxy voor de oude applicatie
3. 3Scherm voor scherm naar Blazor
4. 4De oude applicatie gaat uit

De proxy: hoe oud en nieuw samenwerken

De proxy is YARP, de reverse proxy van Microsoft, en die draait in de nieuwe Blazor-applicatie. Alles wat de nieuwe applicatie kan leveren, levert ze zelf. Al het andere gaat door naar de oude Web Forms-applicatie.

builder.Services.AddReverseProxy()
    .LoadFromConfig(builder.Configuration.GetSection("ReverseProxy"));

app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode();

app.MapReverseProxy();

In de configuratie vangt één route alle adressen op, met een lage prioriteit, zodat die alleen geldt als geen Blazor-pagina past:

"ReverseProxy": {
  "Routes": {
    "webforms": { "ClusterId": "webforms", "Order": 1000, "Match": { "Path": "{**catch-all}" } }
  },
  "Clusters": {
    "webforms": { "Destinations": { "old": { "Address": "https://orders-legacy.internal/" } } }
  }
}

Zodra het orderscherm in Blazor opnieuw is gebouwd, levert de nieuwe applicatie /orders, en het oude scherm wordt gewoon niet meer bereikt. Login en sessie kunnen met de System.Web-adapters van Microsoft tussen beide applicaties worden gedeeld, zodat gebruikers niet twee keer hoeven in te loggen.

Hoe één scherm eruitziet, voor en na

Een typische Web Forms-tabel met paginering:

<asp:GridView ID="OrdersGrid" runat="server" AutoGenerateColumns="false"
    AllowPaging="true" PageSize="20" OnPageIndexChanging="OrdersGrid_PageIndexChanging">
    <Columns>
        <asp:BoundField DataField="Number" HeaderText="Order" />
        <asp:BoundField DataField="Customer" HeaderText="Customer" />
        <asp:BoundField DataField="Total" HeaderText="Total" DataFormatString="{0:C}" />
    </Columns>
</asp:GridView>

Hetzelfde scherm in Blazor, met de QuickGrid-component die bij .NET wordt geleverd:

@inject OrderService Orders

<QuickGrid Items="orders" Pagination="pagination">
    <PropertyColumn Property="@(o => o.Number)" Title="Order" />
    <PropertyColumn Property="@(o => o.Customer)" Title="Customer" />
    <PropertyColumn Property="@(o => o.Total)" Title="Total" Format="C" />
</QuickGrid>

<Paginator State="pagination" />

@code {
    private readonly PaginationState pagination = new() { ItemsPerPage = 20 };
    private IQueryable<Order> orders = Enumerable.Empty<Order>().AsQueryable();

    protected override async Task OnInitializedAsync()
        => orders = (await Orders.GetOpenAsync()).AsQueryable();
}

De markup lijkt op elkaar. Het echte verschil zit erachter: geen ViewState, geen postback bij elke paginawissel, en OrderService is gewone C# die getest en hergebruikt kan worden.

Wat makkelijk overgaat, en wat niet

In Web Forms	In Blazor	Werk
Bedrijfslogica in aparte klassen	Dezelfde klassen, als services	Klein
Bedrijfslogica in de code-behind	Eerst naar services verplaatst	Gemiddeld
Master pages	Layouts	Klein
User controls (.ascx)	Componenten	Klein tot gemiddeld
GridView, Repeater, FormView	QuickGrid of een componentenbibliotheek	Gemiddeld
Pagina’s gebouwd rond ViewState en postbacks	Componentstatus, met een doordachte flow	Gemiddeld
Web Forms-controls van derden	Hun Blazor-versies, of andere componenten	Gemiddeld tot groot
Crystal Reports	Een ander rapportagetool	Groot
Login en sessie gedeeld tussen oud en nieuw	System.Web-adapters of een gedeelde cookie	Gemiddeld, één keer aan het begin

De grootste onbekende is niet Blazor, maar hoeveel logica in de code-behind begraven zit. Waar de logica al in aparte klassen staat, verhuist een scherm vaak in een paar dagen. Waar elke klik op een knop honderd regels SQL en schermcode door elkaar bevat, moet die logica eerst worden losgemaakt.

In welke volgorde de schermen verhuizen

1. Eerst één eenvoudig scherm, om te bewijzen dat proxy, login en deployment van begin tot eind werken.
2. Dan de schermen die het meeste pijn doen: die vaak veranderen, traag zijn of waarover gebruikers klagen. Daar verdient de verhuizing zich het eerst terug.
3. Weinig gebruikte beheerschermen als laatste. De inventaris vindt vaak schermen die niemand meer gebruikt, en die hoeven helemaal niet te verhuizen.

Checklist voordat u begint

• Een lijst van alle pagina’s, met een notitie welke echt worden gebruikt (logs of analytics).
• NuGet-pakketten en controls van derden. Onze gratis tool voor .NET Framework-migratie controleert welke daarvan een versie voor .NET 10 hebben.
• Hoe de login nu werkt: Forms-authenticatie, Windows-authenticatie of ASP.NET Identity.
• Waar de bedrijfslogica zit: in aparte klassen of in de code-behind.
• Rapporten, exports en e-mails die de applicatie verstuurt.
• Wie elk scherm test als het verhuist, en wie het goedkeurt.

Voor het bredere beeld van de overstap van .NET Framework leest u het artikel over migratie van .NET Framework naar .NET 10, en voor de vraag of Blazor wel een veilige keuze is, Heeft Blazor in 2026 nog toekomst?.

Hoe wij werken

Precies dit doen wij: wij migreren Web Forms-applicaties scherm voor scherm achter een proxy naar Blazor, terwijl gebruikers gewoon in de applicatie blijven werken. Wij beginnen met een inventaris en een plan dat laat zien welke schermen als eerste gaan en waar de lastige delen zitten. Meer over de aanpak staat op de pagina Blazor, en de eerste stap is een gratis gesprek van 30 minuten.

Bronnen

• ASP.NET Framework to ASP.NET Core migration, Microsoft Learn
• Incremental ASP.NET to ASP.NET Core migration, Microsoft Learn
• YARP, GitHub
• System.Web adapters, GitHub
• ASP.NET Core Blazor QuickGrid component, Microsoft Learn
• .NET Framework lifecycle, Microsoft Learn