Legacy-Software für die Cloud modernisieren: ISV-Playbook

Warum Modernisierung für ISVs strategisch notwendig ist

Legacy-Software-Produkte kämpfen auf drei Fronten gleichzeitig: Auf der Kostenseite steigen die Betriebskosten für On-Premises-Infrastruktur, während Cloud-native Wettbewerber mit niedrigeren Fixkosten und höherer Agilität operieren. Auf der Wettbewerbsseite fordern Enterprise-Kunden zunehmend Cloud-Deployment, SaaS-Modelle und Marketplace-verfügbare Lösungen als Kaufkriterium. Und auf der Technologieseite verhindert technische Schuld schnelle Innovationszyklen — jedes neue Feature erfordert überproportionalen Aufwand.

Für ISVs bedeutet Modernisierung nicht nur technologische Erneuerung, sondern gleichzeitig die Möglichkeit zur Geschäftsmodelltransformation: von einmaligen Lizenzgebühren zu wiederkehrenden SaaS-Umsätzen, von lokalen Kunden zu globaler Marketplace-Reichweite.

Die vier Modernisierungspfade im Überblick

Pfad 1: Lift-and-Shift (Rehosting)

Der einfachste Modernisierungspfad: Die bestehende Anwendung wird ohne Code-Änderungen auf AWS-Infrastruktur migriert. On-Premises-Server werden durch EC2-Instanzen ersetzt, lokale Datenbanken durch Amazon RDS.

Implementierung auf AWS

1. Infrastruktur-Assessment: Bestehende Server-Landschaft inventarisieren (AWS Application Discovery Service), Abhängigkeiten kartieren, Sizing für EC2-Instanztypen bestimmen.
2. Netzwerkarchitektur: VPC mit Public und Private Subnets, Security Groups als Firewall-Ersatz, NAT Gateway für ausgehenden Traffic aus privaten Subnets.
3. Datenmigration: AWS Database Migration Service (DMS) für Datenbankmigrationen (PostgreSQL, MySQL, Oracle, SQL Server). AWS Schema Conversion Tool für Datenbank-Plattformwechsel.
4. Server-Migration: AWS Application Migration Service (MGN) für automatisierte Server-Replikation und Cutover mit minimalem Downtime.
5. Validierung und Go-Live: Parallelbetrieb, Performance-Vergleich, Cutover, Monitoring-Setup mit Amazon CloudWatch.

Nach Lift-and-Shift: Das Produkt läuft in der Cloud, ist aber noch kein SaaS-Produkt. Es ist der Ausgangspunkt für weitere Modernisierung.

Pfad 2: Containerisierung (Replatforming)

Containerisierung bringt erhebliche Vorteile ohne vollständiges Re-Architecting: konsistente Deployment-Umgebungen, einfachere Skalierung, bessere Ressourcennutzung. Für ISVs ermöglicht Docker+ECS/EKS die Basis für mandantenfähige Deployments.

Docker und AWS Container Services

1. Applikation containerisieren: Dockerfile erstellen, lokale Tests durchführen, Multi-Stage-Builds für optimale Image-Größen nutzen. Container-Image in Amazon ECR (Elastic Container Registry) speichern.
2. Orchestrierungsplattform wählen: Amazon ECS (einfacher, weniger Overhead) für einfachere Workloads; Amazon EKS (Kubernetes) für komplexe Microservices-Architekturen oder wenn Kunden Kubernetes-Expertise mitbringen.
3. Service-Definition: ECS Task Definitions oder Kubernetes Deployments + Services erstellen. Resources (CPU, Memory) und Skalierungsregeln definieren.
4. Load Balancing: Application Load Balancer (ALB) für HTTP/HTTPS-Traffic, mit Path-based Routing für Multiple Services auf einem ALB.
5. CI/CD-Pipeline: AWS CodePipeline + CodeBuild für automatisiertes Build und Deployment. Jeder Git-Push löst automatisch Build, Test und Deployment aus.

Wann ECS, wann EKS?

Amazon ECS (Elastic Container Service)

AWS-eigene Container-Orchestrierung. Einfacher zu betreiben, weniger Konfigurationsaufwand, enger AWS-Service-Integration. Empfehlung für ISVs ohne dediziertes Platform-Engineering-Team.

Amazon EKS (Elastic Kubernetes Service)

Managed Kubernetes. Höherer initialer Aufwand, aber portabler (On-Prem + Multi-Cloud) und mit größerem Ökosystem. Empfehlung, wenn Kunden Kubernetes-Deployments im eigenen Account fordern (Silo-Modell).

AWS Lambda (Serverless)

Für event-getriebene Workloads und Microservices ohne persistenten State. Ideale Ergänzung zu Containerarchitekturen für Background-Jobs, Webhooks, API-Handler.

Pfad 3: Das Strangler Fig Pattern

Das Strangler Fig Pattern ermöglicht die schrittweise Ablösung eines Monolithen, ohne den laufenden Betrieb zu unterbrechen. Benannt nach dem Würgefeigenbaum (Ficus), der seinen Wirtsbaum langsam umwächst und schließlich ersetzt.

Implementierung mit Amazon API Gateway

