Wann sollte man eine Vibe-Coding-App migrieren?

Der Umzug einer generierten App vor dem Start ist billiger und sauberer. Nach ersten Erfolgen ist die Entscheidung besser begründet, doch Fehler werden deutlich teurer. Der richtige Zeitpunkt hängt weniger davon ab, ob das Projekt in Lovable, Bolt, v0 oder Replit begann. Entscheidend ist, ob ihr jede zustandsbehaftete Grenze benennen und den Umzug proben könnt, die bisher der Anbieter kontrolliert.

Für mich ist der Start der Moment, in dem Identitäten, Daten und eine öffentliche Domain zu Versprechen gegenüber Nutzern werden. Davor kostet ein misslungener Umzug Entwicklerzeit. Danach kann derselbe Fehler Kunden aussperren, Schreibvorgänge verlieren, Sitzungen ungültig machen oder Besucher auf zwei Produktversionen verteilen. Nutzung zeigt, was erhalten bleiben muss, macht aus einer gewöhnlichen Codeverschiebung aber auch eine betriebliche Änderung.

Entscheidet nicht nach der Größe des Quellbaums. Eine kleine App mit verwalteter Anmeldung und einer aktiven Datenbank kann schwerer umzuziehen sein als eine große statische Website. Entscheidet nach Eigentum: Wer kontrolliert Repository, Nutzeridentitäten, Datenbank, Geheimnisse, Dateien, geplante Aufgaben, Domain, Bereitstellung und Rückweg?

Vor dem Start schafft ein Umzug Freiheit

Ein Umzug vor dem Start ist meist richtig, wenn die bisherige Plattform eine bekannte Anforderung an Eigentum, Bereitstellung, Datenstandort oder Wartbarkeit nicht erfüllt. Ihr könnt Schemas noch ändern, die Anmeldung ersetzen, Umgebungsvariablen umbenennen und Testdaten zurücksetzen, ohne dies mit Nutzern abstimmen zu müssen.

Diese Phase ist besonders günstig, wenn es nur vorbereitete Konten und entbehrliche Datensätze gibt. Exportiert den Code, baut ihn in einer sauberen Umgebung, erstellt die Datenbank aus Migrationen neu und findet heraus, welche Teile im ursprünglichen Arbeitsbereich stillschweigend vorhanden waren. Jeder Fehler ist nützlich, weil er eine Abhängigkeit aufdeckt, bevor sie Kundendaten trägt.

Der günstige Zeitpunkt macht die Arbeit nicht überflüssig. Generierte Projekte laufen oft, weil ihre ursprüngliche Plattform Konfiguration einfügt, eine Datenbankadresse liefert, Funktionen hostet oder eine bestimmte Baukonvention kennt. Ein Quellcodeexport beweist nur, dass ihr Dateien besitzt. Er beweist nicht, dass ein anderer Hoster dasselbe System bauen und betreiben kann.

Vor dem Start verlange ich einen Test aus einer sauberen Umgebung. Ein Teammitglied, das das Projekt nicht angelegt hat, bekommt nur das Repository, eine dokumentierte Liste der Geheimnisse mit sicheren Entwicklungswerten und die Einrichtungsanleitung. Kann diese Person sich nicht anmelden, einen Datensatz anlegen und den wichtigsten Nutzerablauf abschließen, ist das Projekt noch nicht portabel.

Es gibt gute Gründe zu warten. Ein früher Prototyp ändert sein Datenmodell womöglich täglich, und die nächste Produktentscheidung kann die Umzugsarbeit entwerten. Unterstützt die aktuelle Plattform den geplanten Start, Quellcodeexport, Bereitstellung, eigene Domains und einen glaubwürdigen Rückweg, liefert eine kleine Veröffentlichung möglicherweise mehr Erkenntnisse als Infrastrukturarbeit für ein Produkt ohne Nachfrage.

Die Frage vor dem Start lautet deshalb nicht: „Können wir umziehen?“ Sie lautet: „Beseitigt der Umzug ein bekanntes Startrisiko, oder bezahlen wir dafür, Vermutungen zu bewahren?“ Zieht wegen einer konkreten Einschränkung um, nicht weil klassische Infrastruktur seriöser wirkt.

