C++ zu Rust migrieren: Schrittweise modernisieren ohne Full Rewrite

Ein gewachsenes C++-System lässt sich selten für Monate anhalten, neu schreiben und anschließend auf einen Schlag ersetzen. Dafür hängen zu viele Produkte, Prozesse und Kunden davon ab. Gleichzeitig steigen mit altem Code oft die Kosten für Fehlersuche, Sicherheitsprüfungen und Änderungen. Rust bietet einen Ausweg, aber nicht in Form eines weiteren Großprojekts. Der bessere Ansatz ist eine kontrollierte Koexistenz: C++ bleibt zunächst dort, wo es zuverlässig arbeitet, während Rust gezielt neue oder besonders riskante Komponenten übernimmt.

Wer C++ zu Rust migrieren möchte, braucht deshalb weniger Übersetzungsarbeit als eine belastbare Architekturentscheidung. Dieser Beitrag zeigt, welche Module sich als Einstieg eignen, wie Rust und C++ technisch zusammenspielen und wie aus einem Pilotprojekt eine schrittweise Modernisierung entsteht.

Warum ein Full Rewrite meist das falsche Ausgangsmodell ist

Ein vollständiger Rewrite wirkt auf dem Papier sauber. Das alte System wird durch eine neue Codebasis ersetzt, technische Schulden verschwinden und das Team kann moderne Werkzeuge einsetzen. In der Praxis beginnt das neue System jedoch nicht bei null. Es muss jahrelang gewachsene Geschäftsregeln, Randfälle, Performance-Eigenschaften und Integrationen reproduzieren. Ein Teil dieses Wissens steht in Dokumentationen. Vieles steckt nur im Verhalten des bestehenden Codes.

Damit entstehen drei Risiken gleichzeitig. Erstens liefert das Team über einen langen Zeitraum wenig sichtbaren Geschäftswert, weil die neue Plattform zunächst nur vorhandene Funktionen nachbildet. Zweitens wachsen Alt- und Neusystem auseinander, während das laufende Produkt weiterentwickelt wird. Drittens wird der eigentliche Beweis sehr spät erbracht: Erst beim großen Wechsel zeigt sich, ob Funktion, Lastverhalten und Betriebsprozesse wirklich passen.

Eine schrittweise Migration verkleinert diese Risiken. Sie behandelt Rust nicht als Ziel an sich, sondern als Werkzeug für klar definierte Probleme. Ein Modul wird ausgewählt, über eine schmale Schnittstelle angebunden und mit den bisherigen Ergebnissen verglichen. Funktioniert der Ansatz nicht, bleibt der Rückweg überschaubar. Funktioniert er, liefert der Pilot technische Daten für die nächste Entscheidung.

Das ähnelt dem von Martin Fowler beschriebenen Strangler-Fig-Muster: Neue Funktionen oder Ersatzkomponenten entstehen um das bestehende System herum und übernehmen nach und nach dessen Aufgaben. Der Unterschied liegt im Detail. Bei einer C++-Rust-Migration verläuft die neue Grenze häufig innerhalb eines nativen Prozesses. Deshalb sind ABI, Speicherbesitz und Fehlerbehandlung ebenso wichtig wie die fachliche Modulgrenze.

Welche C++-Module eignen sich für den Einstieg?

Der erste Kandidat sollte relevant genug sein, um etwas zu lernen, aber nicht so kritisch, dass jeder Fehler den Betrieb gefährdet. Ein guter Pilot hat eine klare Verantwortung, wenige Abhängigkeiten und messbare Ein- und Ausgaben. Beispiele sind Parser für nicht vertrauenswürdige Daten, Dateikonverter, Protokolladapter, Kompressionsmodule, Hintergrunddienste oder neue Funktionen, die bisher noch nicht im C++-Bestand existieren.

Vier Kriterien helfen bei der Auswahl:

Sicherheitsrisiko: Verarbeitet das Modul externe oder fehlerhafte Eingaben? Enthält es viel manuelle Speicherverwaltung, komplexe Lebenszeiten oder nebenläufigen Code? Dann kann Rust besonders viel bewirken.
Kopplung: Lässt sich die Komponente über wenige stabile Funktionen ansprechen? Eine schmale Grenze reduziert die Zahl der Typen, Zustände und Fehlerfälle, die zwischen beiden Sprachen übersetzt werden müssen.
Messbarkeit: Können Laufzeit, Speicherbedarf, Fehlerrate und Ergebnisgleichheit automatisiert geprüft werden? Ohne vorher definierte Messgrößen bleibt der Pilot eine Meinungsfrage.
Rückbaubarkeit: Kann das alte Modul während der Einführung parallel verfügbar bleiben? Feature Flags oder eine austauschbare Adapterebene ermöglichen einen kontrollierten Rollout.

