Classic ASP to .NET Core: What the Migration Actually Involves

Why there is no conversion tool

Classic ASP and .NET Core do not share a runtime, a language, a request pipeline, or a programming model. Classic ASP executes VBScript or JScript interpreted per request, with server-side includes stitching files together and state held in server memory. .NET Core is a compiled, dependency-injected, middleware-based framework. There is no meaningful mapping between the two, which is why no vendor sells a converter that works.

What exists instead are tools that wrap classic ASP so it can keep running, and tools that help you inventory what a site does. Both are useful. Neither converts anything.

The practical consequence is that the project should be scoped as building a new application that does what the old one does — not as upgrading the old one. That framing changes how it is estimated, how it is tested, and what done means.

What actually has to be rewritten

Four things account for most of the work in a classic ASP migration.

VBScript itself. Every line of application logic is in a language with no equivalent in .NET Core. It has to be reimplemented in C#. This is mechanical for simple pages and genuinely difficult where the original relies on VBScript behaviour — loose typing, implicit conversions, or error handling built around On Error Resume Next, which has no direct counterpart and often conceals bugs that only surface once real error handling is introduced.

COM components. Classic ASP sites commonly instantiate COM objects through Server.CreateObject — for PDF generation, image manipulation, file handling, payment processing, or bespoke business logic compiled years ago. Each one needs a decision: find a modern library that does the same job, reimplement it, or keep it running somewhere. If the original source is lost, which is common, reimplementation means working out the behaviour from the outside.

Session state. Classic ASP holds Session in the memory of a single server process. Applications built on that assumption often store substantial objects there and rely on them persisting across requests. Modern hosting is multi-instance by default, so session state has to move to a distributed store, or the application has to stop depending on it. This is one of the most common sources of subtle bugs after a migration, because it works fine on one instance and fails intermittently on several.

ADO database access. Data access via ADO and inline SQL, frequently built by concatenating strings, has to be rewritten against a modern data access layer. This is often the part where the migration delivers the most value beyond the move itself, because string-concatenated SQL is where SQL injection lives, and rewriting it is the opportunity to eliminate that whole class of problem.

Realistic effort tiers

Classic ASP sites vary enormously, and the useful question is which of three broad shapes yours is.

Content-led sites. Mostly pages, navigation, and a contact form, with ASP used for includes and a little templating rather than real logic. These are the fastest, and they are usually not rebuild candidates at all — a site like this is generally better served by replacing it than by rebuilding it in .NET Core, because it never needed a server-side runtime in the first place.

Form-and-database sites. Real data capture, some workflow, user accounts, reporting. Genuine business logic, but conventional. These are the typical rebuild, and the timeline is driven by the number of distinct workflows rather than the number of pages.

Deep line-of-business applications. Years of accumulated rules, integrations with other systems, batch jobs, and behaviour that exists because of a decision made a decade ago that nobody remembers. These are the projects where the running application is the only specification, and where the discovery work of establishing what it actually does rivals the work of building the replacement.

The distinction that matters most for planning is whether the business logic is documented anywhere other than the code. If it is not — and it usually is not — then a meaningful share of the project is archaeology, and that should be in the estimate rather than discovered halfway through.

When rebuilding is the wrong answer

.NET Core is not automatically the destination, and two alternatives are worth ruling in or out before committing to a rewrite.

Rehosting instead. Classic ASP still runs on current versions of IIS — the ASP feature remains available in Windows Server and can be enabled. If the application works and the actual problem is an end-of-support operating system underneath it, lifting it onto supported infrastructure is dramatically cheaper than rewriting, and it is a legitimate answer. It does not modernize anything, and the underlying technology keeps ageing, but it solves the problem that is actually urgent.

Replacing instead. If the site is essentially content, or if what it does is something shipping software already does well, then rebuilding it as a custom .NET Core application means taking on maintenance of custom software to do a commodity job. Either retire the dynamic backend entirely, or move to a maintained product. The knowledge base case study is an example of the second, where replacing the platform outright was cheaper and safer than rebuilding around it.

Rebuilding earns its cost when the application encodes something specific to how the business operates, that specificity still matters, and the existing code has become the obstacle. The direct-response marketing case study is that situation: a custom ASP.NET platform where the logic was worth keeping and the codebase was not.

Frequently asked questions