Nach ersten Erfolgen entstehen Pflichten

Ein Umzug nach ersten Erfolgen ist sinnvoll, wenn echte Nutzung Anforderungen zeigt, die das bisherige System nicht erfüllt. Der Plan muss dann jedes bereits genutzte öffentliche Versprechen erhalten. Ihr kennt stark genutzte Wege, das wirkliche Datenvolumen, von Nutzern ausgelöste Hintergrundaufgaben und wichtige Integrationen. Diese Belege verhindern einen teuren Umzug zu einer nur vorgestellten Architektur.

Die Pflichten sind ebenso konkret. Bestehende Passwörter müssen funktionieren, oder Nutzer brauchen einen kontrollierten Rücksetzweg. Datenbankkennungen müssen stabil bleiben, wenn URLs, Rechnungen, Webhooks oder Fremdschlüssel sie verwenden. Hochgeladene Dateien brauchen einen Transferplan. E-Mail-Links und OAuth-Rückrufe müssen auf die richtige Domain zeigen. Schreibvorgänge während der Kopie müssen die neue Datenbank erreichen oder bewusst pausieren.

Erfolg ist keine einzelne Schwelle. Zehn aktive Kunden, die eine App für Lohnabrechnung nutzen, erzeugen mehr Umzugsrisiko als zehntausend Leser eines statischen Katalogs. Zählt Zustand und Folgen, nicht Konten. Fragt, wie viele Daten sich pro Minute ändern, was eine doppelte Aktion kostet, wie schnell der Support Betroffene erreicht und ob das Unternehmen ein Wartungsfenster verkraftet.

Teams verwechseln hier belegte Nachfrage oft mit einer Erlaubnis zum Architekturwechsel. Mehr Nutzer rechtfertigen nicht automatisch eine Neuentwicklung. Ist die exportierte App verständlich und lassen sich Dienste Grenze für Grenze trennen, ist ein schrittweiser Umzug sicherer als ein Austausch des gesamten Stacks.

Vor einem Umzug nach ersten Erfolgen verlange ich eine schriftliche Eigentumskarte:

• Quellrepository und Bauprozess
• Nutzerverzeichnis und aktive Sitzungen
• Primärdatenbank, Dateien und Sicherungen
• Geheimnisse, geplante Aufgaben und ausgehende Webhooks
• Domain, E-Mail-Absenderdaten, Überwachung und Rücksetzbefugnis

Jede Lücke ist ein Hindernis, kein Detail für die Nacht der Umschaltung. Der Plattformname zählt nur, wenn er beeinflusst, wie eines dieser Güter exportiert oder neu konfiguriert wird.

Authentifizierung ist eine Identitätsmigration

Behandelt Authentifizierung als Übertragung von Identitäten und Vertrauensregeln, nicht als Anmeldeformular, das später neu gebaut wird. Das sichtbare Formular ist einfach. Passwort-Hashes, Subjektkennungen der Anbieter, bestätigte E-Mail-Adressen, Mehrfaktor-Anmeldungen, Wiederherstellungswege, Sitzungen und Berechtigungsrollen tragen die Kontinuität.

Klärt zuerst, ob die App eine Nutzertabelle besitzt oder Identität an einen verwalteten Dienst delegiert. Könnt ihr Nutzer exportieren, prüft die vorhandenen Felder und ob sich Passwort-Hashes am Ziel importieren lassen. Hashes sind nicht austauschbar, nur weil beide Systeme sie so nennen. Das Ziel muss Algorithmus und Parameter genau unterstützen, sonst ist für jedes Passwort ein Reset nötig.

Soziale Anmeldung schafft eine weitere Identitätsgrenze. OAuth-Anbieter liefern normalerweise eine stabile, anbieterspezifische Subjektkennung. Gleicht die neue Umsetzung Konten nur über E-Mail-Adressen ab, kann sie Menschen falsch zusammenführen, wenn sich Adressen ändern oder Anbieter andere Aliase liefern. Bewahrt das Tupel aus Aussteller, Anbieterkennung und lokaler Nutzer-ID. Registriert Rückrufadressen vor der Umschaltung neu und testet eine neue Anmeldung sowie ein bestehendes Konto.

