+48 501 250 220

Monolith als Web-Service nutzen und das Neue daneben bauen

Ihr Altsystem läuft und enthält Regeln, die niemand neu schreiben will. Wir stellen seine Logik als Web-Service bereit und schließen bekannte Lücken einmalig. Vergleichstests prüfen, ob die Funktion gleich bleibt, und das Neue entsteht daneben im neuen Stack.

Legacy-Review anfragen (mit API-Eignung) Zur Leistung Migration und Modernisierung
  • ColdFusion und Lucee seit 2015 in Produktivsystemen, PHP seit 2012
  • Schnittstellen mit REST und SOAP
  • Antwort innerhalb eines Werktags
Ein großer schraffierter Block mit einer orange umrandeten Öffnung an der rechten Seite; von der Öffnung führen fünf dünne Linien zu fünf kleinen Quadraten

Wann ein Altsystem als Web-Service sinnvoll ist

Diese drei Lagen sprechen dafür, das Altsystem als Web-Service weiter zu nutzen.

Ein neues Frontend oder eine neue Anwendung soll die Logik nutzen

Ihr Altsystem berechnet, prüft oder erzeugt etwas, das auch ein neues Frontend, eine neue Anwendung oder ein neuer Partner braucht. Die Logik ein zweites Mal zu bauen wäre teuer, und beide Fassungen würden auseinanderlaufen.

Ein Testbericht oder eine Kundenanfrage nennt Lücken

Ein professioneller Penetrationstest oder der Fragebogen eines Kunden nennt Schwachstellen, etwa Cross-Site-Scripting oder SQL-Injection. Ein Neuschreiben dauert in dieser Lage oft Jahre, die Lücken sollen aber früher geschlossen sein. Ist das Ergebnis dringend oder das System unbekannt, beginnen wir mit der 48-Stunden-Notfall-Einschätzung.

Das Team will einen neuen Stack, doch die Regeln stehen nur im Code

Im alten System stecken Regeln, die niemand aufgeschrieben hat. Wird alles neu geschrieben, gehen sie leicht verloren.

Ein schraffierter Block, das Altsystem, in der Mitte; drei Anlässe zeigen darauf: ein neues Frontend als Fenster mit oranger Linie, ein Prüfbericht und ein Stapel neuer Bausteine

Ein Eingang zum alten System, das Neue daneben

Das alte System bleibt als ein Block bestehen und bekommt einen sauberen Eingang: eine API. Neue Anwendungen und Frontends rufen sie auf und hängen nicht am alten Code.

So entsteht das Neue Schritt für Schritt neben dem Alten. Fachleute nennen dieses Vorgehen Strangler-Fig-Muster (öffnet in einem neuen Fenster).

Ein großer schraffierter Block mit einer orange umrandeten Öffnung, von der dünne Linien zu fünf kleinen Knoten führen

So gehen wir vor: sechs Schritte, jeweils mit schriftlichem Ergebnis

  1. Review

    Wir klären, welche Funktionen den Wert des Systems ausmachen, etwa Regeln, Berechnungen und Dokumente, und welche mit der Oberfläche verwoben sind. Ergebnis ist die Funktionslandkarte: Was wir als Service bereitstellen und was im alten System bleibt, mit Begründung.

  2. Einmalige Absicherung

    Wir schließen bekannte Lücken mit dem Ziel, die Funktion nicht zu ändern, und vergleichen die Ergebnisse vor und nach der Änderung. Der Bericht nennt, was wir behoben haben, was offen bleibt und warum.

  3. API

    Wir stellen die Logik als API bereit, als REST mit JSON oder als SOAP mit XML, mit Anmeldung, Begrenzung der Aufrufe und Protokollierung. Die Beschreibung enthält Endpunkte und Beispiele für Anfragen und Antworten.

  4. Neues daneben

    Neue Funktionen entstehen im neuen Stack, der die API aufruft. Das alte System läuft dabei weiter. Der Plan hält die Reihenfolge der Etappen fest und den Rückweg, falls eine Etappe nicht trägt.

  5. Ersetzen, wo es sich lohnt

    Einzelne Teile des alten Codes ersetzen wir erst, wenn der Aufwand für Betrieb oder Änderung größer ist als der Aufwand für den Ersatz.

  6. Runbook

    Es beschreibt, wie die API betrieben, überwacht und aktualisiert wird, auch durch Ihre Leute oder einen anderen Dienstleister.

Neu schreiben oder als Service nutzen?

Kriterium Als Service nutzen Neu schreiben Unverändert lassen
Passt, wenn Die Logik funktioniert und ist wertvoll, bekannte Lücken sind zu schließen, und ein neuer Stack soll sie nutzen. Das Framework wird nicht mehr gepflegt, es gibt keine Tests, und die Geschäftsregeln lassen sich aufschreiben. Das System ist stabil, in einer unterstützten Version, und niemand braucht einen neuen Stack.
Was sich ändert Wir sichern das alte System einmal ab und geben ihm eine API. Neues entsteht daneben. Alles entsteht neu. Regeln und Daten ziehen in das neue System um. Nichts.
Grenze Nicht jedes System eignet sich. Der Review zeigt es. Bis zur Ablösung laufen zwei Systeme, und Regeln, die niemand aufgeschrieben hat, können verloren gehen. Neue Anwendungen können die Logik nicht nutzen, und bekannte Lücken bleiben offen.

