How to Convert Classic ASP to ASP.NET
Converting Classic ASP to ASP.NET works best as a sequence of small, verified steps rather than one cutover. Audit what the old application actually does, pick a target framework, share the database and the login so old and new pages run together, then move one module at a time.
SYSTEM
TRANSITION
LAYER
What to inventory before converting Classic ASP to ASP.NET
-
PAGESASP pages and entry points. Every .asp file, which ones are actually reached, and which are dead code left behind by earlier changes. -
INCLUDE#include files. Shared headers, footers and function libraries. These usually hold more business logic than anyone expects. -
COMCOM components and server objects. Registered components the pages instantiate, including any whose source code is no longer available. -
DBDatabase objects. Tables, views, stored procedures and triggers, plus which of them are called from the application rather than from somewhere else. -
JOBSScheduled jobs and batch scripts. Work that runs outside the web application entirely, and an often forgotten part of an inventory. -
USERSWho uses what. Which groups depend on which screens, which is what decides a safe conversion order.
Why Classic ASP systems are still running
Classic ASP applications that are still in production, long after ASP.NET replaced Classic ASP, are usually there because they work. They were written against a business process that still exists, and they have absorbed years of small corrections that were never written down anywhere else.
That is also why replacing them is hard. The business rules live in the code, not in a specification, and the people who could describe them from memory have often moved on. A full rewrite asks the business to accept a long gap with no working system at the end of it until everything is finished at once.
Step 1: Inventory the application
Before any code is converted, build a list of what the application is made of: the pages, the #include files, the COM dependencies, the database objects it touches, the scheduled jobs that run alongside it, and which users depend on which screens.
The goal is not a tidy document. It is to find the parts that will cause trouble later, specifically the include files that turn out to hold business logic, and the COM components nobody can rebuild.
Step 2: Choose the target: ASP.NET MVC vs ASP.NET Core
ASP.NET MVC or ASP.NET Core are the usual targets. Core is the long-term choice for new work. MVC on .NET Framework is sometimes the practical step when the system depends on Windows-only components. The choice is made per system, not by default.
If the inventory turned up COM components or Windows-only dependencies that cannot be replaced yet, going to Core first means solving those problems before any page moves. Landing on MVC on .NET Framework first keeps those dependencies working and leaves Core as a later step. If the application is already on ASP.NET Web Forms rather than Classic ASP, that is a different job, covered in ASP.NET Web Forms migration to Core.
Step 3: Share the database and the login between old and new
This is what makes running both halves together possible. The new ASP.NET application points at the same SQL Server database as the Classic ASP application, so there is no synchronization problem and no migration window to schedule.
The login has to be shared too, or users will be asked to sign in again every time they cross between an old page and a new one. In practice that means a session store both applications can read, so a user who signs in on an old page stays signed in on a new one.
Step 4: Convert module by module, starting with low-risk, high-traffic pages
Pick the first module for what it teaches you, not for how important it is. A page with heavy traffic and simple logic exercises the shared login and the shared database properly, while a mistake in it is easy to spot and easy to roll back.
Leave the modules with the most intricate business rules until the pattern is established. By then the shared session, the data access approach and the deployment path are all proven, and the only new problem in front of you is the logic itself.
Step 5: Verify against the live system before switching each module off
While both versions exist, the old page is the specification. Run the same inputs through both and compare what they produce, including the awkward cases: empty results, rounding, date handling and whatever the old code did on bad input.
Only when a converted module matches the old one does the old page get switched off. Keeping it reachable until then means a problem found in production is a routing change away from being fixed, not a redeployment.
Step 6: Redirect old .asp URLs so links, bookmarks and search rankings survive
Old URLs are in bookmarks, in emails, in other systems and in search results. When a module is switched off, its old .asp URLs should answer with a permanent redirect to the new page rather than a 404.
On IIS this is a rewrite rule per retired URL or per pattern. It is worth doing as each module is switched off, while it is still obvious which new page replaced which old one.
Common mistakes
The big-bang rewrite is a common one. The business is asked to wait, the scope grows while it waits, and the old system still has to be maintained in the meantime.
Converting syntax without understanding the rules is another. Translated VBScript that compiles is not the same as a module that behaves the way the old one did, and the differences tend to appear in the cases nobody tested.
The quieter two are forgetting the scheduled jobs and COM objects that run outside the web application, and breaking old URLs on the way through, which loses the search rankings and bookmarks the old pages had earned.
Need help with a live Classic ASP system?
We have run continuous Classic ASP to ASP.NET migration on live production systems since 2013, and the work is still running. See our Classic ASP conversion service for how the engagement works, or get in touch with what your system runs on today.
Principles for migrating Classic ASP to ASP.NET safely
The old system stays the reference
Until a module is switched off, the Classic ASP version is what the new one is measured against, because it is the only complete statement of the rules.
One module in flight at a time
Converting several modules at once makes it unclear which change caused a problem. Finishing one before starting the next keeps every regression traceable.
Nothing is switched off before its replacement is proven
The old page keeps serving until the converted one matches it, so a rollback is a routing decision rather than an emergency.
Converting Classic ASP to ASP.NET: questions
What do we do about a COM component with no source code left?
It gets wrapped and called from the new application for as long as it keeps working, and replaced only once its behaviour has been reproduced and checked. Losing the source is a reason to defer that component, not a reason to stop the migration.
Do scheduled jobs and batch scripts need converting as well?
Yes, and they are easy to miss in planning because they do not appear anywhere in the web application. They are inventoried with the pages and converted on the same module-by-module basis.
Can two developers work on the old and the new codebase at the same time?
Yes. That is one of the practical reasons for running both halves together: fixes to the old system can continue while conversion work proceeds, provided both teams agree on who owns a module while it is in flight.
Does the database schema have to stay frozen during the work?
No, but changes have to suit both halves while both are reading the same tables. Additive changes are straightforward; anything that renames or removes a column needs the old pages updated in the same step.
More on Classic ASP to ASP.NET migration
Working out whether your Classic ASP system can be converted this way?
Tell us what it runs on and what it connects to, and we will tell you which parts look straightforward and which do not.