Das OWASP Session Management Cheat Sheet empfiehlt, die Sitzungskennung nach einer Berechtigungsänderung zu erneuern. Eine Migration ist selbst keine Berechtigungsänderung, doch die Empfehlung macht eine Grenze sichtbar: Sitzungszustand ist Sicherheitszustand. Undurchsichtige Cookies von einem Authentifizierungsstack in einen anderen zu übertragen lohnt sich selten. Behaltet den alten Prüfer vorübergehend, wenn ihr ihn vollständig versteht, oder beendet Sitzungen und kündigt eine neue Anmeldung an. Akzeptiert nie still einen Cookie, den der neue Dienst nicht prüfen kann.

Auch der Cookie-Bereich kann einen sonst korrekten Umzug brechen. Prüft Name, Domain, Pfad sowie Secure, HttpOnly und SameSite des neuen Hosts. Laut MDN-Referenz zu Set-Cookie gilt ein Cookie mit Domain für diese Domain und ihre Subdomains, während ein Cookie ohne diese Angabe auf den setzenden Host beschränkt bleibt. Das ist relevant, wenn die alte App unterschiedliche Hosts für Oberfläche und API nutzte. Testet mit einem frischen Browserprofil, damit kein alter Cookie einen fehlerhaften Ablauf gesund aussehen lässt.

Berechtigungen brauchen einen eigenen Vergleich. Eine Anmeldung kann gelingen, während Organisationsmitgliedschaft, Adminrolle, Abonnementrecht oder Zeilenrichtlinie verloren geht. Exportiert Beispielkonten mit verschiedenen Rollen und schreibt vor dem Datentransfer Tests für den erwarteten Zugriff. Eine erfolgreiche Anmeldeseite beweist fast nichts.

Vor dem Start ersetze ich das Identitätssystem lieber sofort und lösche Testnutzer. Nach ersten Erfolgen braucht ihr genau eine klare Strategie:

• Kompatible Passwort-Hashes importieren und Anbieterkennungen erhalten.
• Den alten Identitätsdienst während des App-Umzugs behalten.
• Einen Reset mit ablaufenden Einmaltokens verlangen.
• Kurzzeitig doppelt lesen, aber nur eine Schreibinstanz zulassen.

Betreibt nie zwei beschreibbare Nutzerverzeichnisse. Widersprüchliche E-Mail-Änderungen und Löschanträge machen aus dieser Bequemlichkeit einen Vorfall.

Der Datentransfer muss Bedeutung erhalten

Eine Datenbankmigration gelingt nur, wenn das Ziel Einschränkungen, Kennungen, Zeitstempel, Beziehungen und jeden während des Umzugs angenommenen Schreibvorgang bewahrt. Zeilenzahlen sind ein schwacher Test. Zwei Datenbanken können gleich viele Zeilen enthalten und sich bei Geldgenauigkeit, Zeitzonen, Eindeutigkeit, Nullwerten oder Fremdschlüsseln unterscheiden.

Erstellt die Datenbank vor dem Start aus versionierten Migrationen neu, statt eine Entwicklungsdatenbank zu kopieren. Fügt nur notwendige Startdaten ein. Dieser Test zeigt, ob die Schemahistorie vollständig ist und ob die App von Tabellen abhängt, die jemand manuell in einer gehosteten Konsole angelegt hat.

Trennt nach ersten Erfolgen die Schemaübertragung vom Transfer der Live-Daten. Notiert Quellengine und Version, Erweiterungen, Sortierungen, generierte Spalten, Trigger, Zeilenrichtlinien, Sequenzen und große Objekte. Nutzt das Ziel eine andere Datenbankengine, ist dies zugleich eine App-Migration. SQL-Syntax ist der kleinste Teil; Transaktionsverhalten und Typbedeutung verursachen die unangenehmen Überraschungen.

Die PostgreSQL-Dokumentation beschreibt pg_dump als konsistenten Export, der Leser und Schreiber nicht blockiert. Das hilft, doch Teams lesen zu viel in dieses Versprechen. Ein konsistenter Snapshot enthält keine Schreibvorgänge, die nach seinem Beginn abgeschlossen werden. Ihr braucht weiterhin Änderungserfassung, eine abschließende Schreibpause oder ein Wartungsfenster.

