Quick answer: A Classic ASP migration usually works best as a planned rewrite onto ASP.NET Core, done in phases rather than one big switch. Start by auditing what the old site actually does, including hidden business rules, COM components and database logic. Then decide whether to replace it all at once or route sections to the new application one at a time behind IIS. Move data access to a modern library, rebuild authentication properly and test each section against the old behaviour before switching it off.
Why Classic ASP sites are still around
Classic ASP was Microsoft’s server-side scripting platform before ASP.NET. Many internal tools, order systems and customer portals were built on it in the late 1990s and 2000s. Some of them still run because they work, and because nobody wants to touch code that holds years of business rules.
The risk grows each year:
- Developers who know VBScript and Classic ASP are harder to find
- Libraries and components the site depends on may no longer be maintained
- Security practices built into modern frameworks, like protection against cross-site request forgery and safer data access, are missing or hand-rolled
- The site may depend on old COM components, specific Windows versions or 32-bit settings in IIS
- Adding features, APIs or modern front ends becomes slow and fragile
Classic ASP still runs in IIS on current Windows Server releases, so the pressure is rarely a hard shutdown date. It is the steadily rising cost and risk of keeping it alive. Our guide to legacy system modernization covers the wider decision.
Why ASP.NET Core
For teams already invested in Microsoft technology, ASP.NET Core is the natural destination. ASP.NET Core 3.1 is the current long-term support release, and it is where Microsoft is putting its web development effort.
Benefits over Classic ASP:
- A modern, compiled language (C#) with strong tooling in Visual Studio and VS Code
- Built-in dependency injection, configuration, logging and security features
- Razor Pages and MVC for server-rendered pages, and Web API for services
- Runs on Windows and Linux, in IIS or containers
- Good performance and an active community
If the business is open to other stacks, the decision deserves a proper comparison. We looked at one common alternative in .NET vs Node.js. For most Classic ASP estates, though, staying in the Microsoft world keeps hosting, SQL Server and staff skills aligned.
Step 1: Audit what the old site really does
The most dangerous assumption in any migration is “we know what it does”. Classic ASP sites often hide rules in include files, stored procedures, scheduled tasks and COM components.
List:
- Every page and its purpose, with traffic or usage where you can measure it
- Include files and shared functions
- Database tables, views and stored procedures used
- COM components and third-party DLLs
- Scheduled jobs, file drops and email processes
- Integrations with other systems
- Authentication and permission rules
- Reports and exports that people rely on
Talk to the people who use the system daily. They know about the odd button that runs month-end or the report that finance needs every quarter. A short code audit of the riskiest areas is worth doing before you estimate.
Step 2: Decide on a migration approach
Full rewrite with one switch-over
Build the new application alongside the old one, then switch everything on a chosen date. It is simpler to reason about, but risk concentrates on launch day and the business waits a long time for any benefit.
Suitable when the site is small, well understood and can tolerate a short freeze on changes.
Phased migration behind IIS
Run both applications side by side and route URLs section by section. IIS URL Rewrite and Application Request Routing can send /orders/ to the new ASP.NET Core application while everything else still goes to Classic ASP. Each section is rebuilt, tested and switched in turn. This is often called the strangler approach.
Suitable for larger systems or those that cannot freeze for months. It needs care with shared state, which is covered below.
Do not port line by line
Translating VBScript into C# one line at a time carries old problems into the new code. Use the old site as a specification of behaviour, then build each feature the way ASP.NET Core expects.
Step 3: Plan data access
Classic ASP usually talks to the database with ADO recordsets and SQL strings built by concatenation. That pattern is a common source of SQL injection.
In ASP.NET Core you can use:
- Entity Framework Core for most CRUD and domain logic
- Dapper or plain ADO.NET with parameters where you need fine control or are calling existing stored procedures
Often the database stays the same during the first phase and only the application changes. That keeps the migration focused and lets both old and new code work against the same data. Schema clean-up can follow once the old code is gone. If data needs to move or change shape, plan it as its own workstream; see our guide to data migration.
Check query performance as you go. Old pages sometimes rely on queries that only work because traffic is low. Our post on SQL Server performance covers the usual fixes.
Step 4: Deal with COM components
Many Classic ASP sites call VB6 or other COM components for business logic, PDF generation or file handling. Options:
- Rewrite the logic in C#. Best long-term, and often simpler than expected once the behaviour is documented.
- Replace with a maintained library. Many old components did jobs that modern NuGet packages handle well.
- Call the component through COM interop temporarily. .NET Core 3.x supports COM interop on Windows, which can bridge a gap during a phased move. It ties the app to Windows and should be treated as a short-term step.
Step 5: Handle sessions and authentication
Classic ASP sessions and ASP.NET Core sessions do not share state. During a phased migration this matters, because a visitor may log in on an old page and then land on a new one.
Approaches:
- Move authentication to the new application first and have old pages trust it through a shared cookie or token checked against the database
- Store any shared session data in the database rather than in in-memory session
- Reduce reliance on session state in the new code wherever possible
Use ASP.NET Core Identity or a proper external identity provider for the new system. Do not carry over home-made password storage. Reset or rehash passwords on first login if the old system stored them weakly.
Step 6: Test against the old behaviour
For each section:
- Write down the expected behaviour from the old site, including edge cases
- Build automated tests for business rules in the new code
- Compare outputs, such as totals, reports and exports, between old and new using real data copies
- Run user acceptance testing with the people who use the feature daily
- Keep the old route available for quick rollback for a short period
Step 7: Switch off the old code
Once a section is live in ASP.NET Core and stable, remove the old pages so nobody can reach them by bookmark. Keep redirects for any URLs that customers or search engines use. When the last section moves, decommission the Classic ASP application, its IIS site and any components only it used.
Common pitfalls
- Underestimating hidden logic in stored procedures and include files
- Leaving security fixes for “after the migration”
- Running both systems for too long, so the team maintains two code bases indefinitely
- Changing the database and the application at the same time
- Forgetting scheduled tasks that run outside the website
FAQ
How long does a Classic ASP migration take?
It depends on size and hidden complexity. Small sites can move in weeks. Large business systems often take months in phases. A proper audit is the only way to estimate with confidence.
Can we move to ASP.NET Web Forms instead?
You can, but Web Forms is not part of ASP.NET Core. Moving to it means a second migration later. ASP.NET Core is the better destination for new work.
Can the site run on Linux after migration?
ASP.NET Core can, as long as you remove Windows-only dependencies such as COM components.
Plan the move before it becomes urgent
Classic ASP systems rarely fail all at once. They get slower to change and riskier to run. A phased plan lets you modernise without stopping the business. If you want help auditing and planning a move to ASP.NET Core, see our Custom development service.
