Home/Services/Classic ASP migration

// Classic ASP

Classic ASP migration that keeps your business rules, and your business, running

Your team runs on a system built from .asp pages, and the person who understood it is gone. We read the old code before anyone replaces it: we stabilize the app, write down the rules buried in it, then run the Classic ASP migration page by page while people keep working. Your first call is with a U.S.-based engineer.

classic-asp-app — first inventory (hypothetical example)
→ map the app before changing anything✓ Staging copy running on a separate IIS site! Pricing rules duplicated in two include files! PDF export runs through a COM component, no source! Search page pastes form input straight into SQL→ phase 1: order lookup; old pages stay live

// Know what you have

Classic ASP is not ASP.NET Web Forms

The two get blurred, even in migration quotes. Classic ASP pages end in .asp and are scripts, usually VBScript, that IIS runs on each request. ASP.NET Web Forms pages end in .aspx and are compiled and run on the .NET Framework.

A Classic ASP page often mixes HTML, SQL and business logic in one file, plus shared include files and COM components registered on the server. No upgrade wizard handles all of that; someone has to read it and rebuild it.

which one do you have?
→ open the site folder on the web serverClassic ASP: .asp files, global.asa, #include linesWeb Forms: .aspx files, web.config, a bin folder of DLLs✓ Both in one site? The plan treats each part separately.

// Why now

Why plan your Classic ASP modernization now

None of these forces a rewrite tomorrow. Together, they’re why it’s better to move on your schedule than in an emergency.

The person who knew it is gone

When the developer who built and patched the app leaves, its rules leave too. Replacing them means finding someone fluent in VBScript, ADO and COM, often on short notice.

VBScript is being deprecated

Microsoft is retiring VBScript in phases. Its timeline says that around 2027 it will no longer be enabled by default in Windows. It doesn’t spell out the effect on Classic ASP; our end-of-life guide covers what’s known.

Support follows your Windows server

Microsoft ties ASP support to the lifecycle of the Windows version it runs on (KB 2669020). An app stuck on an old server inherits that server’s end of support.

Hosting choices are narrow

The app needs Windows, IIS and the ASP module, which isn’t installed by default, so someone keeps patching a server mainly for this one app.

“Our crews need to do this from their phones.”

Desktop table layouts mean pinching and zooming, or waiting until people are back at a desk. Rebuilt pages can work at phone width.

Security fixes pile up

Old pages may paste form input straight into SQL or keep database passwords in plain-text include files. We look for both early and fix them properly as each page is rebuilt.

// Options

Three ways to upgrade a Classic ASP application: rehost, contain or migrate

Choose by how long the app needs to live, how often it changes and what your IT team can support. You can combine paths: contain now, migrate page by page later. For systems beyond Classic ASP, see legacy application modernization.

Path
What it involves
When it fits
Trade-off
Rehost
Move the app as-is to a supported Windows Server and IIS version.
The server is out of support and you need breathing room.
A stopgap: VBScript and undocumented rules stay.
Contain or move to the cloud
Package the app and its IIS setup in a Windows container, or move it to a cloud-hosted Windows server.
You want off aging hardware and the app rarely changes.
Same code underneath, so the VBScript dependency remains.
Migrate page by page
Rebuild one page or module at a time on a current, supported stack, with old and new pages sharing one database.
The app is central to your work and still changing.
The most engineering work, in small phases you can check.

Why automatic converters rarely finish the job

Conversion tools can translate VBScript syntax. They can’t tell which of two near-identical include files is live, rebuild a COM component with no source code, or decide whether an odd rule is a bug or a requirement. Converted code also keeps the old structure: new syntax wrapped around old problems. We use tools where they help and engineering judgment everywhere else.

// Business rules

Protecting the business rules buried in old Classic ASP code

In a long-lived Classic ASP app, the code is the specification. Discount tiers, approval limits, the rounding finance relies on: often none of it is written down elsewhere, and some lives in a stored procedure or COM component.

So we inventory first: every page, include file, COM component, stored procedure and scheduled job. Each rule we find is written down in plain English for you to confirm, and rules you no longer follow can be dropped before anyone rebuilds them.

Then old and new run side by side. We give both the same inputs and compare outputs before a new page replaces an old one, so differences surface in testing, not in front of customers.

side-by-side check (hypothetical example)
→ compare order totals: old page vs new, same sample orders✓ Line totals: match✓ Tax and freight: match! Volume discount: new rounds per line, old per order! Finance confirms the old rule; new page corrected✓ Ready to replace orders/total.asp

