SaaS-Engineering

Tech-Stack modernisieren ohne Komplett-Rewrite: schrittweise Migration, Go und Next.js

Von Mostafa EL MouaddineVeröffentlicht am 12. Oktober 202610 Min. Lesezeit

Einen Tech-Stack zu modernisieren heißt, Schritt für Schritt das zu ersetzen, was Auslieferung, Sicherheit oder Wachstum bremst – ohne den Betrieb zu unterbrechen und ohne alles auf einmal neu zu schreiben. Der sicherste Weg ist die schrittweise Migration: eine Fassade vor das Bestandssystem, dann ein Modul nach dem anderen. Für eine SaaS-Architektur bilden Go für die Services, Next.js und TypeScript für die Oberfläche sowie Python für KI und Daten eine solide Kombination – vorausgesetzt, das Team kann sie auch betreiben, was nicht immer der Fall ist.

Woran erkennt man, dass ein Tech-Stack modernisiert werden muss?

Eine ältere Technologie ist an sich kein Problem. Zum Problem wird ein Stack, wenn er mehr kostet, als er einbringt: Jede Weiterentwicklung dauert länger als geplant, und das Team ist mehr damit beschäftigt, das System zu umgehen, als es voranzubringen. Die entscheidenden Signale lassen sich beobachten:

• Langsame, riskante Releases: Jedes Deployment erfolgt von Hand, oft am Abend, mit der Sorge, dabei etwas anderes kaputtzumachen.
• Abhängigkeiten am Ende ihres Lebenszyklus: Framework, Programmiersprache oder Betriebssystem erhalten keine Sicherheitsupdates mehr.
• Konzentriertes Wissen: Nur ein oder zwei Personen verstehen den Kern des Systems, und Fachkräfte für diese Technologie zu finden, wird schwierig.
• Teure Skalierung: Die einzige Antwort auf mehr Nutzer ist ein größerer Server, und Lastspitzen führen zu Störungen.
• Blockaden im Produkt: Es ist unmöglich, eine API für einen Partner zu öffnen, eine Sprache hinzuzufügen, einen zweiten Kunden auf derselben Plattform aufzunehmen oder ein KI-Modell sauber anzubinden.

Ein einzelnes Signal lässt sich oft lokal beheben. Kommen mehrere zusammen, lautet die Frage nicht mehr, ob modernisiert werden soll, sondern in welcher Reihenfolge. Bevor Sie Technologien auswählen, halten Sie die fachlichen Ziele und Rahmenbedingungen schriftlich fest – genau dafür ist ein gutes Lastenheft für Softwareprojekte da.

Anwendung neu aufbauen: Warum ein Komplett-Rewrite meist die falsche Wahl ist

Die Versuchung ist groß, alles wegzuwerfen und bei null anzufangen. In der Praxis friert eine „Big-Bang“-Neuentwicklung das Produkt für Monate ein: Das Altsystem wird für die Kunden weiterentwickelt, das neue System jagt einem beweglichen Ziel hinterher, und die finale Umstellung bündelt alle Risiken an einem einzigen Wochenende. Implizite Geschäftsregeln, die nie dokumentiert wurden, aber sehr wohl im Code stecken, gehen dabei als Erstes verloren.

Die bewährte Alternative ist die schrittweise Migration, oft Strangler Fig Pattern genannt (nach der Würgefeige, ein Bild, das Martin Fowler bekannt gemacht hat): Das neue System wächst um das alte herum und ersetzt es Funktion für Funktion.

1. Eine Fassade (Reverse Proxy oder API-Gateway) vor die bestehende Anwendung setzen, ohne dass sich für die Nutzer etwas ändert.
2. Einen ersten, begrenzten Bereich wählen, der nützlich und risikoarm ist – etwa die Suche, die Benachrichtigungen oder ein Reporting-Modul.
3. Diesen Bereich im neuen Stack neu bauen und den zugehörigen Traffic über die Fassade dorthin leiten.
4. Messen, korrigieren und mit dem nächsten Bereich weitermachen.
5. Den alten Code laufend entfernen – sonst wartet das Team auf unbestimmte Zeit zwei Systeme.

