ASP.NET Web Forms Migration
for businesses in Australia, New Zealand, the UK and the US.
Web Forms was never brought forward to .NET Core or anything after it. It stays on .NET Framework, which means the application is not deprecated so much as parked at a terminus.
- Independent No licence commission, no reseller agenda
- 18+ yrs Building business software
- Fixed Price scopes, no surprises
- AU NZ UK US Perth-based, working remotely
Supported, and going nowhere
A great many internal business applications were built with Web Forms between roughly 2003 and 2015, and they work. Microsoft continues to support .NET Framework, so nothing has broken. But Web Forms was deliberately not carried into .NET Core, and every subsequent .NET release has confirmed that decision.
The practical consequence is that the application cannot follow the platform. New libraries target modern .NET, new hires have never used ViewState, and each year the gap widens.
Your Web Forms project, end to end
Three stages. Scoped and fixed-price before anything starts, delivered by the founder, and your existing system stays running until cutover.
-
Week 0
Read the system as it is
We go through the existing application and record what it actually does, including the parts nobody documented. You get a written inventory and a fixed price before any build starts.
-
Weeks 1-N
Rebuild and run in parallel
The replacement runs beside the original until the numbers reconcile. The old system stays untouched and switched on the whole time.
-
Cutover
Go live and hand over
Cutover on a date you choose, then thirty days of support. Source code, documentation and credentials are handed to you, in your name.
What the work actually is
Move it onto a .NET that still has a future
The database and much of the business logic usually carry across. What has to change is the page model: ViewState and server-side controls do not exist in modern .NET, so the interface layer is genuinely rebuilt.
What you have now
- .aspx pages with code-behind
- ViewState and server controls
- Web Forms on .NET Framework
- SQL Server behind it
Move it onto a .NET that still has a future
The database and much of the business logic usually carry across. What has to change is the page model: ViewState and server-side controls do not exist in modern .NET, so the interface layer is genuinely rebuilt.
See how a project runsWhat you end up with
- The application on current .NET, or rebuilt for the browser
- A stack that receives new features rather than only fixes
- A codebase current developers recognise
The 5 pieces of Web Forms work we are asked for
Most engagements are some combination of these, and most start with the first.
Separate logic from pages
Business logic tangled into code-behind files extracted first. How much is entangled decides the size of the whole project.
Choose the target honestly
Modern .NET with server-rendered pages, Blazor, or a JavaScript front end with an API. Each suits a different team, and we will say which suits yours.
Replace the page model
ViewState and server controls have no equivalent, so the interface layer is rebuilt rather than converted.
Keep the database
SQL Server usually stays exactly as it is, which keeps the project contained and verifiable.
Migrate in stages
Page by page behind the same address, so there is no single high-risk cutover.
Where you are now
It works, and nobody will touch it
- Web Forms on .NET Framework with no path to modern .NET
- ViewState behaviour that new developers have never met
- New libraries increasingly target .NET Core and later only
- Hiring gets harder every year
After
Supported, documented and yours
- Running on a .NET release that is still moving forward
- Access to current libraries and tooling
- A codebase a new hire recognises immediately
- The same SQL Server database and the same data
Scoped and quoted before you commit. You own the code, the documentation and the credentials at the end of it.
Get a fixed-price scopeWeb Forms questions
Is Web Forms actually dead?
It is supported on .NET Framework and it was never carried to .NET Core or later. So it will keep running and it will never move forward. Whether that counts as dead depends on how long you plan to keep the application.
What should we migrate to?
It depends on your team. Modern .NET with server-rendered pages is the smallest conceptual jump. Blazor suits teams that want to stay in C#. A JavaScript front end with an API suits teams that already have web skills.
Can ViewState be converted automatically?
No. It has no equivalent in modern .NET, which is why this is a rebuild of the interface layer rather than a conversion. The business logic underneath usually carries across well.
Can we do it gradually?
Yes, and you should. Page by page behind the same address, with both running side by side, avoids a single risky cutover on a business-critical application.
Does the database have to change?
Usually not at all. Keeping SQL Server as it is makes verification much simpler and keeps the project focused on the layer that actually has to move.
Sending your details…
You can stay on this page while we send it.
Tell us what you are running
What the system does, roughly how old it is, and what is forcing the question. We will come back with a straight answer and a fixed-price scope, even if the answer is to leave it alone.
Prefer a quick chat? Call 0425 531 127. We answer the phone in Perth.
