Classic ASP to ASP.NET Migration and Conversion
We convert Classic ASP applications to ASP.NET on live production systems, one module at a time, without a big-bang rewrite. Old and new pages share one database and one login, so users keep working throughout. Since 2013 we have run this migration on a long-running US public sector case management platform.
SYSTEM
TRANSITION
LAYER
What a Classic ASP to ASP.NET migration covers
- An inventory before any code moves. Every .asp page, include file, COM component, database object and scheduled job, plus which users depend on which screens. This sets the conversion order and the scope.
- ASP to ASP.NET conversion, module by module. To convert ASP to ASP.NET without stopping the business, pages move in small groups while the Classic ASP application keeps serving everything that has not moved yet.
- A target chosen per system. ASP.NET MVC or ASP.NET Core, decided by what the system depends on rather than by default.
- Old and new running side by side. One SQL Server database and one login shared by both halves, so there is no data sync and no cutover weekend.
- Security fixed on the way through. Inline SQL becomes parameterized queries and Response.Write output becomes encoded views, closing the injection and XSS holes Classic ASP code tends to carry.
- URLs and rankings preserved. Every retired .asp URL answers with a 301 redirect to its new page, so bookmarks, links and search positions carry over.
What converts from Classic ASP to ASP.NET, and what has to be rewritten
-
VBSVBScript page logic becomes C# in controllers, services and views. The syntax converts; the business rules inside it have to be read, understood and rewritten. -
COMCOM and ActiveX objects becomes a .NET library where one exists. Where none does, the component is wrapped and kept working until its behavior can be rebuilt and checked. -
ADOADO Recordsets becomes typed data access against the same SQL Server database. Cursor and paging behavior is rewritten, not translated. -
SESSIONSession and Application state becomes a session store both applications can read, so a user signed in on an old page stays signed in on a new one. Rewritten, not converted. -
INCLUDEServer-side include files becomes shared layouts, partial views and services. Mostly rewritten, because includes often hold business logic as well as markup. -
SQLInline SQL built from strings becomes parameterized queries. Always rewritten, because string-built SQL is where injection risk lives. -
AUTHCustom login and permission checks becomes ASP.NET authentication and authorization, rewritten to keep the same users and the same rules.
The pattern is consistent. Markup and simple syntax convert. Anything that holds state, talks to the database or encodes a business rule gets rewritten and checked against the old page.
Automated Classic ASP conversion tools vs manual rewrite
Where conversion tools help
Translating VBScript syntax to C#, converting repetitive markup, and producing a first draft of each page. That removes typing, and on a large system the typing is real.
Where conversion tools fail
They cannot understand business rules written in VBScript, replace a COM object that has no .NET equivalent, or redesign session handling so old and new pages share a login. Their output compiles, but compiling is not the same as behaving like the old page.
What most real projects are
A mix. Tools handle the mechanical layer where they save time. A developer rewrites the logic, data access and state, then checks each page against the live Classic ASP version before it is switched off.
Choosing the ASP.NET target: ASP.NET MVC or ASP.NET Core
ASP.NET MVC runs on .NET Framework, on Windows and IIS. It is often the practical first landing for a Classic ASP system that depends on Windows-only components, because those components keep working while the pages move. .NET Framework 4.8 is the final major version of .NET Framework, so new features arrive in modern .NET instead.
ASP.NET Core runs on modern .NET and is the long-term choice for new work. Moving straight to Core means every Windows-only dependency has to be replaced or isolated before the pages that use it can move. We offer both as targets and decide per system, after the inventory shows what the code depends on.
An ASP.NET Web Forms migration is different work from Classic ASP, because Web Forms pages have no direct equivalent in Core. That has its own page: Web Forms to ASP.NET Core migration.
Running Classic ASP and ASP.NET side by side
The business never stops while the migration runs. The ASP.NET application points at the same SQL Server database as the Classic ASP application, so there is nothing to synchronize. Both read one session store, so users cross between old and new pages without signing in again.
Pages move over one module at a time. A routing change sends users to the new page once it matches the old one. Until then the Classic ASP page stays reachable, which makes a rollback a routing change rather than an emergency deployment.
Keeping URLs and search rankings through an ASP to ASP.NET conversion
Old .asp URLs live in bookmarks, emails, other systems and search results. When a module is switched off, each of its .asp URLs answers with a permanent 301 redirect to the new page, set up as an IIS rewrite rule. Search engines can then carry the old page's standing over to the new URL, and nobody lands on a 404.
We add the redirects module by module, while it is still obvious which new page replaced which old one. Query-string URLs get their own rules, because IIS does not match the query string in the path pattern.
What drives the cost and timeline of a Classic ASP migration
There is no fair price or timeline for an ASP to .NET migration before the inventory, because two Classic ASP systems of similar size can differ a great deal underneath. The factors that matter are how many pages are actually in use, how much logic sits in include files, how many COM components are involved and whether their source still exists, how much of the behavior is tested or documented, and how many integrations the system talks to.
New feature work running alongside the migration also affects the timeline. That is normal on a live system, and the side-by-side approach allows for it.
Classic ASP to ASP.NET migration on a live public sector platform
Since 2013 we have run continuous Classic ASP to ASP.NET MVC migration on a long-running US public sector case management platform. The work is still running, on live production systems.
The systems were inherited. We maintain and extend them while converting them, across multiple large production systems, and each deployment has its own codebase and its own requirements. The work also covers document merge, SharePoint integration, Google Drive integration, API integrations and SQL Server.
The engagement is confidential. We do not name the client, show its code or describe its business logic. For the step-by-step method behind this kind of work, read our Classic ASP to ASP.NET migration guide.
How we run a Classic ASP to ASP.NET migration
Inventory, then a conversion order
The inventory decides what moves first. Simple, heavily used pages go early to prove the shared database and login. Intricate business logic waits until the pattern is established.
One module in flight at a time
Finishing one module before starting the next keeps every regression traceable to a single change.
The old page is the specification
The same inputs go through the Classic ASP page and the ASP.NET page, including bad input, empty results and date handling. A module is switched over only when the two agree.
Integrations carried across
File drops, document generation, third-party APIs and anything else the system talks to are moved with the module that owns them, not left behind on the old server.
Where Classic ASP to ASP.NET migrations go wrong
- Users lose their session crossing between old and new pages A common pattern when the two halves keep separate session state. Users are asked to sign in again, or lose a half-finished form. The fix is a session store both applications read, set up before the first page moves.
- A COM component has no .NET equivalent Common in older systems, especially when the source is lost. The component is wrapped and called from ASP.NET for as long as it works, and replaced only once its behavior has been reproduced and checked.
- Inline SQL carried straight into the new code A common shortcut in converted code. The query still works, and so does the injection hole. Every query is rewritten as a parameterized query as its page moves.
- Character encoding breaks on migrated data A common pattern when Classic ASP pages used a legacy code page and the new application assumes UTF-8. Names and addresses with accented characters come out garbled. The fix is to identify the encoding the old pages actually used and convert data and output deliberately.
- Business logic hidden in include files A common surprise. An include that looks like a header turns out to set prices, permissions or defaults. The inventory reads every include for logic, not just markup, before its pages are scheduled.
Classic ASP to ASP.NET migration questions
Can Classic ASP be converted to ASP.NET automatically?
Partly. Tools translate syntax and repetitive markup. They do not understand VBScript business rules, COM components or session handling, so every converted page still needs a developer and a check against the old page.
Do we have to rewrite everything at once?
No. Old and new pages run side by side on one database and one login, and modules move over one at a time. Nothing is switched off until its replacement matches it.
Should we target ASP.NET MVC or ASP.NET Core?
Core for most new work. MVC on .NET Framework when the system depends on Windows-only components that cannot be replaced yet. We decide per system, after the inventory.
Will our URLs and SEO survive the migration?
Yes, if every retired .asp URL answers with a 301 redirect to its new page. We add the redirects as each module is switched off.
Is Classic ASP still supported and safe to run?
Support depends on the IIS and Windows Server versions underneath and on any third-party components, each with its own lifecycle. The bigger risks are usually inline SQL, unencoded output and components nobody can rebuild. See the real risks of keeping Classic ASP running.
Can the old and new versions share one database?
Yes. That is how they run together. Both point at the same SQL Server database, so there is no sync job and no migration weekend.
How long does a migration take?
It depends on the system, so we do not quote a timeline before an inventory. The main factors are how many pages are in use, how much logic sits in include files, how many COM components are involved, how much behavior is tested and how many integrations the system has.
Do you work on systems you did not build?
Yes. The public sector platform we have migrated since 2013 was inherited. Most Classic ASP systems were written by someone else, which is why every engagement starts with an inventory.
Related to Classic ASP to ASP.NET migration
Is a Classic ASP system still running something you cannot afford to switch off?
Tell us what it runs on, what it connects to and roughly how many pages it has. We will tell you which parts look straightforward and where the risk is.