Jeder Schritt liefert Nutzen und bleibt umkehrbar: Verhält sich der neue Service fehlerhaft, leitet die Fassade den Traffic so lange zum alten zurück, bis der Fehler behoben ist. Die eigentliche Schwierigkeit liegt woanders: Während der Übergangsphase teilen sich alter und neuer Code oft dieselben Daten. Legen Sie von Anfang an fest, welches System für welche Daten maßgeblich ist, und schirmen Sie den neuen Code durch eine Übersetzungsschicht (einen „Anti-Corruption Layer“) von den Eigenheiten des historischen Datenmodells ab – sonst wandern die technischen Schulden mit dem Code mit.

Warum Go und Next.js für eine SaaS-Architektur?

Next.js, Go, Python und TypeScript bilden den Kern-Stack von Codevista Innovations. Die Gründe sind betrieblicher Natur und gelten für jedes Team, das diese Kombination prüft.

Go für Backend-Services

• Einfache Nebenläufigkeit: Mit Goroutines und Channels lassen sich Anfragen, Message Queues und externe Aufrufe parallel verarbeiten, ohne Threads von Hand zu verwalten.
• Ein einziges Binary: Ein Go-Service wird zu einer eigenständigen ausführbaren Datei kompiliert, die vollständig statisch sein kann. Der Container bleibt schlank, und auf dem Server muss keine Laufzeitumgebung installiert werden.
• Vorhersehbare Performance: kompilierte Sprache, schneller Start, in der Regel geringer Speicherbedarf. Die Infrastruktur lässt sich leichter dimensionieren.
• Unkomplizierter Betrieb: umfangreiche Standardbibliothek (HTTP, JSON, Kryptografie), integrierte Werkzeuge für Tests, Formatierung und Profiling, Cross-Compilation für andere Systeme.
• Code, den das ganze Team lesen kann: Die Sprache ist bewusst schlank gehalten, was Code-Reviews und das Onboarding neuer Entwickler erleichtert.

Go eignet sich besonders für APIs, Integrationsdienste (Zahlung, ERP, Messaging), asynchrone Verarbeitung und Komponenten, die hohe Last aushalten müssen.

Next.js und TypeScript für das Frontend

Next.js ergänzt React um serverseitiges Rendering und statische Generierung. Öffentliche Seiten kommen bereits fertig aufgebaut im Browser an – das zählt für die Suchmaschinenoptimierung, für die Ladezeit auf Mobilgeräten und für das Teilen in sozialen Netzwerken. Das React-Ökosystem, eines der verbreitetsten im Frontend, liefert Komponenten und UI-Bibliotheken und erleichtert die Personalsuche.

TypeScript bringt typisierte Verträge: Die mit dem Backend ausgetauschten Daten werden einmal beschrieben, zum Beispiel auf Basis eines OpenAPI-Schemas, das die Go-Services erzeugen. Ein umbenanntes Feld in der API lässt dann den Build scheitern, nicht die Produktion. Schließlich erleichtert Next.js die schrittweise Migration: Mit seinen Rewrite-Regeln liefert es die neuen Seiten aus und leitet die übrigen an die Altanwendung weiter, Seite für Seite.

Python dort, wo KI und Daten zu Hause sind

Python bleibt die Referenzsprache für Daten und künstliche Intelligenz: Datenverarbeitung, maschinelles Lernen, SDKs der Anbieter von Sprachmodellen. Statt diese Aufgaben in Go zu zwingen, ist es besser, sie in eigene Python-Services auszulagern, die über eine interne API oder eine Message Queue aufgerufen werden. Diese Aufteilung hält jede Sprache auf ihrem Terrain und erlaubt strengere Sicherheitsregeln für den Bereich, der sensible Daten verarbeitet – etwa wenn KI-Agenten orchestriert werden. Der Preis dafür: eine Sprache mehr, die gewartet, getestet und überwacht werden muss. Beschränkt sich die KI auf ein paar API-Aufrufe bei einem Modellanbieter, reicht oft ein Go- oder TypeScript-Service.

Wann sind Go und Next.js nicht die richtige Wahl?

Kein Stack passt überall. In diesen Fällen sind andere Optionen – oder der Status quo – vernünftiger:

