Classic ASP Migration
for businesses in Australia, New Zealand, the UK and the US.
Classic ASP was superseded in 2002 and IIS still runs it, so the .asp files kept working. That is the whole reason these applications are still in production twenty years later.
- Independent No licence commission, no reseller agenda
- 18+ yrs Building business software
- Fixed Price scopes, no surprises
- AU NZ UK US Perth-based, working remotely
Still served by IIS, still written in VBScript
Classic ASP applications are usually internal: a booking system, a stock lookup, a customer portal built when that was novel. They are typically a set of .asp files with SQL queries written directly into the page, a design that was normal at the time and is now the main security concern.
Because IIS still executes them, nothing forces a change. The risk is not that they stop running. It is that they are internet-facing, built before parameterised queries were routine, and nobody has looked at them in a decade.
Your Classic ASP project, end to end
Three stages. Scoped and fixed-price before anything starts, delivered by the founder, and your existing system stays running until cutover.
-
Week 0
Read the system as it is
We go through the existing application and record what it actually does, including the parts nobody documented. You get a written inventory and a fixed price before any build starts.
-
Weeks 1-N
Rebuild and run in parallel
The replacement runs beside the original until the numbers reconcile. The old system stays untouched and switched on the whole time.
-
Cutover
Go live and hand over
Cutover on a date you choose, then thirty days of support. Source code, documentation and credentials are handed to you, in your name.
What the work actually is
Same application, without the SQL injection
We read the .asp files, extract the business logic and the queries, and rebuild on a current stack. The database usually stays where it is; the application layer is what changes.
What you have now
- .asp files with inline VBScript
- SQL written directly into the page
- COM objects registered on the server
- An IIS server nobody upgrades
Same application, without the SQL injection
We read the .asp files, extract the business logic and the queries, and rebuild on a current stack. The database usually stays where it is; the application layer is what changes.
See how a project runsWhat you end up with
- A current web application with parameterised queries and real authentication
- The same screens and workflow, so staff are not retrained
- A server that can be patched without fear
The 5 pieces of Classic ASP work we are asked for
Most engagements are some combination of these, and most start with the first.
Read the pages
Business logic and SQL extracted from the .asp files and documented, which is often the first written record of how it works.
Deal with the security debt
Inline SQL replaced with parameterised queries, and authentication rebuilt properly rather than checked against a session variable.
Replace the COM dependencies
Server-registered COM objects identified and their behaviour reproduced without them.
Rebuild the application
Same screens and workflow on a current stack, so the people using it do not need retraining.
Keep the database
If SQL Server is already behind it, it usually stays. Changing two things at once makes reconciliation harder than it needs to be.
Where you are now
It works, and nobody will touch it
- VBScript superseded in 2002 and unchanged since
- SQL written straight into the page, often unparameterised
- COM objects registered on a server nobody dares rebuild
- Internet-facing, and nobody has reviewed it in years
After
Supported, documented and yours
- Parameterised queries and proper authentication
- A stack that receives security patches
- No server-registered COM dependencies
- A server you can rebuild from documentation
Scoped and quoted before you commit. You own the code, the documentation and the credentials at the end of it.
Get a fixed-price scopeClassic ASP questions
Is Classic ASP a security risk?
The language itself is not the issue. The pattern is: SQL written inline and unparameterised, authentication rolled by hand, and no review in a decade. If the application is internet-facing, that combination is worth taking seriously.
Can we keep the database and only replace the application?
Usually yes, and it is the approach we prefer. If SQL Server is already behind it, changing the application alone keeps the reconciliation simple and the project shorter.
What about the COM objects registered on the server?
We identify what each does. They are commonly handling file uploads, PDF generation or an email send, all of which have straightforward modern equivalents.
Can it be done in stages?
Yes. Page by page behind the same address is a normal approach, so you are never running a big-bang cutover on an application the business depends on.
IIS still runs it. Why change anything?
That is a fair question and sometimes the answer is not yet. The trigger is usually a security review, a Windows Server upgrade, or needing a change that nobody will make. Until one of those arrives, doing nothing is a defensible position.
Sending your details…
You can stay on this page while we send it.
Tell us what you are running
What the system does, roughly how old it is, and what is forcing the question. We will come back with a straight answer and a fixed-price scope, even if the answer is to leave it alone.
Prefer a quick chat? Call 0425 531 127. We answer the phone in Perth.