1. API-Inventarisierung: Alle API-Endpunkte des Monolithen dokumentieren. Priorisieren: Welche Endpunkte sind am häufigsten geändert? Welche neuen Features sind geplant? Diese sind die ersten Kandidaten für Microservices.
2. API Gateway einrichten: Amazon API Gateway als Front-Door für alle API-Anfragen. Standardmäßig werden alle Anfragen an den Monolithen weitergeleitet.
3. Ersten Microservice entwickeln: Einen Endpunkt (z. B. Benutzerregistrierung) als eigenständigen Lambda-Dienst oder ECS-Service neu implementieren. Vollständig isoliert, eigene Datenbank.
4. Traffic umleiten: API-Gateway-Route für diesen Endpunkt auf den neuen Microservice umleiten. Monolith-Implementierung bleibt vorerst als Fallback bestehen.
5. Wiederholen bis Monolith leer ist: Iterativ weitere Endpunkte portieren. Am Ende wird der Monolith dekommissioniert — er ist von Funktionalität entleert worden.

Kritisch für den Erfolg: Die Datenbank-Dekomposition. Jeder Microservice braucht seine eigene Datenbank — das Shared-Database-Anti-Pattern (alle Microservices nutzen dieselbe DB) verhindert unabhängige Deployments und Skalierung.

Pfad 4: Full Re-Architecting

Der ambitionierteste Pfad: die Anwendung wird von Grund auf neu als cloud-native SaaS-Produkt entwickelt. Greenfield-Entwicklung mit modernen Architekturprinzipien: Event-Driven Architecture, Microservices, Serverless-First.

Full Re-Architecting ist nur sinnvoll, wenn:

• Der technische Schuldenstand eine inkrementelle Modernisierung unwirtschaftlich macht
• Ausreichend Ressourcen für parallele Entwicklung (neue Architektur + Wartung des Legacy-Systems) vorhanden sind
• Das Geschäftsmodell sich grundlegend ändert (z. B. von On-Prem-Lizenz zu Multi-Tenant-SaaS)
• Neue Märkte erschlossen werden sollen, die das bestehende Produkt technisch nicht bedienen kann

Marketplace-Integration nach der Modernisierung

Die Modernisierung ist auch der optimale Zeitpunkt für die AWS Marketplace Integration. Nach der Containerisierung oder dem Strangler-Fig-Prozess sind die technischen Voraussetzungen für ein Marketplace-Listing typischerweise erfüllt:

1. SaaS-Subscription-Integration: Landing Page für neue Marketplace-Käufer implementieren. AWS übergibt ein Registration Token; die Anwendung verarbeitet es und erstellt den Kunden-Account.
2. Metering Service: aws-marketplace:MeterUsage API aufrufen für nutzungsbasierte Abrechnung. Die modernisierte Architektur (Lambda/ECS) erleichtert die Integration erheblich.
3. Multi-Tenancy aktivieren: Das Marketplace-Listing wird zum Trigger für die Implementierung von Multi-Tenancy, falls noch nicht vorhanden. Jeder Marketplace-Käufer ist ein neuer Tenant.
4. SaaS Quick Start: AWS stellt Cloud Formation-Templates als Quick Start für gängige SaaS-Architekturen bereit. Reduziert den technischen Aufwand für standardisierte Komponenten erheblich.

Häufig gestellte Fragen zur ISV-Modernisierung

Was ist das Strangler Fig Pattern?

Das Strangler Fig Pattern ist eine Modernisierungsstrategie, bei der neue Microservices die Funktionalität eines Monolithen schrittweise ersetzen. Neue Features werden ausschließlich als Microservices entwickelt; bestehende Funktionen werden nach Priorität portiert. Ein API Gateway routet Anfragen entweder zum Monolithen oder zum neuen Service.

Wann ist Lift-and-Shift die richtige Wahl?

Lift-and-Shift ist sinnvoll, wenn schnelle Migration ohne Code-Änderungen erforderlich ist, der Wartungsaufwand für On-Premises-Infrastruktur reduziert werden soll, oder als erster Schritt einer mehrstufigen Modernisierungsstrategie. Es ist nicht die finale Lösung, aber oft der pragmatischste Einstieg.

Wie lange dauert eine typische ISV-Modernisierung?

Das hängt vom gewählten Pfad und der Systemkomplexität ab. Lift-and-Shift: 4–12 Wochen. Containerisierung: 3–6 Monate. Strangler Fig: 12–36 Monate (je nach Monolith-Größe). Full Re-Architecting: 18–48 Monate.

Kann ich während der Modernisierung weiter entwickeln?

Ja — das ist sogar notwendig. Das Strangler Fig Pattern ist explizit dafür ausgelegt, Modernisierung und laufende Feature-Entwicklung zu parallelisieren. Nur Full Re-Architecting erfordert typischerweise eine "Freeze"-Phase für das Legacy-System.

Wie integriert man ein modernisiertes Produkt in den AWS Marketplace?

Nach der Modernisierung muss das Produkt die AWS Marketplace API-Anforderungen erfüllen: SaaS-Subscription-Integration für die Käufer-Authentifizierung, AWS Marketplace Metering Service für Usage-based Abrechnung, und eine Seller-Registrierung im AWS Marketplace Management Portal.

Storm Reply: ISV-Modernisierungspartner mit AWS-Expertise

Storm Reply ist AWS Premier Consulting Partner DACH mit dem AWS Migration Competency und dem AWS DevOps Competency. Wir haben zahlreiche ISVs bei der Modernisierung ihrer Software-Produkte auf AWS begleitet — von der initialen Assessment-Phase bis zum Marketplace-Listing.

Unser ISV-Assessment umfasst: technische Analyse der bestehenden Architektur, Bewertung aller vier Modernisierungspfade, Business-Case-Berechnung (TCO alt vs. neu) und konkrete Implementierungs-Roadmap. Typische Dauer: 2–3 Wochen.