• Das Team beherrscht bereits einen gesunden Stack. Eine gut gewartete, getestete und regelmäßig ausgelieferte Laravel-, Django-, Java- oder .NET-Anwendung rechtfertigt keinen Sprachwechsel. Modernisieren Sie zuerst die Arbeitsweise, dann die Technologie.
• Ein einfaches internes Backoffice. Für ein Verwaltungstool ohne Lastanforderungen liefert ein Komplett-Framework nach dem „Batteries included“-Prinzip mit generierter Administrationsoberfläche oft schneller als Go-Services.
• Eine Anwendung komplett hinter einem Login. Ohne öffentliche Seiten entfällt das SEO-Argument für Next.js; eine klassische React-Anwendung kann genügen und ist einfacher zu hosten.
• Eine Fachdomäne mit sehr vielen Regeln. Go setzt auf Einfachheit und nimmt dafür etwas Wiederholung in Kauf; manche Teams bevorzugen eine ausdrucksstärkere Sprache, um eine komplexe Domäne abzubilden.
• Keine Betriebskapazitäten. Mehrere Services bedeuten Monitoring, zentrales Logging und automatisierte Deployments. Ohne diese Grundlage ist ein gut strukturierter Monolith sicherer als schlecht überwachte Microservices.

Berücksichtigen Sie auch das Tempo von Next.js: Die Hauptversionen entwickeln sich schnell, und mit diesen Updates Schritt zu halten, erfordert eingeplante Zeit.

Multi-Tenant-Architektur: auf internationales Wachstum vorbereiten

Ein Multi-Tenant-SaaS bedient viele Kundenorganisationen – die Mandanten (Tenants) – auf ein und derselben Plattform. Wer mehrere Länder ins Visier nimmt, vervielfacht die Zahl der Mandanten und die Anforderungen an ihre Trennung. Das Isolationsmodell muss früh gewählt werden, denn später lässt es sich nur schwer ändern:

• Gemeinsame Datenbank mit Mandanten-ID: das wirtschaftlichste Modell, aber jede Abfrage muss korrekt filtern; die Row-Level Security von PostgreSQL ist eine sinnvolle zusätzliche Absicherung.
• Ein Schema pro Mandant: bessere Trennung, aber aufwendigere Migrationen.
• Eine Datenbank pro Mandant: starke Isolation und die Möglichkeit, Daten Land für Land zu lokalisieren, um den Preis eines komplexeren Betriebs.

Über die Datenbank hinaus verlangt der internationale Markt konkrete Entscheidungen: mehrere Sprachen, darunter das von rechts nach links geschriebene Arabisch, Zeitzonen, Währungen, Zahlungsmittel (in Marokko das CMI, das Centre Monétique Interbancaire, für Kartenzahlungen, je nach Sitzland der fakturierenden Gesellschaft andere Anbieter wie Stripe) und Compliance. In Marokko regelt das Gesetz 09-08 (loi 09-08) die Verarbeitung personenbezogener Daten, einschließlich ihrer Übermittlung ins Ausland; zuständige Aufsichtsbehörde ist die CNDP, die marokkanische Datenschutzbehörde. Jedes Zielland kann eigene Vorschriften hinzufügen: Prüfen Sie diese, bevor Sie entscheiden, wo die Daten gehostet werden. Unser Leitfaden zur individuellen SaaS-Entwicklung in Marokko erläutert diese Abwägungen im Detail.

In welcher Reihenfolge modernisiert man eine Anwendung?

Die Reihenfolge der Schritte zählt ebenso viel wie die gewählten Technologien. Eine Abfolge, die die Risiken begrenzt:

