Classic ASP hat das Web der späten Neunziger und frühen Zweitausender mit aufgebaut. Viele dieser Anwendungen laufen heute noch – im Bestellwesen, in Verwaltungstools, in internen Portalen. Das Problem ist nicht, dass sie schlecht gebaut wären. Das Problem ist, dass die Technologie stehengeblieben ist, während alles drumherum weitergezogen ist.
Wir lösen Classic ASP vollständig ab und überführen es auf Laravel im Backend und React im Frontend. Sauber getrennt, abgesichert und wartbar.
Automatisches Code-Assessment anfangen →
Woran man merkt, dass es Zeit wird
Classic ASP bekommt von Microsoft keine Weiterentwicklung mehr. Es läuft noch unter aktuellen IIS-Versionen, aber das ist Bestandsschutz, keine Zukunft. Die typischen Warnzeichen kennen Sie vermutlich:
- VBScript-Kenntnisse sind am Arbeitsmarkt praktisch verschwunden. Wer das System wartet, ist meist schon lange im Haus – und irgendwann weg.
- Jede kleine Änderung dauert ewig, weil Logik, Datenbankzugriffe und HTML in denselben Dateien stecken.
- Sicherheitsprüfungen fallen durch. Alter ASP-Code ist berüchtigt für SQL-Injection und Cross-Site-Scripting, weil Eingaben damals selten konsequent geprüft wurden.
Das letzte Zeichen ist das gefährlichste. Ein laufendes System mit offener Injection-Lücke ist keine ruhende Altlast, sondern ein aktives Risiko.
Das Kernproblem: alles klebt zusammen
Typischer Classic-ASP-Code mischt in einer einzigen Datei das HTML der Seite, die Geschäftslogik und die SQL-Abfragen direkt an die Datenbank. Das war schnell geschrieben und ist heute der Grund, warum sich niemand mehr herantraut. Eine Änderung an der Darstellung kann eine Datenbankabfrage zerschießen, und niemand sieht den Zusammenhang.
Genau hier setzt unsere Migration an. Wir zerlegen den verwobenen Code in drei klare Schichten:
- Controller nehmen Anfragen entgegen und steuern den Ablauf.
- Services enthalten die eigentliche Geschäftslogik – das Wissen, das Ihr Unternehmen ausmacht.
- React-Komponenten (TSX) kümmern sich allein um die Darstellung.
Was vorher untrennbar war, lässt sich danach einzeln verstehen, testen und ändern.
Sicherheit ist bei uns kein Extra, sondern Pflicht
Bei jeder ASP-Migration führen wir ein verpflichtendes Sicherheits-Audit durch. Wir gehen jeden Datenpfad durch und prüfen gezielt auf SQL-Injection und XSS. Diese Lücken werden nicht „mitgenommen“, sondern im Zuge der Migration geschlossen: parametrisierte Abfragen statt zusammengebauter SQL-Strings, konsequentes Escaping der Ausgaben, saubere Validierung jeder Eingabe.
Das Ergebnis ist nicht nur moderner Code, sondern Code, der die Prüfungen besteht, die alter ASP-Code reihenweise nicht bestanden hätte.
Wie wir vorgehen
Unsere Migration läuft in festen Rollen, jede mit einem klaren Auftrag:
- Analyse. Wir kartieren die Anwendung: welche Seiten, welche Logik, welche Datenbankzugriffe, welche Abhängigkeiten.
- Architektur. Wir entwerfen das Zielbild auf Laravel + React und legen das Datenmodell fest.
- Umsetzung. Der verwobene Code wird in Controller, Service und TSX überführt – Funktion für Funktion.
- Datenmigration. Die Bestandsdaten werden übernommen und dabei bereinigt, nicht nur kopiert.
- Qualitätssicherung. Inklusive des Sicherheits-Audits auf SQL-Injection und XSS.
Alles in Schritten, kein Big Bang. Das alte System bleibt am Netz, bis das neue jede Funktion nachweislich übernommen hat.
Vertiefung
- Classic ASP zu Laravel migrieren – wie die Backend-Logik konkret überführt wird.
- VBScript ablösen – was mit der serverseitigen Skriptlogik passiert.
Verwandte Technologien
Classic ASP tritt selten allein auf. In gewachsenen Web-Landschaften steht es oft neben anderen serverseitigen Skriptsprachen. Wenn bei Ihnen auch PHP 4/5 oder Perl-CGI im Einsatz ist, betrachten wir das gemeinsam – eine abgestimmte Migration ist günstiger als drei einzelne.
Häufige Fragen
Läuft unser ASP-System während der Migration weiter? Ja. Wir migrieren schrittweise, das Altsystem bleibt produktiv, bis die neue Version jede Funktion übernommen hat.
Was passiert mit unserer SQL-Server-Datenbank? Die Daten werden übernommen und im Zuge der Migration bereinigt. Das Zielsystem arbeitet sauber gegen das neue Datenmodell.
Wie geht ihr mit undokumentierten Sonderfällen um? Die finden wir in der Analyse. Genau dafür ist diese Phase da – das Wissen, das nur im Code steckt, machen wir wieder sichtbar.