Was wir nicht versprechen

  • Nicht jedes System lässt sich als Service nutzen. Ist die Logik mit der Oberfläche verwoben, ordnen wir sie zuerst. Das zeigt der Review.
  • Die einmalige Absicherung ist kein Penetrationstest, kein Zertifikat und keine Garantie, dass keine Lücken bleiben. Penetrationstests führen wir nicht durch. Wir beheben Lücken, die Berichte nennen oder die wir im Review finden.
  • Dass sich das Verhalten nicht ändert, belegen die Vergleichstests nur für die geprüften Abläufe.
  • Eine Ersparnis gegenüber dem Neuschreiben nennen wir erst, wenn der Review den Aufwand beziffert hat.
Ein Rahmen mit drei Kästen für das, was zur Leistung gehört; außerhalb ein gestrichelter Kasten für das, was nicht dazugehört; das Stück des Rahmens dazwischen ist orange

Sicherer Zugang zum alten System

Die API soll der einzige Zugang von außen ins alte System sein und hinter einer Firewall stehen. Auf Wunsch setzen wir eine WAF mit Regeln für Ihre Anwendung davor. Das senkt das Risiko, beseitigt es aber nicht, und es ersetzt nicht das Beheben der Lücken.

Wie wir Netz, Server und Administrationszugang absichern, beschreibt die Leistung Linux-Betrieb und Infrastruktur.

Drei Linien von links laufen in ein schmales, orange umrandetes Tor; von dort führt eine einzige Linie in einen großen schraffierten Block, das alte System

Erfahrung unserer Ingenieure mit Altsystemen und Schnittstellen

Systemtypen
Plattformen zur Kreditabwicklung, Hypothekenfinanzierung und Leasing sowie Systeme zur Erzeugung von Dokumenten und Verträgen

So arbeiten wir an Ihrem alten System

  • Code, Zugangsdaten und Dokumentation bleiben bei Ihnen.
  • Änderungen am alten System machen wir erst nach Ihrer Freigabe, mit Vergleichstests und einem Rückweg.
  • Wir sagen Ihnen auch, wenn sich der Weg über einen Service nicht lohnt.

Und wenn bei uns jemand ausfällt? Die Dokumentation erstellen wir auf Wunsch. Das Repository liegt in der Regel bei Ihnen. Eine Vertretung stellen wir auf Wunsch.

Mehr dazu unter Erfahrung und So arbeiten wir.

Links ein Blatt mit Textzeilen und einer Unterschriftszeile mit orangem Haken; ein Pfeil zeigt auf einen gestrichelt gezeichneten Server rechts

Der erste Schritt: Legacy-Review mit API-Eignung

Legacy-Review

Für Unternehmen mit einem System, das niemand mehr genau kennt: vor einem Update, vor einer Migration oder beim Wechsel des Dienstleisters.

  • Inventar der Versionen und Abhängigkeiten
  • Landkarte aus Anwendung, Datenbank, Server und E-Mail
  • Risikoregister zu Sicherheit, Support und Wissen
  • Bewertung der Backups und der Wiederherstellung
  • Empfehlung „bleiben, Version anheben oder migrieren“ mit Optionsmatrix, die auch „in den Container“ und „als API bereitstellen“ enthält
  • Aufwandsschätzung in Tagen

Der Preis gilt für ein System, also eine Anwendung mit ihrer Datenbank und ihrem Server. Weitere Systeme bepreisen wir einzeln.

Was das Ergebnis enthält

Ein schriftlicher Bericht mit Bestandsaufnahme, Risikoregister, Empfehlung und Aufwandsschätzung. Der Bericht gehört Ihnen.

ab 3.800 € zzgl. USt.

In der Regel 5 Werktage

Legacy-Review anfragen

48-Stunden-Notfall-Einschätzung

Für Unternehmen, deren Entwickler oder Dienstleister plötzlich weg ist und deren System trotzdem weiterlaufen muss.

  • Bestandsaufnahme: Versionen, Abhängigkeiten, Zugänge, Backups, geplante Tasks, Datenquellen und Mailversand
  • Liste der Risiken, die sofort Aufmerksamkeit brauchen
  • Stabilisierungsplan für die ersten 5 Tage und für die ersten 30 Tage
  • kurze Besprechung der Ergebnisse

Das Ergebnis liegt 48 Stunden nach Zugang zum System vor. Änderungen am Produktivsystem und weitere Arbeiten erfolgen nur nach Ihrer Zustimmung.

Was das Ergebnis enthält

Ein schriftlicher Befund mit dem Zustand des Systems, den Sofortrisiken und dem Stabilisierungsplan. Der Befund gehört Ihnen.

ab 1.900 € zzgl. USt.

In der Regel 2 Werktage

48-Stunden-Einschätzung anfragen

Fragen zum Altsystem als Web-Service

Müssen wir unser System neu schreiben, um einen neuen Stack zu nutzen?

Nein. Läuft das alte System, stellen wir seine Logik als API bereit und schließen einmalig bekannte Lücken. Die Funktion soll dabei erhalten bleiben, Vergleichstests prüfen das. Das Neue bauen wir daneben im neuen Stack, der diese API nutzt.

Ein Neuschreiben lohnt sich selten. Es kommt infrage, wenn das Framework nicht mehr gepflegt wird, es keine Tests gibt und sich die Geschäftsregeln aufschreiben lassen. Ob das bei Ihnen zutrifft, klärt der Legacy-Review.

Verändert die API das Verhalten des alten Systems?

Das Ziel ist, dass die Funktionen unverändert bleiben. Bevor wir etwas ändern, halten wir die Ergebnisse der geprüften Abläufe fest und vergleichen sie nach der Absicherung mit dem Stand davor. So fallen Abweichungen sofort auf.

Für Abläufe, die niemand geprüft hat, gibt es bei gewachsener Software keine Garantie. Deshalb legen wir mit Ihnen fest, welche Abläufe zählen.

Entwickeln und integrieren Sie Schnittstellen (REST, SOAP)?

Ja. Wir entwickeln Schnittstellen und binden Systeme an, mit REST und JSON ebenso wie mit SOAP und XML, einschließlich der Synchronisation von Daten zwischen Anwendungen. Typische Anwendungen beschreiben wir unter Entwicklung und Integration.

Können Sie ein System ohne Dokumentation übernehmen?

Ja, dafür ist der Legacy-Review da. Zuerst erfassen wir, was vorhanden ist: Versionen, Abhängigkeiten, geplante Tasks, Datenquellen und Mailwege. Dazu prüfen wir, ob sich die Sicherungen einspielen lassen.

Dass wir Ihr System noch nicht kennen, ist der Normalfall und kein Hindernis. Erst mit dem Befund sagen wir, was das System braucht und was die laufende Betreuung umfassen würde. Der Bericht gehört Ihnen.

Wer pflegt den alten Code nach der Absicherung?

Das entscheiden Sie. Code und Dokumentation bleiben bei Ihnen, und mit dem Runbook und der Beschreibung der API kann Ihr Team oder ein anderer Dienstleister weiterarbeiten.

Auf Wunsch übernehmen wir die laufende Pflege im Rahmen von Übernahme und Wartung.

Wie lange dauert es, ein Altsystem als Service bereitzustellen, und was kostet es?

Eine belastbare Zahl gibt es erst nach dem Review. Dauer und Kosten hängen davon ab, wie sauber die Logik von der Oberfläche getrennt ist, wie viele Funktionen Sie als Service brauchen und wie viele Lücken zu schließen sind.

Der Legacy-Review schätzt den Aufwand in Arbeitstagen. Danach machen wir Ihnen ein Angebot, bevor Sie etwas beauftragen.

Brauchen wir dafür einen anderen Server?

Meist nicht. Die API betreiben wir auf dem vorhandenen Server oder davor, hinter einer Firewall und auf Wunsch mit einer WAF, deren Regeln zu Ihrer Anwendung passen.

Läuft das System auf einer Plattform ohne Sicherheits-Updates, ist ein Update oder Umzug ohnehin ein Thema. Das erfasst der Review mit.

Reicht eine WAF aus?

Allein nicht. Eine WAF filtert typische Angriffe vor der Anwendung und verschafft Zeit, schließt aber keine Lücke im Code. Deshalb verbinden wir sie mit dem Beheben bekannter Schwachstellen, einer Segmentierung des Netzes und einem Administrationszugang nur per VPN.

Eine WAF mit Regeln für Ihre Anwendung löst weniger Fehlalarme aus und schützt realistischer als die Standardkonfiguration. Lässt sich der Code nicht schnell ändern, ist eine WAF mit Isolation eine Brücke bis zum Update. Das Risiko sinkt dann, ist aber nicht beseitigt.

Welches Altsystem soll weiterleben?

Nennen Sie uns Technologie und Version, was das System leistet und was Neues darauf zugreifen soll. Wir antworten innerhalb eines Werktags.

Felder mit dem Zusatz „optional“ können leer bleiben.

Antwort per E-Mail

Für den Rückruf genügt Ihre Telefonnummer: Notfälle rund um die Uhr, sonst innerhalb eines Werktags.

Um welches System und welche Technologie geht es, was möchten Sie erreichen? Bitte senden Sie keine Passwörter oder vertraulichen Unterlagen.

Antwort innerhalb eines Werktags · unverbindlich

Wir verwenden Ihre Angaben nur, um Ihre Anfrage zu beantworten. Prownex IT Services Sp. z o. o. ist für die Verarbeitung verantwortlich. Speicherdauer und Ihre Rechte beschreibt die Datenschutzerklärung.