Cloud-Migration einer Legacy-Anwendung

Die Kernanwendung — Backend, zentrale API und Geschäftslogik — lief als PHP-Monolith und sollte das auch bleiben. Darin steckten aber auch viele begleitende Aufgaben: wiederkehrende API-Abrufe, Datenverarbeitung, Report-Generierung und der Versand transaktionaler E-Mails — ausgeführt als Cronjobs und lokale Scripts auf einer einzelnen Maschine.

Genau diese Begleitprozesse machten Probleme. Die Report-Generierung griff direkt auf die Produktiv-Datenbank zu; aufwändige Auswertungen erzeugten Lastspitzen genau dort, wo das Tagesgeschäft lief. Der E-Mail-Versand lief inline im jeweiligen Prozess — bei langsamem Mailserver wartete der Nutzer mit. Migriert wurde deshalb nicht der ganze Monolith, sondern gezielt die Teile, die ihn ausbremsten.

Statt eines riskanten Komplett-Rewrites haben wir gezielt einzelne Teile aus dem Monolithen herausgelöst. Gemeinsam mit dem Auftraggeber haben wir zuerst die größten Painpoints identifiziert und nach Schmerz und Nutzen priorisiert — herausgelöst wurde Stück für Stück, während die Kernanwendung und der Betrieb unverändert weiterliefen.

Die herausgelösten Cronjobs und Scripts wurden zu event-getriebenen Lambda-Funktionen, orchestriert über EventBridge. S3 übernahm die Ablage von Artefakten und Reports, SES den Mailversand, RDS die Datenhaltung. Über mehrere Wochen wanderten so 20+ Begleitprozesse von der einzelnen Maschine in verwaltete, nutzungsbasiert abgerechnete AWS-Services.

Reports auf ein Datenbank-Replica. Der größte einzelne Hebel war die Einführung eines Datenbank-Replicas. Report-Jobs und alle nicht geschäftskritischen Prozesse greifen seither ausschließlich auf das Replica zu — vollständig losgelöst von der Produktiv-Datenbank. Eine schwere Auswertung kann das Tagesgeschäft nicht mehr ausbremsen, weil sie auf einer separaten Kopie läuft.

Transaktionale E-Mails asynchron über SES. Zuvor wurden E-Mails inline im jeweiligen Prozess per SMTP versendet — bei längeren Antwortzeiten des Mailservers musste der Nutzer mit warten. Heute schreibt der Nutzer-Prozess nur noch die Geschäftslogik und pro Mail einen Eintrag in eine separate, asynchrone SQS-Queue. Der Versand selbst läuft im Hintergrund über SES. Für den Nutzer entfällt jede zusätzliche Wartezeit.

20+ Begleitprozesse liefen nach mehreren Wochen auf AWS — ohne eine einzige Betriebsunterbrechung und ohne Eingriff in die Kernanwendung. Aus Cronjobs und lokalen Scripts wurden event-getriebene Lambda-Funktionen.

Aus permanent vorgehaltener Fixinfrastruktur wurde nutzungsbasierte Abrechnung. Die Produktiv-Datenbank ist von der Report-Last entkoppelt, der E-Mail-Versand aus dem kritischen Pfad genommen — das Tagesgeschäft läuft spürbar ruhiger.