Nutzt eine Abgleichabfrage, deren Ausgabe zum Umschaltprotokoll gelegt werden kann. Dieses Fragment prüft Anzahl, ID-Grenzen und letzte Aktualisierung für drei wichtige Tabellen:

SELECT 'users' AS table_name, count(*) AS rows,
       min(id)::text AS min_id, max(id)::text AS max_id,
       max(updated_at) AS newest_update
FROM users
UNION ALL
SELECT 'projects', count(*), min(id)::text, max(id)::text, max(updated_at)
FROM projects
UNION ALL
SELECT 'orders', count(*), min(id)::text, max(id)::text, max(updated_at)
FROM orders;

Führt sie auf beiden Seiten aus und untersucht jede Abweichung. Prüft anschließend fachliche Regeln, die Zahlen nicht erkennen: Keine Bestellung zeigt auf einen fehlenden Nutzer, Salden entsprechen ihrem Journal, jeder Dateidatensatz hat ein Objekt und Eindeutigkeitsregeln weisen dieselben Duplikate ab.

Sicherungen brauchen einen Wiederherstellungstest. Eine erfolgreiche Exportdatei beweist nur, dass ein Befehl endete. Stellt sie in ein leeres Ziel wieder her, startet die App damit und messt die Dauer. Nur diese gemessene Zeit zeigt, ob Wiederherstellung ein brauchbarer Rückweg oder bloß beruhigend ist.

Dateispeicher versteckt sich oft hinter Datenbankzeilen. Eine exportierte Tabelle uploads kann Objektnamen enthalten, während die eigentlichen Objekte in einem verwalteten Bucket bleiben. Kopiert Bytes, Prüfsummen, Inhaltstypen, Zugriffsregeln und Eigentumsdaten. Testet Stichproben über die App, nicht über die Speicherkonsole. Regeneriert signierte oder alte Hostadressen. Behandelt Nutzerdateien im selben Umschaltfenster als Zustand, besonders wenn Nutzer während der Datenbankkopie Dateien ersetzen können.

Umgebungsvariablen zeigen versteckte Architektur

Macht aus einem geerbten Beutel von Umgebungsvariablen einen benannten Vertrag je Umgebung. Fehlende Variablen führen zu sichtbaren Fehlern. Gefährlicher sind plausible, aber falsche Produktionswerte, etwa ein Testschlüssel für Zahlungen, ein altes Webhook-Geheimnis oder eine Rückrufadresse zum früheren Host.

Erfasst Variablen aus Code, Plattformeinstellungen, Baukonfiguration, serverlosen Funktionen, geplanten Aufgaben und Bereitstellung. Kopiert nicht die gesamte alte Umgebung. Ordnet jeden Wert nach Besitzer, Vertraulichkeit, Geltungsbereich, Rotationsweg und danach, ob er beim Bauen oder zur Laufzeit gelesen wird.

Ein kleines Verzeichnis macht diese Grenze prüfbar:

DATABASE_URL          runtime   secret   owner=backend   rotate=yes
PUBLIC_APP_ORIGIN     build     public   owner=web       rotate=no
SESSION_SIGNING_KEY   runtime   secret   owner=security  rotate=yes
MAIL_SENDER           runtime   public   owner=ops       rotate=no
WEBHOOK_SECRET        runtime   secret   owner=backend   rotate=yes

Die Trennung von Bauzeit und Laufzeit ist bei React-ähnlichen Oberflächen wichtig. Ein beim Bauen eingebetteter Wert ändert sich nicht durch eine Laufzeiteinstellung. Baut den Client neu und prüft das ausgelieferte Paket auf öffentliche Konfiguration. Ein Geheimnis gehört nie in eine Variable, nur weil ihr Name mit einem öffentlichen Präfix des Frameworks beginnt.

Rotiert Geheimnisse beim Umzug nach ersten Erfolgen, wenn das Ziel eine Überlappung unterstützt. Akzeptiert für Webhook-Prüfung oder Sitzungssignatur kurz den alten und den neuen Wert, stellt aber nur noch den neuen aus. Entfernt den alten nach dem längsten Zustell- oder Sitzungsfenster. Erlaubt ein Anbieter nur einen Wert, koordiniert den Wechsel mit der endgültigen Umschaltung und dokumentiert die Abhängigkeit.

