Classic ASP modernisation

Two different answers, and both matter. Classic ASP itself is still a supported component of IIS. Windows Server 2025 ships it, so on paper it's supported well into the 2030s.

VBScript is the other answer. Microsoft has announced its retirement from Windows in phases. In the current phase it's deprecated but installed and switched on by default. In the next, from around 2026 to 2027, it becomes an optional feature that's off by default. Then it's removed. Classic ASP uses the same VBScript engine as the rest of Windows, so a Classic ASP application written in VBScript stops working on a server where VBScript isn't installed.

The practical position in September 2026: your Classic ASP application runs today, and the clock on the language underneath it is running. A server rebuild or an operating system upgrade is when it usually bites.

Twenty years of a business in a few hundred .asp files. Include files everywhere, SQL written inline in the pages, a mix of VBScript and the occasional JScript, session variables doing the work of a data model, and a database that's usually SQL Server and usually fine.

The rules are in there. They're just spread across pages in a way that nobody has mapped, which is why the first job is to map them.

Contain it. Pin the server. Document how it's built and deployed. Make sure VBScript stays installed on the server through any update, and that a rebuild of the server is a known procedure rather than a discovery. This buys time, and for a small internal application it can be the whole answer for a while.

Migrate to ASP.NET Core, page by page. The usual path. A new application sits behind a reverse proxy alongside the old site and takes over pages in order of value. The inline SQL becomes a proper data layer; the VBScript rules become C#. The old site keeps serving whatever hasn't moved.

Replace it. Right when the application's shape no longer fits the business, or when the pages are so tangled that porting them costs more than designing from the rules. Even then, replace alongside, with the data shared and the old site kept until the new one has proven itself.

The assessment reads the pages and prices each path as a fixed number.

1. Map it. Every page, every include, every SQL statement, every session variable and every integration, written down as a system description with the rules made explicit.
2. Safety net. Source control, a documented build of the old site, a test environment, a backup that's been restored.
3. A proxy in front. The ASP.NET Core application handles the pages it owns and passes everything else through to Classic ASP. Login is bridged so users see one site.
4. Data layer once. The inline SQL is gathered into one place, so the rules exist once and both applications can use them.
5. Pages in order of value. Each rebuilt, tested on a copy, run in staging on the same data, checked by the people who use it, then switched. The old page stays reachable until the new one has proven itself.
6. Retire Classic ASP when the last page that matters has moved, before or after VBScript's removal, on your schedule rather than Microsoft's.

Usually SQL Server, occasionally Access, and either way it's the part that carries forward unchanged. Old and new applications share the same database throughout, so there's no data move unless an Access file has to become a SQL Server database first. Any change to the data is tested on a copy, then in staging, before anything connects to live.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Classic ASP application it counts the pages, maps where the rules and the SQL live, and prices containment, migration and replacement as fixed numbers. What drives the price and the payment terms each have a page.

The obvious one has a plan attached: VBScript is leaving Windows in phases, and a Classic ASP application in VBScript leaves with it. The date isn't fixed, which is worse than a fixed date, because it arrives as a surprise during a server rebuild.

The slower one is people. Classic ASP hasn't been taught for twenty years. The developer who can read yours is the same one who's retiring.

Map it, contain it, then move it on your schedule. Marc Allington has built web applications in Classic ASP and builds on ASP.NET Core now, so both ends are familiar. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment.