Von Lovable zu Cursor: So migrierst du ein Live-SaaS sicher

Um eine Lovable-App sicher nach Cursor zu übertragen, öffnest du das Quell-Repository in Cursor, bildest den bestehenden Build nach und veröffentlichst eine minimale Änderung, ohne das Backend anzufassen. Authentifizierung, Abrechnung und Kundendaten bleiben genau dort, wo sie bereits funktionieren. Dieses Playbook führt durch das Handoff, kalkuliert ein Zeitbudget von 8 bis 14 Stunden ein, liefert einen Audit-Prompt per Copy-Paste und enthält die Release-Checks, die vor teuren Überraschungen schützen.

Was sich beim Wechsel wirklich ändert

Ein aktives SaaS verlangt keinen dramatischen Rewrite, nur weil du den Editor wechseln willst. Der eigentliche Übergang ist viel kleiner: Lovable hat dir beim Bau der ersten Version geholfen, Cursor wird nun der Ort, an dem du Code prüfst, bearbeitest, testest und wartest.

Das ist eine reine Migration des Entwicklungs-Workflows. Ein Hosting-Umzug ist etwas völlig anderes. Eine Datenbank-Migration ebenfalls.

Behandelt man alle drei Baustellen als eine einzige Aufgabe, wird die Fehlersuche schnell zum Albtraum. Wenn der Login streikt, nachdem du gleichzeitig Frontend, Auth-Provider und Domain umgezogen hast, gibt es drei plausible Ursachen statt nur einer.

Lass funktionierende Teile unangetastet

| Ebene | Empfehlung für das erste Handoff | Grund | |---|---|---| | Quellcode | Im verknüpften oder exportierten Repository arbeiten | Versionshistorie sichern und eine editierbare Basis etablieren | | Editor | Projekt in Cursor öffnen | Entwicklungsumgebung wechseln | | Datenbank | Bestehenden Dienst beibehalten | Unnötige Wanderung von Kundendaten vermeiden | | Authentifizierung | Provider und bestehende Produktions-URLs behalten | Risiken bei Login und Sessions minimieren | | Abrechnung | Zahlungs-Account und aktive Webhook-Endpoints behalten | Abonnements und Berechtigungslogik absichern | | Hosting | Beibehalten, sofern es deinen Release-Workflow unterstützt | Codeänderungen nicht mit Infrastrukturwechseln vermischen |

Zugriff auf den Quellcode garantiert noch lange keine portable Infrastruktur. Ein Repository kann Frontend-Code und Serverfunktionen enthalten, ohne dass Secrets, Datenbankeinträge oder sämtliche Service-Einstellungen darin liegen.

Stand Oktober 2026 bleibt die sicherste Regel: Analysiere dein konkretes Projekt und deine Berechtigungspläne, statt blind darauf zu vertrauen, dass dein Setup dem irgendeines Tutorials entspricht.

Wechsle aus einem konkreten Grund

Gute Gründe sind etwa eine bessere Navigation im Code, reproduzierbare Tests, kontrolliertes Refactoring oder ein Review-Prozess, der auch mit externen Entwicklern funktioniert.

"Echte Gründer nutzen vollwertige Code-Editoren" ist kein Argument. Frust über eine einzelne schlechte KI-Generierung genauso wenig.

Wenn Lovable deine Änderungen nach wie vor zuverlässig umsetzt, bleib einfach dort. Wechsle erst, wenn dein aktueller Workflow eine konkrete technische Aufgabe blockiert, nicht schon dann, wenn sich ein neues Tool-Abo nach Fortschritt anfühlt.

Die App auditieren und einen Rollback-Punkt setzen

Für eine kleine, ordentlich dokumentierte App solltest du hier 1 bis 2 Stunden einplanen. Kannst du auf Anhieb nicht sagen, wo Auth oder Billing laufen, stoppe die Migration und finde es zuerst heraus.

1. Kartiere die Runtime, nicht nur die Dateien

Erstelle `docs/runtime-map.md` und halte fest:

• Wo das Frontend gehostet wird und wie Releases ablaufen.
• Welche Datenbank genutzt wird und wem das Konto gehört.
• Welcher Dienst die Authentifizierung übernimmt.
• Wo Serverless Functions ausgeführt werden.
• Wo Payment-Webhooks und Cronjobs laufen.
• Welche Dienste für Mailversand, Storage oder KI angebunden sind.
• Wo die Umgebungsvariablen konfiguriert sind.

Notiere Variablennamen und Speicherorte, niemals geheime Werte. Kopiere niemals Zugangsdaten in einen KI-Chat.

Trenne browser-sichere Konfigurationen strikt von reinen Server-Secrets. Eine öffentliche Client-ID darf im Frontend-Code stehen, Zugangsdaten für Datenbank-Admins oder Payment-Secrets haben dort nichts verloren. Ein harmlos klingender Variablenname ist noch kein Beweis für Sicherheit.

2. Definiere das Verhalten, das erhalten bleiben muss

Nimm zwei Test-Accounts mit getrennten Organisationen oder Workspaces. Dein minimaler Testpfad lautet:

1. Account anlegen und einloggen.
2. Den primären Datensatz der App erstellen.
3. Seite neu laden und prüfen, ob der Eintrag persistiert wurde.
4. Sicherstellen, dass der zweite Account keinen Zugriff darauf hat.
5. Den Subscription-Ablauf in einer Testumgebung durchspielen.
6. Ausloggen und prüfen, ob geschützte Seiten gesperrt sind.

Ergänze den Workflow, für den Kunden tatsächlich zahlen. Bei einem Reporting-SaaS wäre das etwa der Upload einer Testdatei und die Report-Erstellung. Eine hübsche Login-Maske beweist noch nicht, dass das Produkt funktioniert.

Protokolliere bestehende Fehler, bevor du eine einzige Zeile anfasst. Sonst suchst du später stundenlang nach Ursachen in Cursor für Bugs, die schon vorher da waren.

3. Code sichern und Wiederherstellung absichern

Sobald das Repository sauber und die Ausgangslage überprüft ist, setzt du eine Markierung:

```bash git status git tag pre-cursor-handoff git push origin pre-cursor-handoff ```

Prüfe vor dem Push, ob versehentlich Secrets committet wurden. Falls ja, rotiere diese umgehend; eine Datei nachträglich zu löschen, tilgt sie nicht aus der Git-Historie.

Das Tag sichert nur den Code, nicht die Kundendaten. Prüfe separat deine Backup-Optionen für die Datenbank, teste das Restore-Verfahren und notiere das letzte erfolgreiche Backup. Ein Backup, das du nicht einspielen kannst, ist nur ein beruhigender Dateiname.

Dokumentiere die ID des aktuellen Produktions-Deployments und wie du genau diesen Stand wiederherstellst. Bietet dein Hoster kein simples Rollback, baue dir einen getesteten Redeploy-Pfad, bevor du die erste Änderung vornimmst.

Lass das Datenbankschema während dieses Handoffs unangetastet. Das hält spätere Code-Rollbacks simpel.

Entwicklung in fünf Schritten nach Cursor verlagern

Das Ziel ist ein reproduzierbares Projekt und ein winziger, geprüfter Patch. Nicht eine grundsanierte Architektur bis Sonntagabend.

Schritt 1: Repository öffnen und Ownership sichern

Nutze die bestehende GitHub-Verknüpfung oder den Exportpfad, um an den Quellcode zu kommen, klone ihn lokal und öffne den Ordner in Cursor.

Lies `README`, `package.json`, Lockfiles und Deployment-Configs, bevor du irgendwelche Befehle ausführst. Nicht jedes Lovable-Projekt nutzt identische Skripte oder dieselbe Infrastruktur.

Erstelle einen Arbeitszweig:

```bash git switch -c cursor-handoff ```

Entscheide dich für einen primären Workflow während des Wechsels. Vermeide es, dass Lovable und Cursor gleichzeitig Änderungen auf denselben Branch schreiben.

Prüfe genau, wie die Lovable-GitHub-Integration mit Branches und eingehenden Commits umgeht, bevor du Änderungen hin und her synchronisierst. Zugriff auf das Repo bedeutet noch nicht, dass jede lokale Änderung sauber im visuellen Builder ankommt.

Schritt 2: Den bestehenden Build lokal nachbauen

Halte dich exakt an die im Projekt vorgegebene Runtime-Version und den Package Manager. Aktualisiere während des Handoffs keine Dependencies.

Für ein npm-Projekt mit eingecheckter `package-lock.json` startest du so:

```bash npm ci npm run ```

Der zweite Befehl listet die verfügbaren Skripte auf. Führe nur die dokumentierten Befehle für Development, Build, Linting und Tests aus, die auch wirklich existieren. Erfinde keine erfolgreichen Testergebnisse, wenn gar kein Test-Skript existiert.