Vor dem Start löscht ihr ungenutzte Variablen und lasst den Start bei fehlenden Pflichtwerten scheitern. Nach ersten Erfolgen ergänzt ihr erst Beobachtung, damit eine scheinbar alte Integration nicht unbemerkt noch monatliche Arbeit für die Buchhaltung erledigt.

Vergleicht Werte nach Umgebung, kopiert aber keine Geheimnisse in das Migrationsdokument. Notiert Namen und Versionsmarken und bewahrt Werte im Geheimnisspeicher des Ziels auf. Die App-Identität darf nur lesen, was diese Bereitstellung braucht. Haltet bei Änderungen fest, wer sie vorgenommen und welches Release sie genutzt hat. So lässt sich in der Umschaltnacht die Frage beantworten: „Welche Datenbankadresse haben wir tatsächlich ausgerollt?“

Die Domainumschaltung lenkt Verkehr

Die Umschaltung muss so geplant sein, dass alte und neue Bereitstellung während der DNS-Verteilung sicher Verkehr annehmen können. DNS ändert sich nicht überall gleichzeitig. Eine kurz zuvor gesenkte Gültigkeitsdauer beeinflusst Resolver nicht, die den alten Wert bereits zwischengespeichert haben.

Senkt die TTL des betreffenden Eintrags mehrere Tage vorher und kontrolliert die autoritative Antwort. Haltet die alte Bereitstellung mindestens für die alte TTL plus einen vorsichtigen Puffer gesund. Stellt das Zertifikat am neuen Host bereit, bevor Verkehr dorthin fließt. Prüft Hauptdomain, www, API-Subdomain, Weiterleitungen und IPv6 getrennt.

Die Domain ist nur die Eingangstür. Aktualisiert Authentifizierungsrückrufe, erlaubte Ursprünge, Cookie-Domains, kanonische Adressen, Webhook-Ziele, E-Mail-Links und mobile Deep Links. Sucht im Repository und in Einstellungen nach dem alten Hostnamen. Eine Weiterleitung hilft Browsern, behebt aber keinen strikten OAuth-Fehler und keinen für das falsche Ziel signierten Webhook.

Keine Unterbrechung ist nur möglich, wenn beide Versionen mit kompatiblem Zustand arbeiten. Ändert das neue Release die Datenbank so, dass alter Code sie nicht lesen kann, führt DNS-Überlappung zu Fehlern. Nutzt erweiternde und später verkleinernde Schemaänderungen: Fügt Neues hinzu, stellt Code für beide Formen bereit, übertragt Daten und entfernt die alte Form erst nach Ende des alten Verkehrs.

Bei geringem Volumen kann ein kurzes Wartungsfenster sicherer sein als aufwendige Live-Replikation. Kündigt die Schreibpause an, liefert eine korrekte Wartungsantwort, leert Hintergrundarbeit, kopiert den letzten Stand, gleicht ab, schaltet um und öffnet Schreibzugriffe. Lesen kann verfügbar bleiben, wenn es keine versteckte Arbeit erzeugt.

Ein Rückweg braucht eine Datenregel. DNS zurückzuschalten ist einfach, solange das Ziel keine Schreibvorgänge angenommen hat. Danach kann eine Umkehr Daten verwerfen oder aufspalten. Definiert den letzten sicheren Rücksetzzeitpunkt. Später müsst ihr vorwärts reparieren oder Änderungen abgleichen.

Beobachtet die App von außerhalb des neuen Hostingkontos. Löst die Domain über mehrere öffentliche Resolver auf, fordert die Zertifikatskette an, ladet ohne warmen Cache, sendet eine umkehrbare Transaktion und prüft ihre Hintergrundarbeit. Das Dashboard kann gesund melden, während Nutzer alte DNS-Antworten oder einen älteren regionalen Build erhalten. Prüft öffentliche Domain und zielgebundenen Testhost bis zum Ende der Überlappung.

Quellcodebereinigung macht den Umzug dauerhaft