// Your data

Keep your SQL Server data and reports working through the migration

Your SQL Server database holds years of history, and other things may depend on it: Tableau or Excel reports, a nightly export to accounting, a job someone scheduled long ago.

The default plan keeps that database and changes the application around it. New pages use the same tables, so reports keep running through every phase, and queries buried in page code move into parameterized SQL as each page is rebuilt.

Sign-in needs care too. Classic ASP keeps its session data to itself, so we decide early how people stay signed in across old and new pages. Schema changes, if needed, get their own phase.

  • ✓Same SQL Server database through every phase
  • ✓Reports and exports checked before each release
  • ✓Old URLs redirected where paths change
  • ✓One sign-in across old and new pages

// Stabilize first

Need a Classic ASP developer right now? Stabilize first

Sometimes the migration isn’t the urgent part. The app broke after a server update, your developer stopped answering, or nobody has the admin password. You need Classic ASP support and maintenance first.

We get the app under control and keep it stable while the migration plan takes shape; the backups, staging copy and notes become its starting point. For long-term care, see software maintenance and support.

  • ✓Get access: server, source code, database, domain and hosting accounts
  • ✓Back up the code, the database and the IIS configuration
  • ✓Stand up a staging copy so fixes are tried away from the live app
  • ✓Document how it works: pages, includes, jobs, integrations
  • ✓Harden security: patch the server, close injectable queries, remove stale accounts
  • ✓Fix what’s breaking, then keep it stable while the plan takes shape

// Engagement

How a Classic ASP migration runs

Step 1

Assessment call with an engineer

Your first call is with an engineer. Tell us what the app does, who uses it, where it’s hosted and what worries you most.

Step 2

Page and module inventory

We map every page, include, COM component, stored procedure, report and integration, and write the business rules down in plain English.

Step 3

Phased plan

Pages are grouped into phases, starting with what hurts most or carries the most risk. Each phase is small enough to judge on real pages before the next.

Step 4

Staging-tested releases and maintenance

New pages are checked on the staging copy and compared with the old ones before release. The same crew then hosts and maintains the app.

// Selected work

Selected work: software we keep running after launch

A migration only pays off if someone looks after the result. Our crew designs, builds and still runs our own platform, and hosts and maintains a confidential client’s careers website. Browse all our services or all case studies.

Our own platform · Restaurants

A platform we designed, built and still run

Just A Menu keeps QR menus, TV menu boards, print, websites and an API in sync from one dashboard, plus the JAM Player hardware.

ProductWeb appAPI
Read the case study →
Confidential client

Hosting · Maintenance

A national careers website, hosted and maintained

We host and maintain the careers website for a national retail chain. The client is confidential, so we don’t name it.

HostingMaintenance

// Credentials

The basics, before you ask.

Since 2018

Building and supporting software

Orlando, FL

100% U.S.-based team, clients nationwide

SAP Ariba

Registered supplier

NDAs welcome

Happy to sign before you share details

DesignRush Top Web Design Companies badge

Top Web Design Companies

DesignRush

// FAQ

Classic ASP migration FAQ

Is Classic ASP still supported?

Microsoft says ASP is currently supported in all supported versions of IIS, with support tied to the Windows lifecycle (KB 2669020). VBScript, which Classic ASP apps typically use, is being deprecated in phases. Our Classic ASP end-of-life guide has the details.

Can Classic ASP be converted automatically?

Conversion tools can help with parts, but business rules, include files and COM components usually need an engineer’s judgment. We prefer migrating page by page and comparing results against the old system.

Can you keep our Classic ASP app running while we plan?

Yes. We get access, back it up, set up a staging copy and document how it works, then keep it stable while the migration plan takes shape.

Will our URLs and search rankings survive?

They can, if the migration maps old URLs to new ones and adds redirects wherever paths change. We plan that as part of the page inventory.

Can we keep our SQL Server database?

Usually, yes. A migration can keep the existing database and change the application around it, which keeps your reports working. Schema changes, if needed, get their own phase.

Can we migrate our Classic ASP app to the cloud?

Yes, by two routes. As a stopgap, move the existing app to a cloud-hosted Windows server or a Windows container with IIS. For the long term, migrate it page by page to a current stack, which also removes the VBScript dependency.

// Bring us in

Tell us about the software your business runs on.

A new build, a system that’s hard to use, a stuck project or a prototype that needs to go live. An engineer, not a salesperson, will get back to you.

202-88-MAGIC · or email info@effortlesspresence.com