1. Audit und Bestandsaufnahme: Inventar der Komponenten, Abhängigkeiten, Datenflüsse und Problemstellen, geordnet nach fachlichem Wert und Risiko.
2. Grundlage für die Auslieferung: Continuous Integration und Continuous Deployment, automatisierte Tests für die kritischen Abläufe, Monitoring. Ohne dieses Sicherheitsnetz ist jede Migration ein Glücksspiel.
3. Fassade und erster Bereich: Einrichtung des Proxys, dann Migration eines Moduls mit hohem Nutzen und geringem Risiko, um das Vorgehen zu validieren.
4. Schrittweises Next.js-Frontend: zuerst die öffentlichen Seiten, bei denen serverseitiges Rendering für Auffindbarkeit und Ladezeit den Unterschied macht, dann die Anwendungsmasken.
5. Daten zuletzt: Die Datenbank ist der riskanteste Teil; migrieren Sie sie Domäne für Domäne, mit Prüfskripten und einem Rollback-Plan.
6. Stilllegung und Wissenstransfer: Jedes ersetzte Modul verschwindet aus dem Altsystem, und das interne Team baut seine Kompetenzen auf dem neuen System im Laufe des Projekts auf, nicht erst am Ende.

Führen Sie dieses Vorhaben in kurzen Iterationen durch, mit einer Methode wie Scrum: Jeder Sprint liefert einen überprüfbaren Umfang auf einer Vorproduktionsumgebung (Staging) aus, bevor er in Produktion geht. Wenn Sie die Arbeit ganz oder teilweise an einen Dienstleister vergeben, helfen Ihnen unsere Kriterien zur Wahl einer Entwicklungsagentur in Casablanca, die richtigen Fragen zu stellen – insbesondere zur Datensicherheit.

Codevista Innovations begleitet dieses Vorgehen – von der Analyse Ihres bestehenden Stacks bis zum Entwurf von Multi-Tenant-Architekturen mit Go und Next.js, von Casablanca aus für Marokko und den internationalen Markt. Unsere Projekte beginnen mit einer Discovery- und Designphase und schreiten dann in zweiwöchigen Sprints voran, die zu Ihrer Abnahme auf Staging ausgeliefert werden. Um Ihre Situation einzuordnen, erzählen Sie uns von Ihrem Projekt.

Häufige Fragen

Wie lange dauert die Modernisierung einer bestehenden Anwendung?

Das hängt von der Größe des Systems, der Qualität des bestehenden Codes und der Verfügbarkeit des Teams ab: Eine pauschale Zahl wäre nicht seriös. Der Vorteil der schrittweisen Migration liegt gerade darin, nicht von einem einzigen Umstellungstermin abzuhängen. Ein erster Bereich kann lange vor Projektende in Produktion gehen, danach folgen die weiteren Module nach ihrem Nutzen. Ein erstes Audit liefert eine realistische Reihenfolge und Schätzung.

Kann man die bestehende Datenbank beim Umstieg auf Go und Next.js behalten?

Ja, und anfangs ist das oft sogar empfehlenswert. Go verfügt über ausgereifte Treiber für die wichtigsten relationalen Datenbanken, darunter PostgreSQL, MySQL und SQL Server. Die neuen Services können also während der Übergangsphase in der bestehenden Datenbank lesen und schreiben. Das Schema wird anschließend Domäne für Domäne migriert, sobald die Services stabil laufen – mit Skripten zur Konsistenzprüfung und einem Rollback-Plan.

Go oder Node.js für das Backend eines SaaS?

Beides lässt sich gut begründen. Mit Node.js können Frontend und Backend TypeScript gemeinsam nutzen, was einem kleinen Team das Leben erleichtert. Go bietet ein einziges Binary und native Nebenläufigkeit, die ohne besondere Konfiguration alle Prozessorkerne nutzt – hilfreich für APIs unter hoher Last und für Integrationsdienste. Ausschlaggebend sind meist eher die Kompetenzen des Teams und die Betriebsanforderungen als die reine Performance.

Lohnt sich Next.js für eine Fachanwendung ohne SEO-Anforderungen?

Weniger. Das serverseitige Rendering von Next.js dient vor allem öffentlichen Seiten: Auffindbarkeit, Ladezeit, Teilen in sozialen Netzwerken. Für ein internes Tool, das vollständig hinter einem Login liegt, kann eine klassische React-Anwendung genügen. Next.js bleibt sinnvoll, wenn dasselbe Produkt eine öffentliche Website und einen Kundenbereich vereint oder wenn Sie ein einziges Framework für Routing, Internationalisierung und Serveraufrufe möchten.