Die Bereinigung soll Plattformbindung entfernen, ohne brauchbare generierte Struktur zu löschen oder eine fremde Neuentwicklung auszulösen. Generierter Code kann sich wiederholen oder unbeholfen wirken. Geschmack ist aber keine Migrationsanforderung. Ändert, was unabhängiges Bauen, Tests, Sicherheitsprüfung oder Wartung verhindert.

Beginnt mit Herkunft. Exportiert das vollständige Repository und behaltet Lizenzen, Assetnachweise, generierte Migrationen, Sperrdateien und Konfiguration. Prüft, ob Geheimnisse oder Plattformtokens in der Git-Historie stehen. Löschen aus der neuesten Datei widerruft sie nicht. Rotiert offengelegte Zugangsdaten und entscheidet bewusst über eine Umschreibung der Historie.

Sucht dann plattformspezifische Importe, Proxywege, Datenbankclients, Authentifizierungshelfer, Speicheradapter, Bereitstellungsdateien und generierte API-Endpunkte. Kapselt sie, wo sinnvoll, hinter schmalen App-Schnittstellen. Eine repositoryweite Suche hilft, doch Nutzerabläufe zeigen, welche Verweise noch Bedeutung haben.

Abhängigkeiten bereinigt ihr erst nach einem funktionierenden unabhängigen Build. Entfernt Pakete einzeln, erzeugt die Sperrdatei mit demselben Paketmanager neu und testet jede Gruppe. Aktualisiert nicht zugleich Framework, Zustandsverwaltung, Komponentennamen und Hosting. Sonst hat jeder Fehler zu viele mögliche Ursachen.

Generierter Servercode braucht an Vertrauensgrenzen besondere Aufmerksamkeit. Verfolgt jede Anfrage von Route über Berechtigungsprüfung bis Datenbankabfrage. Der Server darf sich nicht auf eine Sichtbarkeitsregel im Client verlassen. Prüft Uploadgrenzen, ausgehende Ziele, Fehlermeldungen und Adminrouten. Das verlangt keine Neuentwicklung aller Handler, sondern bestätigt, dass Zugriffsregeln nach Wegfall verwalteter Middleware gelten.

Das Projekt braucht gewöhnliche Betriebsdateien: ein Beispiel der Umgebung mit falschen Werten, Datenbankmigrationsbefehle, Bau- und Startanleitung, Gesundheitsprüfungen und eine Beschreibung der Hintergrundprozesse. Die Anleitung muss ausführbar sein. „Datenbank konfigurieren“ hält nur fest, dass eine existiert.

Vor dem Start dürfen Schemaresets und große Umbauten Teil der Bereinigung sein, weil keine Kompatibilitätszusage besteht. Nach ersten Erfolgen bleiben öffentliche API-Formen, Kennungen und sichtbares Verhalten unverändert, bis der Infrastrukturumzug ruhig läuft. Ändert nicht gleichzeitig Produktverhalten. Sonst kann der Support Beschwerden nicht dem Umzug oder der Funktion zuordnen.

Eine Probe macht Ausfallzeit entscheidbar

Eine Migrationsprobe soll die Produktionsfolge mit einer aktuellen, bereinigten Datenkopie nachstellen und gemessene Zeiten, Abgleichergebnisse und einen getesteten Abbruchpunkt liefern. Eine fremde Checkliste sagt nicht, wie lange eure Wiederherstellung dauert oder welcher Prozess nach Aktivierung der Wartung weiterschreibt.

Eine Person führt aus, eine zweite beobachtet, protokolliert Zeiten und hinterfragt übersprungene Prüfungen. In kleinen Teams kann die zweite Person der Gründer sein, braucht aber genug Kontext, um eine veränderte Ausgabe zu erkennen. Wer Befehle eingibt, sollte nicht allein über ihren Erfolg entscheiden.

Ein brauchbares Ablaufbuch hat eine feste Reihenfolge:

1. Unabhängige Bereitstellungen stoppen und aktuelle Versionen, DNS-Werte und Geheimnisversionen festhalten.
2. Schreibzugriffe sperren, Warteschlangen leeren, geplante Aufgaben stoppen und letzten Quellstand notieren.
3. Restdaten kopieren, Tabellen und Fachregeln abgleichen, Anmeldung und Hauptablauf testen.
4. Verkehr umschalten, Zertifikate und Rückrufe prüfen, Fehler und Warteschlangen beobachten, Schreiben öffnen.
5. Am festgelegten Punkt entweder am neuen System festhalten oder die dokumentierte Rücksetzregel ausführen.

