Kaputte Datenbank-Migrationen in KI-erstellten Apps sicher beheben

Warum KI-erstellte Apps mit kaputten Migrationen enden

Eine Datenbank-Migration ist ein kleines Skript, das Ihre Datenbank kontrolliert verändert. Stellen Sie sich das wie einen „Rezept-Schritt“ für Ihre Tabellen vor: eine Spalte anlegen, ein Feld umbenennen, einen Index hinzufügen. Migrationen sollen in Reihenfolge laufen, damit jede Umgebung am Ende dasselbe Schema hat.

KI-erstellte Apps brechen diese Kette oft, weil der Code schnell entsteht, ohne die sorgfältigen Gewohnheiten, mit denen Menschen die Historie sauber halten. Tools können Migrationen automatisch erzeugen, nach einem Prompt neu generieren oder Muster aus einem anderen Projekt kopieren. So entstehen Dateien, die zwar gültig wirken, aber nicht zueinander passen.

Häufige Ursachen sind:

• Zwei Migrationen, die dieselbe Tabelle unterschiedlich verändern
• Eine Migrationsdatei, die bearbeitet wurde, nachdem sie irgendwo bereits ausgeführt wurde
• Doppelte Migrationsnamen oder Zeitstempel, die auf verschiedenen Rechnern anders sortieren
• Migrationen, die gegen eine lokale Datenbank generiert wurden, die nicht mit Staging oder Prod übereinstimmt

„Auf meinem Rechner funktioniert es“ passiert, wenn Ihre lokale Datenbank zusätzliche manuelle Änderungen, fehlende Schritte oder eine andere Migrationsreihenfolge hat. Ihr App-Code passt zum lokalen Schema, alles scheint in Ordnung — bis Production die echte Migrationskette ausführt und auf eine fehlende Tabelle, eine doppelte Spalte oder einen Fremdschlüssel stößt, der nicht erstellt werden kann.

Dieses Problem tritt meist im schlimmsten Moment auf: beim ersten Deploy, wenn ein neuer Kollege das Setup von Grund auf ausführt, oder wenn CI eine saubere Datenbank anlegt und Migrationen strikt der Reihe nach ausführt.

Wenn Sie ein KI-erstelltes Prototyp-Projekt von Tools wie Lovable, Bolt, v0, Cursor oder Replit geerbt haben, ist dies eines der ersten Dinge, die FixMyMess bei einer Codebasis-Diagnose prüft, denn Migrationsprobleme bleiben oft bis zum Launch verborgen.

Symptome und Risiken — was Sie anschauen sollten, bevor Sie etwas anfassen

Kaputte Migrationen zeigen sich meist genau beim Deploy, aber die Ursache begann oft viel früher. KI-generierte Apps erzeugen Migrationen schnell und bearbeiten Modelle oder Schemata danach so, dass sie nicht mehr zu dem passen, was bereits in anderen Umgebungen lief.

Offensichtliche Anzeichen sind schwer zu übersehen: Deploys schlagen fehl mit „Tabelle nicht gefunden“ oder „Spalte existiert bereits“, Seiten stürzen ab, weil eine Abfrage ein Feld erwartet, das nicht existiert, oder Sie sehen fehlende Tabellen, die der Code voraussetzt. Ein weiteres Muster sind doppelte Spalten (z. B. user_id und userid) oder Indizes, die unter verschiedenen Namen doppelt angelegt wurden.

Die gefährlicheren Zeichen sind leise. Die App läuft vielleicht noch, aber Lokal, Staging und Production stimmen nicht mehr überein. Eine Umgebung hat eventuell einen neueren Spaltentyp, einen Default-Wert oder eine Constraint-Eigenschaft (z. B. NOT NULL), die die anderen nicht haben. Das führt zu „auf meinem Rechner funktioniert es“-Bugs: ein Feature besteht lokal die Tests, bricht aber in Produktion, oder schlimmer, schreibt falsche Daten, die erst später auffallen.

Bevor Sie kaputte Datenbank-Migrationen zu reparieren versuchen, achten Sie auf folgende Risiken:

• Datenverlust durch destruktive Migrationen auf dem falschen Schema
• Lange Downtime, wenn eine Migration große Tabellen sperrt oder langsame Backfills auslöst
• Teilweise Rollbacks, bei denen der Code zurückrollt, die Datenbank aber nicht sauber rückgängig machen kann
• Versteckte App-Fehler, wenn Code ein Schema annimmt, das nur in einer Umgebung existiert