Ungeeignet sind meist zentrale Domänenobjekte, die durch fast alle Teile des Systems gereicht werden, oder stark verzahnte Module mit vielen impliziten Seiteneffekten. Wer dort startet, muss sofort einen großen Teil der Architektur entflechten. Das kann langfristig sinnvoll sein, ist aber ein schlechtes Experiment für die erste Rust-Komponente.

Auch neue native Funktionen sind ein guter Einstieg. Google verfolgt bei Android seit Jahren genau diese Richtung: Neue native Komponenten werden bevorzugt in speichersicheren Sprachen entwickelt, anstatt den gesamten C++-Bestand umzuschreiben. Im Android-Sicherheitsbericht von 2022 beschreibt Google diesen Ansatz ausdrücklich als praktikabler als eine flächendeckende Konvertierung. Die Zahlen aus Android sind nicht automatisch auf jedes Unternehmen übertragbar. Sie zeigen aber, dass eine schrittweise Einführung auch in einer sehr großen nativen Codebasis funktionieren kann.

In der Praxis gibt es drei sinnvolle Einstiegsmuster:

Greenfield-Muster: Eine neue Komponente entsteht direkt in Rust und wird an den C++-Bestand angebunden.
Ersatzmuster: Rust übernimmt ein vorhandenes Modul hinter derselben fachlichen Schnittstelle.
Schutzschicht-Muster: Rust sitzt vor einem schwer veränderbaren C++-Kern und übernimmt beispielsweise Validierung, Parsing oder die Begrenzung eingehender Daten.

Das Greenfield-Muster verursacht meist den geringsten Migrationsaufwand. Das Ersatzmuster liefert den klarsten Vorher-Nachher-Vergleich. Eine Schutzschicht kann Risiken schnell reduzieren, lässt die technische Schuld im Kern jedoch bestehen. Die Wahl sollte deshalb zum Ziel des Piloten passen und nicht allein davon abhängen, wo sich Rust am einfachsten einbauen lässt.

Wie Rust und C++ zuverlässig zusammenarbeiten

Die wichtigste Architekturentscheidung liegt nicht in Rust oder C++, sondern an der Grenze dazwischen. Je breiter diese Grenze ist, desto mehr Komplexität wird dauerhaft Teil des Systems. Deshalb sollte ein Migrationsmodul nicht den kompletten internen Objektgraphen spiegeln. Besser sind wenige, fachlich verständliche Operationen mit einfachen Datentypen und klarer Verantwortung für Speicher und Fehler.

Koexistenz-Architektur: C++-Bestand, kontrollierte FFI-Grenze und neues Rust-Modul.

Die niedrigste gemeinsame Basis ist üblicherweise ein C-kompatibles Application Binary Interface (ABI). Rust stellt Funktionen über extern "C" bereit; gemeinsam genutzte Datenstrukturen erhalten bei Bedarf mit #[repr(C)] eine definierte C-Darstellung. Auf C++-Seite liegt davor ein kleiner Adapter, der die C-Schnittstelle in vertraute Klassen oder Funktionen übersetzt. Die FFI-Dokumentation im Rustonomicon beschreibt die grundlegenden Regeln und macht zugleich deutlich: Der Compiler kann die Korrektheit einer fremden Schnittstelle nicht vollständig prüfen.

Für größere Schnittstellen helfen spezialisierte Werkzeuge:

CXX erzeugt eine typisierte Brücke zwischen Rust und C++. Es unterstützt ausgewählte gemeinsame Typen und prüft Teile des Vertrags bereits beim Build. Gerade diese bewusste Begrenzung ist nützlich, weil sie zu einer kontrollierten Schnittstelle zwingt.
bindgen generiert Rust-Bindings aus vorhandenen C- oder C++-Headern. Das ist hilfreich, wenn eine bestehende Bibliothek zunächst weitgehend unverändert aus Rust aufgerufen werden soll.
cbindgen geht in die andere Richtung und erzeugt C- oder C++-Header für eine Rust-Bibliothek mit C-kompatibler API.
Corrosion bindet Cargo-Projekte in vorhandene CMake-Builds ein. So muss die bestehende Build-Struktur nicht sofort ersetzt werden.