Baut das unveränderte Projekt nicht, halte die exakte Fehlermeldung fest und behebe dieses Problem isoliert. Ein Missverhältnis beim Package Manager ist kein Grund, die komplette App neu zu generieren.

Schritt 3: Entwicklung von der Produktion isolieren

Nutze nach Möglichkeit ein separates Backend für die Entwicklung. Falls nicht verfügbar, beschränke lokale Tests auf synthetische Daten und stark eingeschränkte Rechte. Mache keine destruktiven Experimente mit echten Kundendaten.

Richte die lokale Umgebungsdatei des Projekts ein und stelle sicher, dass Git sie ignoriert. Eine Beispieldatei mit Platzhaltern gehört ins Repo, echte Werte nicht.

Authentifizierung erfordert besondere Vorsicht. Trage die nötigen Redirect-URLs für Localhost oder Previews beim Auth-Provider ein, ohne die produktiven URLs zu verändern. Teste auch Passwort-Resets oder Magic Links, falls die App sie nutzt.

Nutze für Abrechnungstests Test-Keys und eine dedizierte Test-Webhook-URL. Leite niemals den produktiven Webhook für Abonnements auf deinen lokalen Rechner um.

Einige gehostete Funktionen laufen lokal eventuell nicht. Dokumentiere, welche Aufrufe dennoch entfernte Services ansprechen, welche Umgebung betroffen ist und ob dadurch Kosten oder bleibende Änderungen entstehen.

Schritt 4: Cursor vor der ersten Änderung auditieren lassen

Nutze diesen Prompt, sobald das Projekt geöffnet ist:

```text Act as the maintainer taking over this existing SaaS repository. Start in read-only mode. Do not edit files or run deployment, installation, migration, or destructive commands.

Inspect the code and report:

1. Framework, runtime, package manager, and available scripts.
2. Frontend entry points and protected routes.
3. Database, authentication, billing, and server-function boundaries.
4. Environment variable names and where they are referenced.

Never print secret values or read local secret files.

1. Existing tests and missing checks for the core user journey.
2. Code or configuration that appears tied to hosted services.

Distinguish verified findings from assumptions. Cite file paths. Do not claim a check passed unless it was actually executed.

Propose one small, reversible improvement with no schema changes, no dependency upgrades, and no authentication or billing changes. List acceptance criteria and a rollback plan. Wait for approval. ```

Das Ergebnis sollte eine prüfbare Übersicht sein, kein theoretischer Aufsatz. Öffne die genannten Dateien und kontrolliere wichtige Aussagen gegen. Für spezifischere Arbeitsabläufe hilft dir die Prompt-Bibliothek.

Schritt 5: Einen bewusst unspektakulären Patch deployen

Wähle eine kleine Änderung: einen verbesserten Empty State, eine klarere Validierungsmeldung oder einen behobenen Layoutfehler.

Weise Cursor an, nur die absolut notwendigen Dateien zu bearbeiten. Prüfe das Git-Diff gründlich auf geänderte Dependencies, entfernte Authorization-Checks, unerwartete Config-Änderungen oder ungefragte Aufräumarbeiten.

Lass die Tests und Build-Checks erneut laufen. Wenn eine winzige UI-Korrektur plötzlich 40 Dateien anfasst, brich ab und prüfe den Grund.

Rechne mit 2 bis 3 Stunden für das lokale Setup und 3 bis 5 Stunden für die Analyse, den ersten Patch und die Verifikation. Fehlende Dokumentation kann den Zeitaufwand schnell vergrößern.

Sicher releasen und entscheiden, was bleibt

Plane weitere 2 bis 4 Stunden für Preview-Tests, das eigentliche Deployment und Checks nach dem Release ein. Damit liegt das Gesamtbudget bei 8 bis 14 Stunden - exklusive Backend-Migrationen, größerer Bugfixes oder der Einarbeitung in ein neues Framework.

Übergangsbudget festlegen

Diese Zahlen sind Richtwerte für die Planung, keine Preisgarantien von Anbietern für Oktober 2026. Laufende Abos und Serverkosten fallen regulär weiter an.