Eine gute Regel: Wenn Sie nicht klar beantworten können „Welche Migrationen liefen in Prod und in welcher Reihenfolge?“, stoppen Sie. Führen Sie nicht blind weitere Migrationen aus, um „zu sehen, ob es klappt“. Das vergrößert meist die Abweichung zwischen den Umgebungen und erschwert die Wiederherstellung. Bei einem geerbten KI-Prototyp beginnen Teams wie FixMyMess oft mit einer Read-only-Prüfung, um festzulegen, was sicher läuft und was einen kontrollierten Neuaufbau braucht.

Starten Sie mit einer schnellen Inventur: Was existiert und wo

Bevor Sie kaputte Datenbank-Migrationen reparieren, verschaffen Sie sich einen klaren Überblick über das, was tatsächlich vorhanden ist. Die meisten Migrations-Desaster entstehen, weil Leute annehmen, Lokal, Staging und Production seien gleich — tun sie aber nicht.

Nennen Sie zuerst jede vorhandene Umgebung. Das umfasst in der Regel mindestens lokal (Ihr Laptop), Staging (ein Testserver) und Production (echte Nutzer). Wenn Sie Preview-Apps, alte Staging-Datenbanken oder eine zweite Produktionsregion haben, zählen diese ebenfalls dazu.

Erfassen Sie dann das aktuelle Schema in jeder Umgebung so, wie es jetzt ist, nicht wie Sie es sich wünschen. Nutzen Sie, was Ihr Stack bietet: ein Schema-Dump, ein Introspektionskommando oder einen read-only Export von Tabellen, Spalten, Indizes und Constraints. Speichern Sie diese Ausgaben mit Zeitstempeln, damit Sie sie später vergleichen können.

Sammeln Sie anschließend die Migrationsquellen und den Migrationsstatus:

• Den vollständigen Migrationsordner aus dem Repo (inklusive alter Dateien)
• Die Migrations-Tracking-Tabelle in der Datenbank (z. B. die Tabelle, die aufzeichnet, welche Migrationen gelaufen sind)
• Alle manuellen Notizen oder Skripte, die außerhalb von Migrationen genutzt wurden
• Den genauen Befehl, der fehlschlägt (und wer ihn ausgeführt hat)
• Den vollständigen Fehltext und wann er passiert (frisches Setup vs. nach Pull)

Zum Schluss schreiben Sie die Fehlergeschichte in einfachen Worten auf. Beispiel: „Lokal läuft es, Staging scheitert bei Migration 0042, Production hat manuell eine zusätzliche Spalte.“ Diese kurze Erzählung verhindert Spekulationen und beschleunigt die nächsten Schritte — besonders wenn Sie Hilfe wie FixMyMess für ein Audit hinzuziehen.

Prüfen Sie die Migrationshistorie auf Konflikte und Änderungen

Bevor Sie kaputte Datenbank-Migrationen reparieren, klären Sie, ob Ihre Migrationskette vertrauenswürdig ist. KI-generierte Apps erstellen oft schnell Migrationen und überschreiben später Dateien oder generieren neue, ohne zu beachten, was bereits in Production lief.

Lesen Sie die Migrationsliste von alt nach neu und prüfen Sie, ob die Reihenfolge sauber ist. Lücken sind nicht immer fatal, aber ein Hinweis darauf, dass Dateien umbenannt, gelöscht oder neu generiert wurden. Achten Sie auch auf doppelte IDs oder Zeitstempel, die dazu führen könnten, dass zwei unterschiedliche Migrationen denselben „Slot“ beanspruchen.

Suchen Sie als Nächstes nach Bearbeitungen alter Migrationen. Wenn eine Migration irgendwo angewendet wurde (Staging oder Prod) und die Datei später geändert wurde, haben Sie zwei Wahrheiten: Die Datenbank hat eine Version und Ihr Repo eine andere. Ein schneller Check sind Dateidaten, Commit-Historie oder Hinweise wie „fix“ in älteren Migrationsdateien.

Branch-Merges sind eine weitere häufige Konfliktquelle. Zwei Branches können jeweils eine „nächste Migration“ hinzufügen, sodass beim Merge konkurrierende Migrationen entstehen, die beide annehmen, sie seien die nächste. Das zeigt sich oft als zwei neue Migrationsdateien, die innerhalb weniger Minuten erstellt wurden, aber unterschiedlichen Inhalt haben.

Gehen Sie außerdem davon aus, dass in mindestens einer Umgebung manuelle Änderungen passiert sind. Wenn jemand in Production einen Index hinzugefügt, einen Spaltentyp hotfixed oder ein SQL-Snippet ausgeführt hat, spiegeln Ihre Migrationen das nicht.

Eine schnelle Audit-Checkliste:

• Bestätigen Sie, dass Migrations-IDs einzigartig und streng ansteigend sind
• Markieren Sie alte Migrationsdateien, die nach ihrer Erstellung bearbeitet wurden
• Identifizieren Sie „parallele“ Migrationen, die auf separaten Branches erstellt wurden
• Notieren Sie Schemaänderungen, die in der DB existieren, aber nicht in Migrationen
• Schreiben Sie auf, welche Umgebungen wahrscheinlich abweichen (lokal, staging, prod)

Wenn das chaotisch wirkt — das ist normal für Prototypen von Tools wie Cursor oder Replit. Teams wie FixMyMess starten oft genau mit diesem Audit, bevor sie entscheiden, ob sie die Kette reparieren oder neu aufbauen.

Drift zwischen Umgebungen erkennen, ohne zu raten

Migrations-Drift entsteht, wenn zwei Umgebungen (lokal, staging, prod) unterschiedliche Schemata haben, obwohl sie gleich sein sollten. Bei KI-generierten Apps passiert das oft nach „Quick Fixes“ direkt in der Datenbank oder nachdem Migrationen bearbeitet und neu ausgeführt wurden.

Vergleichen Sie die Schemata selbst, nicht nur die Migrationsdateien. Sie brauchen ein klares, schriftliches Diff dessen, was in jeder Umgebung existiert: Tabellen, Spalten, Datentypen, Indizes und Constraints (insbesondere Fremdschlüssel und Unique-Constraints). Das sind die Unterschiede, die meistens erklären, warum ein Endpoint lokal funktioniert, in Prod aber fehlschlägt.

Ein schneller, praktischer Weg ist, einen Schema-Snapshot aus jeder Umgebung zu exportieren (ein schema-only Dump oder ein Introspektions-Output Ihres ORM) und sie Seite an Seite zu vergleichen. Konzentrieren Sie sich bei der Prüfung auf Objekte, die Verhalten ändern:

• Fehlende oder zusätzliche Spalten, die Code liest/schreibt
• Unterschiedliche Nullability oder Default-Werte
• Fehlende Unique-Constraints (plötzlich sind Duplikate möglich)
• Fehlende Fremdschlüssel (oder unterschiedliche Cascade-Regeln)
• Index-Unterschiede, die unter realer Last zu Timeouts führen

Trennen Sie „erwartete Unterschiede“ von echter Drift. Seed-Daten, Admin-Testnutzer und dev-only Feature-Flags dürfen abweichen. Schema-Unterschiede sind selten „erwartet“. Weicht das Schema ab, gehen Sie davon aus, dass irgendwann etwas kaputtgeht.

Wählen Sie dann eine Quelle der Wahrheit. Das ist eine Entscheidung, kein Raten. Meistens sollte Production gelten, wenn dort echte Nutzer bedient werden, aber manchmal ist Prod selbst das Durcheinander (z. B. weil während einer Panik manuell Spalten ergänzt wurden). Wenn Sie kaputte Datenbank-Migrationen reparieren, wählen Sie die Umgebung mit dem vollständigsten und korrektesten Schema und dokumentieren Sie warum.

Beispiel: Ein Prototyp in Replit funktioniert lokal, aber Signup schlägt in Prod fehl. Das Diff zeigt, dass in Prod ein Unique-Index auf users.email fehlt, sodass Duplikate entstanden und die Auth inkonsistent wurde. Diese eine Schema-Drift erklärt die „zufälligen“ Login-Fehler und zeigt genau, was zuerst repariert werden muss.

Schritt für Schritt: Ein sicherer Wiederherstellungsplan

Kaputte Migrationen wirken dringend, aber Eile verwandelt ein Schema-Problem schnell in Datenverlust. Der sicherste Plan ist bewusst langweilig: Änderungen pausieren, einen verlässlichen Wiederherstellungspunkt erstellen und die Reparatur vorher proben.

Zuerst: Deployment einfrieren. Stoppen Sie Auto-Deploys, Hintergrundjobs, die Migrationen beim Start anwenden, und alle „einfach pushen“-Releases. Wenn die App kunden-facing ist, legen Sie ein Wartungsfenster fest und kommunizieren Sie, was gesperrt ist: Datenbankschema, ORM-Modelle und Code, der in die betroffenen Tabellen schreibt.

Als Nächstes: Machen Sie ein Backup, das Sie tatsächlich getestet haben. Akzeptieren Sie nicht einfach „Backup erfolgreich“ in den Logs. Stellen Sie das Backup in einer separaten Datenbank wieder her, führen Sie eine einfache Abfrage aus, um Haupttabellen und aktuelle Zeilen zu prüfen, und verifizieren Sie die Verbindung der App. Wenn Sie das nicht wiederherstellen können, haben Sie kein verlässliches Backup.

Reproduzieren Sie nun den Fehler an einem sicheren Ort mit einer Kopie der Produktionsdaten (oder einem anonymisierten Snapshot). Führen Sie genau den Migrationsbefehl aus, wie er in Production läuft. Erfassen Sie den ersten Fehler und den Namen der Migrationsdatei — der erste Fehler ist meist der entscheidende Hinweis.

Dann wählen Sie Ihren Wiederherstellungsansatz. Ist das Problem klein (fehlende Spalte, bearbeitete Migration oder partielle Ausführung), dann reconciliieren Sie: Schreiben Sie eine korrigierende Migration, die das Schema vom aktuellen Zustand zum erwarteten Zustand bringt. Ist die Historie verheddert (konkurrierende Änderungen, doppelte IDs, Drift zwischen Umgebungen), bauen Sie neu: Erstellen Sie einen sauberen Baseline aus dem aktuellen Schema und starten die Kette neu.

Vor dem Go-Live führen Sie einen vollständigen End-to-End-Lauf durch: Starten Sie mit einer leeren Datenbank, wenden Sie alle Migrationen an, seed-en Sie minimale Daten und führen Sie einen Smoke-Test aus. Hier fangen Sie „auf meinem Rechner funktioniert es“-Drift ab.

Wenn Sie kaputte Datenbank-Migrationen in einer KI-generierten Codebasis (Lovable, Bolt, v0, Cursor, Replit) beheben, beginnen Teams wie FixMyMess oft genau mit diesem Probelauf, damit die Änderung in Production vorhersehbar statt heldenhaft wird.

Eine saubere Migrationskette neu aufbauen (Baseline, Squash und Reset)

Eine saubere Migrationskette macht Deploys wieder langweilig. Wenn Sie kaputte Datenbank-Migrationen reparieren müssen, löschen Sie nicht einfach Dateien. Entscheiden Sie zuerst, ob Sie das Bestehende stabilisieren oder eine neue, gut dokumentierte Basis erstellen.

Baseline: Wann sie erstellt werden sollte (und wann nicht)

Erstellen Sie eine neue Baseline-Migration, wenn das Produktionsschema korrekt ist, die Migrationshistorie aber unordentlich, bearbeitet oder außer Reihenfolge ist. Ziel ist, das aktuelle Schema als neuen Startpunkt zu erfassen.

Erstellen Sie keine Baseline, wenn Production nicht vertrauenswürdig ist (unbekannte manuelle Änderungen, fehlende Tabellen oder Datenprobleme). Dann müssen Sie zuerst das Schema reparieren und danach baselinen.

Squash und Reset: Historie sicher aufbewahren

Wenn Migrationen bereits in Production angewendet wurden, vermeiden Sie es, die Historie an Ort und Stelle umzuschreiben. Behandeln Sie die alte Kette stattdessen als „Legacy“ und ziehen Sie einen klaren Cutoff.

Ein sicheres Vorgehen ist:

• Den aktuellen Zustand einfrieren: Daten sichern und die Schema-Version in jeder Umgebung notieren
• Eine einzige „gesquashte“ Migration erzeugen, die das aktuelle Schema exakt abbildet
• Diese als neue Baseline markieren (z. B. mit einer Notiz im Repo und Deploy-Dokumentation)
• Alte Migrationen in einem separaten Ordner oder deutlich markiert behalten, aber nicht mehr anwenden
• Für neue Setups nur noch Baseline + neue Migrationen ausführen

Stellen Sie sich einen Prototyp vor, bei dem lokal 42 Migrationen existieren, Staging 39 und Prod manuell gefixte Tabellen hat. Ein blindes Squashen von lokal passt nicht zu Prod. Die richtige Vorgehensweise ist, von dem Schema zu baselinen, das Sie als Quelle der Wahrheit gewählt haben (meist Prod), und dann die Vorwärtsänderungen als neue Migrationen anzulegen.

Dokumentieren Sie die Baseline in einfachen Worten: Datum, Quellumgebung, exakter Schema-Snapshot und die Regel für neue Setups. Teams wie FixMyMess fügen diese Dokumentation oft als Teil der KI-App-Remediation hinzu, weil künftige Deploys davon abhängen.

Testen und Ausrollen der Lösung ohne Risiko für echte Daten

Behandeln Sie Ihre Migrationslösung wie ein Release, nicht wie einen schnellen Patch. Der sicherste Ort zum Verifizieren ist eine Staging-Umgebung, die Production gleicht: gleiche DB-Engine und Version, ähnliche Extensions, gleiche Umgebungsvariablen und ein Abbild des Produktionsschemas (idealerweise mit einem kleinen, anonymisierten Datenschnitt).

Vor jedem Test: Machen Sie ein frisches Backup, das Sie wiederherstellen können. Rollback-Pläne scheitern oft, weil man davon ausgeht, Down-Migrationen würden Änderungen sauber rückgängig machen. In echten Vorfällen ist das realistischste Rollback meist das Wiederherstellen eines Snapshots.

Stellen Sie sicher, dass Migrationen wiederholbar sind

Eine Migration, die „einmal funktioniert“, kann trotzdem gefährlich sein. Führen Sie die komplette Migrationskette in Staging aus, setzen Sie die Staging-DB zurück und führen Sie sie erneut aus. Sie sollten jedes Mal dasselbe Ergebnis erhalten.

Achten Sie auf Warnsignale wie Zeitstempel als Default-Werte, nicht-deterministische Data-Backfills oder Migrationen, die von aktuellem Tabelleninhalt abhängen.

Validieren Sie die App, nicht nur das Schema

Nach Migrationen starten Sie die App und testen die wichtigen Abläufe: Registrierung/Login, Erstellen und Bearbeiten zentraler Datensätze, Suche/Filter und Admin-Bereiche. Starten Sie außerdem Hintergrundjobs und geplante Tasks, denn die greifen oft auf Spalten zu, die umbenannt oder auf NOT NULL gesetzt wurden.

Führen Sie den Rollout klein und kontrolliert durch:

• Kündigen Sie ein kurzes Wartungsfenster an (auch wenn Sie auf Zero Downtime hoffen)
• Wenden Sie zuerst die Migrationen an, dann deployen Sie den App-Code, der das neue Schema erwartet
• Überwachen Sie Fehler und langsame Queries direkt nach dem Release
• Seien Sie bereit, die DB wiederherzustellen, wenn etwas schief aussieht

Wenn die App KI-generiert ist, prüfen Sie versteckte Schema-Annahmen im Code. FixMyMess sieht oft Prototypen, bei denen die UI lokal funktioniert, Production aber wegen fehlender Migrationen, bearbeiteter Migrationsdateien oder unterschiedlicher Secrets scheitert.

Häufige Fehler, die Migrationsprobleme verschlimmern

Der schnellste Weg, aus einem Migrationschaos einen echten Ausfall zu machen, ist „patchen, bis es läuft“, ohne zu wissen, was wo gelaufen ist. Ziel beim Reparieren kaputter Datenbank-Migrationen ist nicht nur, die App wieder startklar zu machen, sondern jede Umgebung auf eine gemeinsame, erklärbare Historie zurückzuführen.

Ein häufiger Fehler ist, eine alte Migration zu editieren, die bereits in Production gelaufen ist. Ihr Code sagt nun etwas anderes als die Production-DB. Ein Kollege führt frisches Setup aus, Staging benutzt eine andere Kette und Sie haben zwei Timelines geschaffen, die sich nie mehr angleichen lassen.

Ein anderer Fehler ist, Drift zu „reparieren“, indem man die Datenbank manuell ändert. Beispiel: Jemand fügt in Production eine fehlende Spalte direkt hinzu, damit die Fehler verschwinden, aber die Migrationsdateien stimmen immer noch nicht. Die App läuft vielleicht einen Tag, dann versucht das nächste Deploy, die Spalte erneut hinzuzufügen, scheitert und blockiert alle weiteren Migrationen.