Unabhängig vom Werkzeug müssen vier Regeln explizit dokumentiert werden: Wer besitzt einen übergebenen Speicherbereich? Wie lange bleiben Zeiger und Referenzen gültig? Wie werden Fehler dargestellt? Und welcher Thread darf eine Funktion aufrufen? C++-Exceptions sollten die Sprachgrenze nicht passieren. Rust-Panics müssen ebenfalls innerhalb der Rust-Komponente abgefangen oder durch eine Prozessstrategie behandelt werden. An der Schnittstelle sind Statuscodes, klar definierte Fehlerobjekte oder Ergebnisstrukturen meist robuster.

Ebenso wichtig ist eine einfache Datenform. Flache Strukturen, Byte-Puffer, Strings mit expliziter Länge und opaque Handles sind leichter zu kontrollieren als komplexe Vererbungshierarchien. Das mag zunächst weniger elegant wirken, schützt aber beide Seiten vor impliziten Annahmen. Sicherheit endet zudem nicht automatisch an der Rust-Datei. Unsicherer FFI-Code, ungültige Zeiger aus C++ oder falsch modellierte Lebenszeiten können weiterhin Fehler verursachen. Die Grenze gehört deshalb in Code Reviews, Tests und Architekturunterlagen wie eine öffentliche API behandelt.

C++ zu Rust migrieren: Eine Roadmap in sechs Schritten

1. Bestand und Ziele erfassen

Beginnen Sie nicht mit einer Liste von Dateien, sondern mit einer Karte des Systems. Welche Komponenten verursachen häufige Fehler? Wo entstehen lange Änderungszeiten? Welche Teile verarbeiten nicht vertrauenswürdige Daten? Welche Schnittstellen sind bereits stabil? Ergänzen Sie technische Kennzahlen um betriebliche Folgen, etwa Ausfallzeit, Supportaufwand oder verzögerte Releases.

Definieren Sie anschließend ein konkretes Ziel. „Mehr Rust“ ist kein Ziel. Sinnvoll sind Aussagen wie: Speicherfehler im Parser reduzieren, die Änderungszeit für einen Protokolladapter verkürzen oder ein neues Modul ohne zusätzliche C++-Altlasten entwickeln. Dieses Ziel bestimmt die Auswahl des Piloten und die späteren Messgrößen.

2. Einen begrenzten Piloten auswählen

Der Pilot sollte in wenigen Wochen einen vollständigen Lernzyklus erlauben: bauen, integrieren, testen, ausrollen und beobachten. Legen Sie vor Beginn fest, was Erfolg bedeutet. Dazu können identische Ergebnisse für einen Referenzdatensatz, ein maximales Laufzeitbudget, keine zusätzlichen Abstürze und eine begrenzte Integrationszeit gehören.

Bewahren Sie während des Piloten die alte Implementierung. Ein Adapter mit austauschbarem Backend kann Anfragen wahlweise an C++ oder Rust senden. Bei deterministischen Funktionen ist auch ein Shadow Mode sinnvoll: Beide Varianten laufen mit denselben Eingaben, aber zunächst wird nur das C++-Ergebnis produktiv verwendet. Abweichungen werden protokolliert und untersucht.

3. Die Sprachgrenze entwerfen

Bevor Rust-Code entsteht, wird der Vertrag zwischen den Sprachen festgelegt. Beschreiben Sie Funktionen, Datentypen, Ownership, Nebenläufigkeit und Fehlermodelle. Halten Sie die Anzahl gemeinsam genutzter Typen klein. Eine gute Grenze folgt einer fachlichen Operation, etwa „Nachricht validieren“, statt einzelne Hilfsfunktionen aus dem Inneren des Moduls offenzulegen.

Entscheiden Sie auch, wer die API kontrolliert. Bei einer neuen Rust-Komponente kann eine kleine C-kompatible Fassade langfristig stabil bleiben, während sich die interne Rust-Implementierung verändert. Wird dagegen eine große bestehende C++-API direkt gespiegelt, übernimmt die neue Komponente deren historische Komplexität. Dann ist zwar Code in Rust entstanden, die Architektur wurde aber kaum modernisiert.

4. Build, Tests und Betrieb gemeinsam integrieren

Eine Migration scheitert selten am ersten Funktionsaufruf. Schwieriger sind reproduzierbare Builds, plattformabhängige Toolchains, Paketierung und Diagnose im Betrieb. Cargo muss in CI, CMake oder das vorhandene Build-System eingebunden werden. Compiler-Versionen und Zielplattformen gehören fixiert, Abhängigkeiten geprüft und Artefakte reproduzierbar erzeugt.