| Übergangskosten | Empfohlener Puffer | Mögliche Kostentreiber | |---|---:|---| | Temporäre Preview- oder Testinfrastruktur | 0 - 30 $ | Separate Datenbank oder kostenpflichtige Preview-Umgebungen | | Zusätzliche KI-Nutzung | 0 - 40 $ | Wiederholte Audits mit großem Kontext und weitreichende Rewrites | | Test-Mails, Storage und API-Calls | 0 - 10 $ | Echte externe API-Aufrufe statt Mockdaten | | Unvorhergesehenes | 20 $ | Unerwartete Test- oder Deployment-Hürden | | Gesamte Zusatzreserve | 20 - 100 $ | Keine garantierte Obergrenze |

Prüfe die aktuellen Abrechnungsmodelle beider Tools, bevor du parallele Abos abschließt. Die Lovable Preisübersicht hilft dir zu verstehen, welche Nutzungs- und Hosting-Aspekte du prüfen solltest.

Die meiste Zeit frisst die Entwicklerarbeit. Zehn Stunden für die Rekonstruktion der Infrastruktur kosten oft mehr als ein weiterer Monat eines Builders, der seinen Zweck erfüllt.

Release-Checkliste

• [ ] Der unveränderte Ausgangsstand baute fehlerfrei.
• [ ] Der Patch liegt auf einem eigenen Branch und wurde gereviewt.
• [ ] Keine Secrets im Diff oder in getrackten lokalen Dateien.
• [ ] Produktions-URLs für Auth blieben unangetastet.
• [ ] Datenzugriff zwischen Accounts wurde getestet und blockiert.
• [ ] Billing-Checks liefen über ein separates Test-Setup.
• [ ] Verhalten in der Preview deckt die Kernfunktionen ab.
• [ ] Keine Schema-Änderungen an der Datenbank, keine unnötigen Dependency-Updates.
• [ ] Das vorherige Produktions-Deployment kann wiederhergestellt werden.
• [ ] Das Deployment auf Produktion enthält exakt den gewünschten Commit.

Deploye zu einem Zeitpunkt, an dem du Zeit hast, das System zu beobachten. Wiederhole Login, Datensatzerstellung, Persistenz und den Bezahlprozess sofort mit einem Test-Account. Behalte Logs und Error-Tracking im Blick.

Sollten Zugriffsrechte versagen oder fremde Daten sichtbar werden, stoppe das Release sofort. Tritt eine gewöhnliche Regression auf, setze den Rollback über den getesteten Pfad um. Lass kein KI-Modell hektische Schnellreparaturen live über mehrere Produktivsysteme hinweg improvisieren.

Tools nach Aufgaben trennen

Nach dem Übergang kann Cursor Implementierung und Reviews übernehmen, während die bestehenden Plattformen den Betrieb absichern. Behalte Lovable, wenn dir der visuelle Builder Zeit spart und du sichergestellt hast, wie Änderungen synchronisiert werden.

Kündige überflüssige Abos erst dann, wenn du geprüft hast, ob Hosting, Backend-Dienste oder Deployments an diesem Account hängen. Halte wichtige Betriebsanleitungen immer außerhalb von Chat-Verläufen fest.

Arbeite bei künftigen Aufgaben nach demselben Prinzip kleiner, kontrollierter Schritte, wie wir es in unseren Playbooks für Gründer und Entwickler beschreiben. Wer eine Codebasis besitzt, muss sie erklären, testen und wiederherstellen können. Sie einfach nur in einem anderen Editor zu öffnen, reicht dafür nicht.

Kann Cursor eine mit Lovable erstellte App bearbeiten?

Ja, sofern du Zugriff auf den Quellcode hast. Cursor kann das Repository bearbeiten, übernimmt aber weder gehostete Dienste noch Secrets, Deployment-Settings oder Datenbestände automatisch. Diese Abhängigkeiten musst du separat prüfen.

Muss die Lovable-Datenbank umziehen?

Für einen reinen Editor-Wechsel normalerweise nicht. Lass die Datenbank dort, wo sie ist, solange sie erreichbar bleibt und ihren Zweck erfüllt. Ein Umzug von Kundendaten ist ein eigenes Projekt samt Backups, Migrationschecks, Rechteprüfungen und eigenem Rollback-Plan.

Kann man Lovable nach dem Wechsel zu Cursor kündigen?

Möglicherweise. Den Code in Cursor zu öffnen, reicht als Entscheidungsgrundlage allerdings nicht. Kläre vorher, ob Hosting, Backend, Veröffentlichung und Berechtigungen auch ohne aktives Abonnement weiterlaufen. Prüfe vor der Kündigung die aktuellen Konditionen des Anbieters.