Legacy .NET modernization

ASP.NET Web Forms to ASP.NET Core and Blazor, one tested page at a time.

We record what your application does today as automated tests, let AI agents draft the new version page by page, and ship a page only when the same tests pass on it. The old and new applications run side by side the whole way, so users keep their URLs and a page can be rolled back by routing it to the legacy app again.

See the demonstration results Start with a pilot

Parity tests passed by the new app, recorded from the old one: 28/28; Parity tests passed by the new app, recorded from the old one
Automated accessibility violations, before and after: 57 → 0; Automated accessibility violations, before and after
Deliberately injected changes the tests caught: 9/9; Deliberately injected changes the tests caught
Every address the old app served still works: Same URLs; Every address the old app served still works

From our demonstration on Microsoft’s 7-page eShopLegacyWebForms sample, run 8 November 2026. What it covers and what it does not.

Why this has to happen

Web Forms never came to modern .NET.

Web Forms runs only on .NET Framework. Microsoft did not bring it to .NET Core or to any .NET release since, and .NET Framework 4.8.1 is the last major version: supported as part of Windows, with security fixes, but no new features. ASP.NET Core, where new hosting, performance and security work happens, has no Web Forms.

Moving forward means rewriting the user interface. Business logic and data access can often stay. The risk is behavior: the validation rule nobody wrote down, the page only one role can see, the address bookmarked in a thousand browsers. The method below exists to catch those before users do.

Who it is for

Government and commercial systems, the same method.

Government agencies

Federal, state and local systems still on Web Forms: grants management, case management, licensing, permitting and records. Section 508 accessibility and authorization parity are measured on every page. We answer RFIs, run pilots, bid as a prime where the work fits, and subcontract on larger teams.

For government buyers →

Companies and institutions

The same method for private companies, insurers, hospitals and universities running old .NET systems: policy and claims screens, internal portals, student and research administration, line-of-business applications. The system keeps running while it moves, and the tests stay with you.

Start with a pilot →

The method

AI does the volume. Tests decide. A person is accountable.

AI agents do the inventory, the test generation, the first-draft conversion and the documentation. An accountable engineer reviews every change. Nothing ships without passing the parity tests.

01
Inventory
A scanner reads every page, master page, user control and code-behind file: each server control, event handler and data-binding expression, every use of ViewState, Session and the query string, every authorization check and every route. The plan is built on counts, with a complexity score per page.
02
Record
Automated browser tests drive your running legacy application and record what each page does: status codes, redirects, visible text, tables, form fields, links and validation messages. Accessibility is scanned on every page. Bugs found while recording are written down as declared deviations before any new code exists.
03
Convert
AI agents draft the ASP.NET Core and Blazor version of each page from the legacy source and the inventory. The unmodified draft is committed before it is built or tested, so what the AI wrote and what a person changed stay separate in the history.
04
Prove
The same tests run against the new application; only the address changes. Every recorded behavior must match, or match a declared deviation. Accessibility and authorization checks run with them. The tests are tested too: we inject changes and confirm they are caught.
05
Attribute
Every file carries a provenance record: the legacy sources it came from, the tool and model that produced it, each commit since, any fix made after a test failed, and who reviewed it. FrontierPeer, our multi-model review platform, is the control layer for that record. An accountable engineer signs off every change.

Side by side

Page by page, with the old system still running. Rollback is a route.

A new ASP.NET Core application goes in front of the existing one. Requests for pages that have been migrated are answered by the new application. Everything else is forwarded to the legacy application by YARP, Microsoft’s reverse proxy, and Microsoft’s System.Web adapters let the two share session state and sign-in during the transition.

Each page moves when its tests pass. Legacy URLs keep working throughout, including old .aspx addresses. If a migrated page misbehaves, rolling it back means routing its URL to the legacy application again.

Browser
Same URLs as today, same sign-in
↓
New ASP.NET Core / Blazor application
Answers every page that has passed its tests
↓ YARP forwards the rest
Existing Web Forms application
Unchanged; shrinks as pages move

What you get

What you receive.

An inventory of the whole application

Every page, control, event handler, route and authorization check, with a complexity score, before any estimate is made.

Parity tests you keep

The recorded behavior tests stay with your application and keep guarding it after the migration is done.

Section 508 accessibility, measured

axe-core scans of every page before and after, against WCAG 2.0 and 2.1 A and AA; the Revised Section 508 Standards incorporate WCAG 2.0 AA. Automated tools find only part of what WCAG covers, so keyboard and screen-reader checks are part of each page's review.

Security and authorization parity

Every authorization check in the inventory gets a test: each role sees and can do what it could before, and nothing more. Your existing sign-in stays in place; during the transition the new application uses it through Microsoft's System.Web adapters.

Your controls and your hosting

Telerik UI for ASP.NET AJAX controls map to their Telerik UI for Blazor counterparts where you hold the license. A control with no counterpart is flagged in the inventory for a decision before work starts. The new application runs on Azure, on IIS on your existing servers, or in containers.

A provenance log and plain documentation

Which tool and model produced each change and who reviewed it, the declared deviations with their reasons, per-page migration notes, and a runbook for the side-by-side routing.

Start small

A fixed-price pilot on your own code.

We inventory one functional area of your application and migrate two or three representative pages, with full parity tests, accessibility results before and after, and the provenance log. You see the method work on your system, and the inventory gives the rest of the migration a basis in counts before you commit to more.

The price is fixed and quoted after a short scoping call.

Ask about a pilot

Inventory of one functional area
Two or three representative pages migrated
Parity tests recorded from your running system
Accessibility before and after
Provenance log for every change
Runs beside your system; nothing is switched off

Plainly

Who you would be hiring.

Frontier Peer Labs, LLC was formed in August 2026. We have no completed federal contracts yet and no past performance to cite. The evidence we can offer is the Web Forms to Blazor demonstration: its inventory, recordings, test results and provenance.

The method is language-agnostic. Inventory, recorded behavior, AI-drafted conversion and parity tests work for any system that can be run and tested. We start with Web Forms because it is the clearest case of a platform with no path forward, and we staff each engagement with the platform depth it needs.

Registrations, NAICS codes and teaming: For government buyers.