Die Migration von Anwendungen in die Cloud ist ein komplexes Unterfangen mit erheblichen technischen und organisatorischen Auswirkungen. Sie erfordert die Bewertung der Cloud-Readiness, die Auswahl der richtigen Migrationsstrategie und bei Bedarf die Anpassung des Quellcodes. Automatisierte Tools spielen mittlerweile eine Schlüsselrolle bei der Analyse und Transformation von Softwareprojekten.
Dieser Artikel stellt zwei Open-Source-Tools vor: das CNCF-Projektt Konveyor und OpenRewrite von Moderne, die bei der Planung und Durchführung der Migration von Java-basierten Unternehmensanwendungen unterstützen. Wir decken sowohl strategische Überlegungen als auch technische Workflows bis hin zu Anpassungen auf Code-Ebene ab.
Cloud-Plattformen versprechen Skalierbarkeit, Resilienz, Automatisierung und Kostenkontrolle. Legacy-Systeme sind jedoch oft monolithisch aufgebaut und eng an spezifische Infrastrukturen gekoppelt. Eine erfolgreiche Migration erfordert maßgeschneiderte Strategien; weder ein einfaches „Lift and Shift“ noch ein vollständiger Rewrite sind immer die optimale Lösung.
Erfolgreiche Projekte halten die Waage zwischen Kosten, Funktionalität und Modernisierung. Sie setzen auf interdisziplinäre Teams, klare Kommunikation und Tools, die transparente Analysen und reproduzierbare Änderungen liefern. Konveyor hilft bei der Evaluierung des Migrationsbedarfs, während OpenRewrite Code-Updates automatisiert – und dabei typische Probleme wie Classpath-Konflikte, Logging-Frameworks, Konfigurationen und veraltete Servlet-Container löst.
Eine Cloud-Migration ist nicht bloß eine technische Übung, sondern eine architekturelle Entscheidung mit weitreichenden Konsequenzen. Sie betrifft den Quellcode, Build-Prozesse, Infrastrukturabhängigkeiten, Bereitstellungsstrategien und Sicherheitsanforderungen. Typische technische Hürden sind:
Typische Hürden bei der Cloud-Migration. Bild generiert mit ChatGPT.
Eine weitere Herausforderung ist das Fehlen einer einheitlichen Teststrategie. Anwendungen ohne reproduzierbare Builds, automatisierte Tests oder Infrastructure-as-Code lassen sich nur schwer in automatisierte CI/CD-Pipelines integrieren – doch solche Pipelines sind für den cloud-nativen Betrieb unverzichtbar.
Ein zentrales Konzept, das wir bei QAware bei der Bewertung der Cloud-Readiness (Cloud-Bereitschaft) nutzen, ist die Kategorisierung von Anwendungen in drei Gruppen:
Kategorien der Cloud-Readiness.
Konveyor verwendet eine ähnliche Klassifizierung, die durch die Analyse automatisch und transparent generiert wird. Zu den wichtigsten Prüfungen gehören:
Das Konveyor-Projekt besteht aus drei Hauptkomponenten:
Ein CLI-Tool namens Kantra das die Analysefunktionen in einer eigenständigen Befehlszeilenschnittstelle kapselt. Es analysiert Quellcode sowie Abhängigkeiten, erstellt Berichte über Migrations-Blocker und liefert konkrete Handlungsempfehlungen.
Eine neue Komponente zur Integration von KI-Funktionen namens Konveyor AI. Sie nutzt die Analyseergebnisse und stellt mithilfe von Generativer KI automatische Fixes bereit. Diese Komponente befindet sich noch in der Entwicklung, ist aber sehr vielversprechend.
Die Analyse von Konveyor nutzt statische Codeanalyse und Heuristiken und erkennt Elemente wie JDBC-Anweisungen, Web-Frameworks, hartcodierte Pfade oder beispielsweise alte Java-Klassen. Die Ausgabe ist in HTML oder JSON verfügbar und kann direkt in CI/CD-Pipelines integriert werden.
Um eine Java-Anwendung mit dem Konveyor CLI-Tool Kantra zu analysieren, können Sie folgende Schritte ausführen:
Installieren Sie die Kantra-CLI durch Herunterladen von der Kantra Releases-Seite.
kantra \
analyze \
-i /path/to/your/java/application \
-o ../out \
--mode source-only \
--target cloud-readiness Kantra generiert den Bericht im HTML-Format innerhalb des angegebenen Ausgabeverzeichnisses (in diesem Beispiel ../out).
Beispiel für einen aus der Analyse generierten Bericht.
Mit dem Bericht können Sie die Cloud-Readiness Ihrer Anwendung bewerten, potenzielle Blocker identifizieren und konkrete Erkenntnisse für Refactoring- oder Modernisierungsmaßnahmen gewinnen.
Basierend auf den Analyseergebnissen können Teams eine Migrationsstrategie wählen, die zu ihrer Anwendungslandschaft und ihren geschäftlichen Zielen passt. In der Praxis haben sich drei Kernstrategien herausgebildet, die jeweils unterschiedliche Ziele, Aufwände und Risiken aufweisen.
Strategien für die Cloud-Migration.
Der Entwickler verlagert die Anwendung ohne Änderungen in die Cloud. Dieser Ansatz ist schnell und erfordert minimalen Entwicklungsaufwand, bringt jedoch keine strukturellen Verbesserungen. Er wird häufig bei kurzfristigem Kapazitätsbedarf oder Infrastrukturumstellungen (z. B. bei der Stilllegung von Rechenzentren) genutzt. Technisch kann dies bedeuten, dass VMs 1:1 zu IaaS-Angeboten wie AWS EC2 oder Azure VM migriert werden, wobei die meisten bestehenden CI/CD-Pipelines erhalten bleiben. Die Nachteile sind begrenzte Skalierbarkeit, eingeschränkte Observability und geringe Kostenvorteile – was oft zu Szenarien führt, die man als „Cloud in Name Only“ bezeichnet.
Der Entwickler passt die Anwendung an cloud-native Paradigmen an, was typischerweise Folgendes umfasst:
Refactoring ist üblich für funktional stabile, aber technisch veraltete Anwendungen. Es ermöglicht den Abbau von technischen Schulden, stellt Observability her (Prometheus, Grafana, OpenTelemetry), ermöglicht resiliente Kubernetes-Deployments und sorgt für zukunftssichere Skalierung. Tools wie OpenRewrite erleichtern dies durch regelbasierte, reproduzierbare Codeänderungen.
The developer performs a complete rewrite based on modern cloud architectures. A rewrite is necessary when:
Typische Technologien sind Microservices, Serverless-Komponenten (AWS Lambda, Azure Functions) und ereignisgesteuerte Architekturen (Event-Driven Designs). Rebuilding ist kostspielig, aber zukunftsweisend, wobei der ROI an das Innovationspotenzial gekoppelt ist.
Die meisten realen Migrationen kombinieren verschiedene Strategien – zum Beispiel das Refactoring des transaktionalen Kerns bei gleichzeitigem Rehosting von Hilfsmodulen. Dies verbindet einen schnellen ROI mit langfristiger Modernisierung. Eine erfolgreiche Migration hält die Balance zwischen Geschäftskontinuität und technischer Erneuerung.
Während sich Konveyor auf Analyse und Strategieplanung konzentriert, geht OpenRewrite den nächsten Schritt: automatisierte Codeanpassungen auf Basis deklarativer Regeln.
Im Kern analysiert OpenRewrite den Code zu einem vollständigen abstrakten Syntaxbaum (AST) und ermöglicht so semantisch präzise Transformationen. Sogenannte “Recipies” (Rezepte) definieren die Transformationslogik als modulare, wiederverwendbare und versionierbare Komponenten.
OpenRewrite bietet ein umfangreiches Set an Community-Recipes für typische Migrationsaufgaben, wie zum Beispiel:
Mit Maven lässt sich OpenRewrite einfach in Ihren Build-Prozess integrieren und ein spezifisches Recipe anwenden.
Das folgende Beispiel zeigt, wie Sie eine Spring-Boot-Anwendung von Version 2.x auf 3.4 aktualisieren, was erhebliche Änderungen wie die Migration des Jakarta-EE-Namespaces beinhaltet.
pom.xml unter <plugins> hinzu: <plugin>
<groupId>org.openrewrite.maven</groupId>
<artifactId>rewrite-maven-plugin</artifactId>
<version>6.15.0</version> <!-- Update to latest version -->
<configuration>
<activeRecipes>
<recipe>org.openrewrite.java.spring.boot3.UpgradeSpringBoot_3_4</recipe>
</activeRecipes>
<activeStyles>
<style>org.openrewrite.java.SpringFormat</style>
</activeStyles>
</configuration>
<dependencies>
<dependency>
<groupId>org.openrewrite.recipe</groupId>
<artifactId>rewrite-spring</artifactId>
<version>6.11.1</version> <!-- Update to latest version -->
</dependency>
</dependencies>
</plugin>mvn rewrite:run
Über Community-Regeln hinaus ermöglicht Ihnen OpenRewrite das Schreiben eigener Recipes. Sie können dies deklarativ mit YAML (Kombination bestehender Bausteine) oder imperativ mit Java tun (volle Kontrolle über Transformationen auf AST-Ebene). Ein pragmatischer Mittelweg ist der Start mit Templates im Refaster-Stil, um einfache Java-Recipes schnell aufzubauen.
Wann zu verwenden: Komposition, simple Transformationen und zentral verwaltete Policy-Rollouts.
Beispiel:
# Compose existing recipes to roll out standards
name: com.company.platform.baseline
recipeList:
- org.openrewrite.java.dependencies.UpgradeDependencyVersion:
groupId: org.springframework.boot
artifactId: spring-boot-starter
newVersion: 3.3.x
- org.openrewrite.java.RemoveUnusedImports
- org.openrewrite.java.format.AutoFormatVorteile:
Nachteile:
Wann zu verwenden: Komplexe, kontextbezogene Refactorings, die direkten AST-Zugriff erfordern.
Minimales Recipe-Skelett:
@DocumentExample
public class ReplaceSystemOutWithSlf4j extends Recipe {
@Override public String getDisplayName() { return "Use SLF4J instead of System.out"; }
@Override public TreeVisitor getVisitor() {
return new JavaIsoVisitor<>() {
@Override public J.MethodInvocation visitMethodInvocation(J.MethodInvocation m, ExecutionContext ctx) {
m = super.visitMethodInvocation(m, ctx);
if (m.getSimpleName().equals("println") &&
TypeUtils.isOfClassType(m.getSelect().getType(), "java.io.PrintStream")) {
return m.withName(m.getName().withSimpleName("info"))
.withSelect(JavaParser.parseExpression("logger"));
}
return m;
}
}; }
} Vorteile:
Nachteile:
Nutzen Sie Before/After-Muster im Refaster-Stil, um Java-Visitor zu generieren.
Beispiel:
import com.google.errorprone.refaster.annotation.AfterTemplate;
import com.google.errorprone.refaster.annotation.BeforeTemplate;
@RecipeDescriptor(
name = "Prefer StringIsEmpty",
description = "Prefer String#isEmpty() over alternatives that check the string's length."
)
public class StringIsEmpty {
@BeforeTemplate
boolean equalsEmptyString(String string) {
return string.equals("");
}
@BeforeTemplate
boolean lengthEquals0(String string) {
return string.length() == 0;
}
@AfterTemplate
boolean optimizedMethod(String string) {
return string.isEmpty();
}
}Wann zu verwenden:
Vorteile:
Mit dem Aufkommen leistungsfähiger Large Language Models (LLMs) stellt sich die Frage: Wie können diese Technologien zur Cloud-Migration beitragen? Im Gegensatz zu regelbasierten Tools wie OpenRewrite arbeiten LLMs probabilistisch – sie nutzen statistische Sprachmodelle, die auf großen Codebasen und Textkorpora trainiert wurden.
Vielversprechende Anwendungsfälle für LLMs bei der Migration sind:
Die Stärken von LLMs liegen in ihrer:
LLMs haben jedoch auch erhebliche Einschränkungen:
Kombiniert mit regelbasierten Tools wie OpenRewrite und Analyse-Frameworks wie Konveyor könnten LLMs als „kreative Ergänzung“ dienen für:
Eine hybride Lösung aus Reproduzierbarkeit und kontextuellem Verständnis zeichnet sich als vielversprechender Ansatz ab. Konveyor erforscht diese Richtung bereits mit seiner Komponente Konveyor AI, die LLM-Funktionen in den Migrationsprozess integriert.
Die Migration in die Cloud erfordert ein starkes Architekturverständnis, hohe Codequalität und präzise Planung. Sie ist selten ein linearer Prozess – vielmehr ist sie ein iterativer Zyklus aus Analyse, Entscheidungsfindung, Anpassung und Validierung. Hier spielen Open-Source-Tools wie Konveyor und OpenRewrite ihren vollen Wert aus:
Zusammen bilden sie ein komplementäres Toolset: Analyse und Ausführung, Strategie und Umsetzung, Transparenz und Automatisierung. Für Organisationen, die ihre Anwendungslandschaften zukunftssicher machen wollen, bieten diese Tools einen skalierbaren, offenen und gut integrierten Weg in die Cloud – frei von Black-Box-Verhalten, aber mit klaren Regeln, hoher Wiederverwendbarkeit und wachsender Community-Unterstützung.
Die Zukunft liegt jedoch in der Kombination: Konveyor und OpenRewrite für die strukturierte Migration, LLMs für kreative Erweiterungen – eingebettet in DevOps-Prozesse und cloud-native Prinzipien. So wird die Migration nicht zu einem einmaligen Kraftakt, sondern zu einem kontinuierlichen Modernisierungsprozess: skalierbar, nachvollziehbar und automatisiert.