Vor dem Start probt ihr, indem ihr das Ziel löscht und aus dem Repository neu erstellt. Das Ziel ist Wiederholbarkeit. Eine leere Datenbank und frische Umgebung decken mehr auf als eine produktionsähnliche Kopie.

Nach ersten Erfolgen probt ihr Volumen und Gleichzeitigkeit. Kopiert repräsentative Daten für langsame Indizes und lange Migrationen. Spielt sichere Lesezugriffe nach, erzeugt synthetische Schreibvorgänge mit bekannten IDs und prüft Hintergrundaufgaben auf Wiederholbarkeit. Eine doppelte E-Mail ist nicht harmlos, nur weil die Datenbank konsistent blieb.

Messt die Schreibpause getrennt vom gesamten Wartungsfenster. Große Kopien können oft bei laufender Quelle erfolgen; pausiert nur für Differenz und Prüfung. Passt die Differenz laut Probe nicht in das Fenster, braucht ihr Replikation oder Änderungserfassung. Erkennt das nicht erst vor wartenden Kunden.

Bewahrt nach dem Umzug Belege auf: Quell- und Zielversionen, Zeitstempel, Zeilenprüfungen, Funktionstests, DNS-Antworten, Entscheidungen und Abschaltzeit alter Dienste. Das beschleunigt Fehlersuche und schützt den nächsten Plan vor Gedächtnislücken.

Entscheidet nach Umkehrbarkeit

Die beste Phase ist die, in der ein realistischer Fehler noch umkehrbar bleibt. Vor dem Start gibt es wenig Belege, aber große Freiheit. Nach ersten Erfolgen gibt es Belege und zugleich Zustand, der während des gesamten Umzugs stimmig bleiben muss.

Ich nutze sechs Entscheidungstests:

• Vor dem Start umziehen, wenn eine bekannte Vorgabe zu Compliance, Eigentum, Export, Hosting oder Architektur die Veröffentlichung blockiert.
• Bleiben und starten, wenn die Plattform den Bedarf deckt und nur Unsicherheit den Umzug treibt.
• Nach ersten Erfolgen umziehen, wenn gemessene Nutzung eine Grenze zeigt und Identitäts-, Daten- und Verkehrskontinuität probbar sind.
• Warten, wenn keine wiederherstellbare Datenbank exportiert, die Domain nicht kontrolliert, Geheimnisse nicht erfasst oder Schreibverantwortung nicht festgelegt werden kann.
• Schrittweise trennen, wenn Authentifizierung oder Daten vorübergehend bleiben können, während Rechenbetrieb und Hosting umziehen.

Lovable, Bolt, v0 und Replit können Projekte erzeugen, deren Portabilität von ausgewählten Diensten, Tarif und dem gerade generierten Code abhängt. Prüft das wirkliche Repository und die Kontrollen eures Kontos. Eine Anbieterkategorie sagt nichts darüber, ob eure Hashes, Erweiterungen, Dateien oder Bereitstellungseinstellungen beweglich sind.

Bei einer neuen chatbasierten Entwicklungsumgebung senken Planung und Rücksetzpunkte die Kosten für kleine, prüfbare Änderungen. Koder.ai unterstützt Quellcodeexport, Bereitstellung und Hosting, eigene Domains, Snapshots und Rollback. So bleiben Eigentumsprüfungen Teil des Migrationsplans, ohne dass dieser Rat von einer Plattform abhängt.

Legt vor dem Start ein Migrationsbudget fest, auch wenn ihr bleibt. Kontrolliert den Quellcode, versioniert das Schema, dokumentiert den Umgebungsvertrag und probt eine Wiederherstellung. Solange die App klein ist, kostet das wenig und erhält die Umzugsoption, bis echte Nutzung einen Grund statt einer Krise liefert.

Kann das Team die Wiederherstellung heute nicht durchführen, ist Portabilität nur eine Absicht und keine Eigenschaft der App.