Typische Fehler in KI-generierten Apps sind:

• Down-Migrationen als Sicherheitsnetz behandeln, obwohl nie ein Rollback auf echten Daten getestet wurde
• Constraints und Indizes weglassen, weil die App „ohne sie läuft“ — später folgen langsame Queries und schlechte Daten
• Eine Migrationszeile aus der Migrations-Tabelle löschen, um Fehler zu unterdrücken
• Tabellen oder Spalten außerhalb von Migrationen umbenennen und sich dann wundern, warum ORM-Modelle drift
• Schemaänderungen und Data-Backfills in einer Migration mischen, was die Wiederherstellung erschwert

Schnelle Fixes verstecken oft nur das Symptom und vergrößern die Drift. Sie kommen vielleicht an dem akuten Fehler vorbei, aber die nächste Umgebung (oder der nächste Entwickler-Rechner) bricht auf neue Weise.

Wenn Sie einen Prototypen von Lovable, Bolt oder Replit geerbt haben, gehen Sie davon aus, dass Migrationen in Eile erzeugt wurden. Teams wie FixMyMess bestätigen zuerst, was in Production lief, und bauen dann einen sauberen Weg nach vorne, ohne die Historie in-place umzuschreiben.

Kurze Checkliste vor dem Deploy

Wenn Ihre Migrationen von einem KI-Tool generiert wurden, erwarten Sie Lücken. Eine ruhige Checkliste hilft, den schlimmsten Fehler zu vermeiden: es erst in Production zu merken.

Bevor Sie Production anfassen

Machen Sie ein Backup und beweisen Sie, dass es funktioniert. „Backup gemacht“ ist nicht dasselbe wie „Restore getestet“. Stellen Sie das Backup in eine frische DB wieder her, öffnen Sie die App und prüfen Sie, ob Haupttabellen und aktuelle Datensätze vorhanden sind.

Führen Sie dann ein Schema-Diff über jede relevante Umgebung durch (lokal, staging, production). Notieren Sie, was unterschiedlich ist. Wenn Production eine zusätzliche Spalte oder einen fehlenden Index hat, schreiben Sie das auf.

Wählen Sie eine einzige Quelle der Wahrheit und dokumentieren Sie die Entscheidung. Entscheiden Sie, ob Production-Schema, ein bestimmter Migrations-Branch oder eine bekannte gute Umgebung die Referenz ist. Legen Sie diese Wahl schriftlich fest, damit niemand während des Deploys „die falsche Seite“ repariert.

Beweisen Sie, dass die Migrationskette sicher ist

Führen Sie die komplette Migrationsfolge auf einer production-ähnlichen Kopie aus. Das heißt: Kopie der Prod-Daten (oder anonymisierte Daten mit derselben Struktur), gleiche DB-Version und derselbe Migrationsbefehl wie beim Deploy. Achten Sie auf lange Locks, fehlende Constraints und „funktioniert nur lokal“-Unterschiede.

Stellen Sie sicher, dass Ihr Plan Validierung und Rollback umfasst:

• Validierung: grundlegender Login, einige wichtige Lese-/Schreib-Operationen und schnelle Prüfungen kritischer Tabellen/Zeilenanzahlen
• Rollback: klare Schritte, um die App-Version zurückzusetzen und die DB wiederherzustellen, falls nötig

Beispiel: Wenn Staging „ahead“ von Prod ist, weil ein KI-Tool lokal eine zusätzliche Migration erstellt hat, dann pausieren Sie und gleichen diese Differenz zuerst ab. Mit dieser Drift zu deployen endet meist in einem fehlgeschlagenen Deploy oder stillen Dateninkonsistenzen.

Wenn Sie eine unordentliche KI-generierte Codebasis geerbt haben, beginnt FixMyMess oft genau hier: mit einem kostenlosen Audit, das die Quelle der Wahrheit bestätigt, die Drift kartiert und den Recovery-Plan prüft, bevor etwas live geht.

Beispiel: Recovery eines Prototyps, der zwischen Lokal und Prod driftete

Ein Gründer liefert einen KI-gebauten Prototyp, der lokal einwandfrei läuft. Beim Deploy in Production schlägt Migration 012 mit „Spalte existiert bereits“ fehl. Die App startet nicht, und jeder weitere Deploy wiederholt den Fehler.