Tests sollten auf mehreren Ebenen arbeiten. Rust-Unit-Tests prüfen die neue Implementierung. Vertragstests prüfen die FFI-Grenze. Differential Tests führen C++ und Rust mit denselben Eingaben aus und vergleichen Ergebnisse. Fuzzing eignet sich besonders für Parser und Binärformate. Lasttests prüfen nicht nur den Mittelwert, sondern auch Latenzspitzen und Speicherverbrauch.

Observability muss beide Sprachen verbinden. Logs brauchen gemeinsame Korrelationskennungen, Metriken dieselben fachlichen Definitionen und Absturzberichte verwertbare Symbole aus beiden Toolchains. Sonst entsteht im Fehlerfall eine blinde Zone genau an der neuen Systemgrenze.

5. Kontrolliert ausrollen und messen

Nach bestandenen Tests folgt kein sofortiger Komplettwechsel. Aktivieren Sie das Rust-Modul zunächst für interne Umgebungen, dann für einen kleinen Anteil realer Last. Feature Flags, Mandantengruppen oder klar abgegrenzte Datenpfade eignen sich für den gestuften Rollout. Für jede Stufe müssen Abbruchkriterien und ein getesteter Rückweg existieren.

Vergleichen Sie dabei nicht nur die technische Performance. Relevant sind auch Änderungsdurchlaufzeit, Review-Aufwand, Fehlerrate, Produktionsvorfälle und die Zeit bis zur Diagnose. Ein Google-Bericht von 2025 nennt im Android-Kontext unter anderem eine deutlich geringere Dichte an Speichersicherheitsproblemen sowie weniger Rollbacks bei Rust-Änderungen. Solche Ergebnisse sind ein wertvoller Hinweis, aber kein Versprechen für jedes Projekt. Ihre eigene Messung entscheidet.

6. Aus dem Pilot ein Programm machen

Nach einem erfolgreichen Pilot wird nicht automatisch das nächste beliebige Modul übersetzt. Dokumentieren Sie zuerst, was funktioniert hat: Schnittstellenmuster, Toolchain, Review-Regeln, Teststrategie und Betriebskennzahlen. Daraus entsteht ein wiederverwendbarer Migrationspfad. Ein kleines internes Beispielprojekt kann neuen Teammitgliedern zeigen, wie eine Rust-Bibliothek gebaut, angebunden und diagnostiziert wird.

Priorisieren Sie danach weitere Komponenten anhand derselben Kriterien wie den Piloten. Einige C++-Module werden ersetzt, andere bleiben bewusst bestehen. Erst wenn keine produktiven Aufrufer mehr vorhanden sind und die Beobachtungsphase abgeschlossen ist, wird die alte Implementierung entfernt. So entsteht kein dauerhaftes Doppelsystem, aber auch kein riskanter Stichtag.

Sechsphasige Roadmap für die schrittweise C++-Rust-Migration.

Typische Risiken und passende Gegenmaßnahmen

Die erste Gefahr ist eine zu breite FFI-Schicht. Wenn jede C++-Klasse ein Rust-Gegenstück erhält, steigen Kopplung und Testaufwand. Die Gegenmaßnahme ist eine fachliche Fassade mit wenigen Operationen.

Die zweite Gefahr ist unklare Ownership. Jeder übergebene Puffer braucht eine eindeutige Regel für Erzeugung, Veränderung und Freigabe. API-Dokumentation und automatisierte Tests mit Sanitizern bleiben auch bei Rust wichtig.

Die dritte Gefahr ist eine unterschätzte Toolchain. Rust bringt Cargo, andere Abhängigkeitsmechanismen und neue Build-Artefakte mit. Ein früher CI-Prototyp verhindert, dass der Pilot lokal funktioniert, aber an Release-Prozessen oder Zielplattformen scheitert.

Die vierte Gefahr ist ein Wissenssilo. Wenn nur ein Entwickler die Brücke versteht, entsteht neue Abhängigkeit. Pairing, gemeinsame Reviews und kurze Architekturentscheidungen verteilen das Wissen. Das Team braucht nicht sofort vollständige Rust-Expertise. Es braucht zunächst sichere Standards für den begrenzten Einsatzbereich.

Schließlich kann Rust als Vorwand für eine unnötige Neugestaltung dienen. Eine Migration sollte Architekturprobleme gezielt lösen, aber nicht gleichzeitig jedes Datenmodell, Protokoll und Deploymentverfahren ersetzen. Je mehr Variablen sich im Pilot ändern, desto schwerer lässt sich sein Ergebnis bewerten.

Woran lässt sich der Erfolg messen?

Erfolg zeigt sich nicht an der Zahl der Rust-Zeilen. Gute Kennzahlen verbinden Technik und Lieferung:

Produktionsfehler und sicherheitsrelevante Befunde im migrierten Modul
P50-, P95- und P99-Latenz sowie Spitzen beim Speicherverbrauch
Dauer von Entwicklung, Review und Release einer vergleichbaren Änderung
Zahl und Ursache von Rollbacks oder Hotfixes
Zeit zur Diagnose eines Fehlers über die Sprachgrenze hinweg
Anteil der Aufrufe, die stabil über das Rust-Modul laufen

Eine Migration ist nicht in jedem Fall wirtschaftlich. Ein stabile, selten geänderter C++-Baustein ohne besondere Sicherheitsanforderungen kann unverändert die beste Lösung sein. Gleiches gilt, wenn eine benötigte Plattform nicht zuverlässig unterstützt wird, harte Zertifizierungen einen Wechsel unverhältismäßig teuer machen oder das Team keinen langfristigen Betrieb der Rust-Toolchain sicherstellen kann.

Die Entscheidung lautet deshalb nicht „Rust oder C++ für das gesamte Produkt“. Sie lautet für jedes Modul: Welches konkrete Risiko oder welche Liefergrenze soll verbessert werden, und ist Rust dafür der wirtschaftlich beste Hebel? Weitere Entscheidungskriterien finden Sie im Beitrag Warum Unternehmen sich 2026 für Rust statt C++ entscheiden. Hinweise auf wirtschaftliche Folgen technischer Altlasten behandelt außerdem Die wichtigsten Anzeichen, dass Ihr Legacy-System Ihrem Unternehmen zu viel Geld kostet.

Fazit: Migration als kontrolliertes Architekturprogramm

Wer C++ zu Rust migrieren will, muss keine komplette Codebasis neu schreiben. Der belastbare Weg beginnt mit einem klar begrenzten Modul, einer schmalen und geprüften Schnittstelle sowie Messgrößen, die vor dem ersten Rollout feststehen. C++ und Rust dürfen über Jahre koexistieren, solange Verantwortlichkeiten, Toolchain und Rückbauplan eindeutig sind.

Wenn Sie prüfen möchten, welche Komponenten sich für einen Pilot eignen, kann trust!NICKOL die bestehende Architektur analysieren und eine priorisierte Migrations-Roadmap entwickeln. So wird aus einer allgemeinen Rust-Idee eine umsetzbare Entscheidung mit kontrolliertem Risiko.

FAQ zur C++-Rust-Migration

Muss eine C++-Anwendung vollständig neu geschrieben werden, um Rust zu nutzen?

Nein. Rust-Bibliotheken können über eine C-kompatible ABI oder Werkzeuge wie CXX in bestehende C++-Anwendungen eingebunden werden. Für viele Unternehmen ist es sinnvoller, neue oder besonders riskante Module schrittweise zu migrieren und den stabilen Bestand zunächst weiterzubetreiben.

Können Rust und C++ im selben Prozess laufen?

Ja. Beide Sprachen können im selben Prozess zusammenarbeiten. Dafür braucht es eine klar definierte FFI-Schnittstelle, kompatible Datentypen sowie eindeutige Regeln für Speicherbesitz, Lebenszeiten, Threads und Fehler. Die Sprachgrenze sollte möglichst klein bleiben.

Welches Modul sollte zuerst nach Rust migriert werden?

Geeignet ist ein fachlich abgegrenztes Modul mit messbaren Ein- und Ausgaben, begrenzten Abhängigkeiten und erkennbarem Nutzen. Parser, Protokolladapter oder neue native Funktionen sind häufig bessere Piloten als zentrale, stark gekoppelte Domänenmodelle.

Verbessert Rust automatisch Sicherheit und Performance?

Rust verhindert viele Klassen von Speicherfehlern im sicheren Sprachbereich. Falsche FFI-Verträge, unsicherer Code und logische Fehler bleiben jedoch möglich. Auch bessere Performance ist nicht automatisch garantiert. Sicherheit, Laufzeit und Speicherverbrauch müssen für den konkreten Anwendungsfall getestet werden.

Wie lange dauert eine schrittweise C++-Rust-Migration?

Das hängt von Systemgröße, Modulgrenzen, Plattformen und Qualitätsanforderungen ab. Ein begrenzter Pilot kann oft in wenigen Wochen Erkenntnisse liefern. Die vollständige Modernisierung eines großen Systems ist dagegen ein mehrjähriges Programm, bei dem C++ und Rust bewusst parallel betrieben werden.