Bei genauerem Hinsehen ist das Problem nicht eine einzelne fehlerhafte Datei. Zwei Branches hatten jeweils eine leicht unterschiedliche Änderung an derselben Tabelle eingeführt (z. B. beide fügten ein status-Feld zur users-Tabelle hinzu — der eine machte es nullable, der andere setzte einen Default). Lokal hat der Entwickler die Migration eines Branches angewendet; in Production lief zuvor die des anderen Branches. Nun stimmen Migrationshistorie und reales Schema nicht mehr überein.

Der sicherste Weg ist, Production als Quelle der Wahrheit zu behandeln, von diesem Schema zu baselinen und dann nur noch vorwärts zu gehen.

Praktisch sieht das so aus:

• Deploys einfrieren und vollständiges Backup machen (inkl. Restore-Test)
• Produktionsschema und Migrations-Tabelle prüfen, um zu sehen, was wirklich gelaufen ist
• Eine Baseline-Migration erstellen, die Production heute exakt widerspiegelt (keine Änderungen, nur Angleichung)
• Eine neue, saubere Forward-Chain schreiben, die die fehlenden Änderungen in kleinen, expliziten Schritten anwendet

Validieren Sie danach die App mit realen Flows, nicht nur, ob die Migrationen durchliefen. In diesem Beispiel testen Sie Login (Sessions, Passwort-Reset), Abrechnung (Webhooks, Rechnungen) und die Dashboards, die von der geänderten Tabelle abhängen.

Das ist ein typisches Muster, wenn Sie kaputte Datenbank-Migrationen in KI-generierten Apps reparieren: Versuchen Sie nicht, Production an eine unordentliche lokale Historie zu zwingen. Machen Sie die Historie zur Production, und fügen Sie dann sichere, vorwärtsgerichtete Migrationen hinzu. Wenn Sie unsicher sind, welche Schema-Version korrekt ist, kann FixMyMess zuerst die Codebasis und die Migrationstrail auditieren, damit Sie nicht den harten Weg in Production lernen.

Nächste Schritte: Migrationen stabil halten und wissen, wann Hilfe nötig ist

Nachdem Migrationen wieder funktionieren, ist das Ziel langweilige Konsistenz. Entscheiden Sie zuerst, ob Sie eine kleine Reparatur brauchen (eine falsche Migration, eine fehlende Datei, falsche Reihenfolge) oder einen kompletten Neuaufbau (Historie bearbeitet, Umgebungen stimmen nicht überein und "latest" ist nicht vertrauenswürdig). Wenn nach einem sauberen Testlauf auf einer frischen DB weiterhin Überraschungen auftreten, tendieren Sie zum Neuaufbau.

Eine einfache Präventionsmaßnahme ist ein kurzes „Schema-Vertrag“-Dokument, dem alle folgen. Legen Sie es ins Repo — es muss nicht aufwendig sein, aber klar:

• Nur neue Migrationen erstellen, alte Migrationen nicht mehr editieren, nachdem sie ausgeliefert wurden
• Jede Migration sollte reversibel sein (oder erklären, warum nicht)
• Eine verantwortliche Person finalisiert Merges, wenn mehrere Branches die DB berühren
• Änderungen am Production-Schema erfolgen ausschließlich über Migrationen, nicht per manueller Konsole
• Eine frische Installation (leere DB → latest) muss in CI funktionieren, bevor deployt wird

Wenn Ihre App von Lovable, Bolt, v0, Cursor oder Replit generiert wurde, erwarten Sie mehr versteckte Drift als üblich. Der Code könnte beim Start Tabellen erzeugen, unerwartet Daten seed-en oder lokal SQLite verwenden, während Production Postgres läuft. Behandeln Sie die Datenbank als integralen Teil der App, nicht als Nachgedanken.

Wissen Sie, wann Sie eine zweite Meinung brauchen: Wenn Sie echte Kundendaten haben, mehrere widersprüchliche Umgebungen oder unsicher sind, ob ein „Fix“ Spalten löschen oder Constraints umschreiben könnte — dann pausieren. FixMyMess bietet ein kostenloses Code-Audit an, um Migrationsprobleme zu lokalisieren und sichere Fixes vorzuschlagen, was oft schneller ist, als unter Zeitdruck zu raten.