App neu aufbauen ohne die Datenbank zu ändern: ein Cutover-Plan, der funktioniert

Was kann schiefgehen, wenn Sie neu aufbauen, aber die gleiche Datenbank behalten

Die aktuelle Datenbank zu behalten fühlt sich oft sicherer an als eine vollständige Migration. Trotzdem kann ein Neuaufbau auf Arten fehlschlagen, die für Nutzer wie „fehlende Daten" aussehen. Die meisten Probleme entstehen durch kleine Abweichungen zwischen dem, was die alte App annahm, und dem, was die neue App tatsächlich tut.

Die schmerzhaftesten Fehler zeigen sich als verlorene Accounts oder „leere" Historien. Die Zeilen sind vielleicht noch da, aber die neue App liest sie anders. Häufige Ursachen sind geänderte Passwort-Hashes, andere E-Mail-Normalisierung (Groß-/Kleinschreibung, Trimmen), neue Nutzer-ID-Formate oder ein neuer Auth-Provider, der sich nicht sauber auf vorhandene Identitäten abbilden lässt.

Ein Neuaufbau ohne Datenbankwechsel birgt auch das Risiko subtiler Korruption während des Cutovers. Wenn alte und neue App gleichzeitig schreiben, kann die Realität gespalten werden: doppelte Datensätze, überschriebenen Updates oder Ereignisse, die nur in einem System aufgezeichnet werden.

Ein Cutover-Plan muss vor allem ein paar Dinge schützen: Logins und Identitätsabbildung, Reihenfolge der Schreibvorgänge (keine doppelten Writes und keine verlorenen Updates), Prüfpfade und Historie (Timestamps, Statusänderungen, Rechnungen, Nachrichten) sowie Hintergrundjobs (E-Mails, Webhooks, Abrechnungsläufe), die alte Daten erneut verarbeiten könnten.

Manchmal ist das Beibehalten der Datenbank die falsche Entscheidung. Wenn das Schema unsicher ist (offenliegende Secrets, Spuren von SQL-Injection, fehlende Constraints) oder das Datenmodell so inkonsistent ist, dass jede Ansicht Sonderlogik braucht, verbringen Sie möglicherweise mehr Zeit mit Flickwerken als mit einem echten Neuaufbau.

Ein einfaches Beispiel: Ihr Neuaufbau ändert die Regeln für „Organisation-Mitgliedschaft“. Alte Daten erlauben mehrere Rollen pro Benutzer, die neue App erwartet jedoch genau eine. Nutzer verlieren plötzlich den Zugriff, weil der neue Code die falsche Rolle auswählt. Solche Probleme früh zu finden ist Zweck von Kompatibilitätsprüfungen.

Ziele festlegen und einen Cutover-Ansatz wählen

Schreiben Sie zuerst auf, welche Versprechen Sie unter keinen Umständen brechen wollen. Das verhindert, dass der Neuaufbau zu einem riskanten Rewrite wird, bei dem Leute Zugriff, Historie oder Vertrauen verlieren.

Die meisten Teams kommen auf Versprechen wie: bestehende Konten funktionieren weiter, historische Daten bleiben intakt und die Ausfallzeit ist entweder nahezu null oder geplant und kurz. Wenn ein Versprechen flexibel sein kann (z. B. ein 10-minütiges Wartungsfenster ist in Ordnung), entscheiden Sie das jetzt — nicht in der Launch-Nacht.

Formulieren Sie „Erfolg" als klare Prüfungen, denen das ganze Team zustimmt. Zum Beispiel: Nutzer können sich einloggen und sehen dieselben Rollen und Berechtigungen; wichtige Seiten zeigen dieselben Summen (Bestellungen, Rechnungen, Nachrichten); neue Aktionen erzeugen genau einen DB-Write; kritische Jobs laufen weiter; und der Support hat ein klares Skript für die wahrscheinlichsten Probleme.

Zwei gängige Cutover-Stile

Ein geplanter Schalter (Big-Bang) leitet zu einem geplanten Zeitpunkt den gesamten Traffic auf die neue App. Er ist leichter zu verstehen, aber die Risiken sind höher, falls etwas schiefgeht.

Ein schrittweiser Übergang verschiebt den Traffic in Etappen (prozentual, nach Nutzergruppen oder nach Feature). Er dauert länger, reduziert aber das Risiko, weil Sie anhand realer Nutzung lernen können, bevor Sie komplett umschalten.

Definieren Sie das Rollback so, dass Sie es schnell und ohne Rätsel entscheiden und ausführen können. Seien Sie explizit, was Nutzer erleben werden (z. B. nur-Lesen-Periode vs. vollständige Rückkehr zur alten App) und was mit während des Versuchs erstellten Daten passiert.

Kartieren Sie die aktuellen Daten und die daran gebundenen Nutzerreisen

Verschaffen Sie sich ein klares Bild davon, was tatsächlich in Produktion ist — nicht nur das, was das ERD sagt. Neuaufbauten brechen oft, weil eine „kleine" Tabelle oder ein Hintergrundjob heimlich viel Arbeit geleistet hat.

Beginnen Sie mit einem Inventar der Daten hinter Ihren meistgenutzten Flows. Konzentrieren Sie sich auf Tabellen, die entscheiden, wer ein Nutzer ist, was er darf und wofür Sie bezahlt werden. In der Praxis sind das meist Identitäts- und Zugriffstabellen, Abrechnungs-/Abo-Tabellen, Ihre Kern-Domänen-Records und die Logs/Integrationstabellen, die erklären, was passiert ist (und warum).

Als Nächstes kartieren Sie Beziehungen, die nicht brechen dürfen. Suchen Sie nach Foreign Keys (oder „weichen" Links, die nur im Code durchgesetzt werden), Unique-Constraints und „müssen existieren"-Records (wie eine Default-Org oder eine Owner-Rolle). Notieren Sie, was nach dem Cutover wahr bleiben muss, z. B.: jedes Abo bildet genau ein aktives Konto ab.

Dokumentieren Sie schließlich, wo Daten erstellt oder geändert werden. Halten Sie es einfach: UI-Formulare, Admin-Tools, Hintergrundjobs, Importe und Webhooks. Erfassen Sie die Eigenheiten, auf die die Produktion angewiesen ist, auch wenn sie unordentlich sind.

Beispiel: Wenn Ihre aktuelle App org_id auf zwei verschiedene Arten schreibt (Web-Signup vs. sales-assisted Onboarding), muss die neue App beide Fälle verarbeiten.

Authentifizierung und Nutzeridentität kompatibel machen

Authentifizierung ist meist das erste, was in Produktion kaputtgeht. Kleine Abweichungen bei Nutzer-IDs, Organisationszugehörigkeit oder Rollen können Menschen aussperren oder — schlimmer — in das falsche Konto einloggen.

Bestätigen Sie, was Ihr System als „die" Identität behandelt. Ist es eine numerische user_id, eine UUID, eine E-Mail oder eine externe Provider-ID (Google, GitHub)? Wählen Sie den stabilen Schlüssel und verwenden Sie ihn überall gleich: Organisationszugehörigkeit, Berechtigungen, Billing-Eigentum und Audit-Logs.

Führen Sie eine Kompatibilitätsprüfung durch, die die meisten Probleme aufdeckt:

• Dieselbe User-ID bildet in beiden Apps dieselbe E-Mail und Org ab.
• Org- und Rollen-Tabellen bedeuten dasselbe (nicht nur dieselben Namen).
• Einzigartigkeitsregeln passen zur Realität (besonders E-Mail-Einzigartigkeit).
• Gelöschte oder deaktivierte Nutzer verhalten sich gleich.
• Audit-Felder wie created_at und last_login bleiben erhalten.

Passworthandling braucht besondere Sorgfalt. Rehashen Sie Passwörter nicht, außer es ist wirklich nötig. Wenn die alte App bcrypt verwendet und die neue App argon2 erwartet, verifizieren Sie weiterhin mit dem alten Hash und migrieren Sie beim nächsten Login (speichern Sie den neuen Hash nach erfolgreichem Login). So vermeiden Sie erzwungene Passwort-Resets, Support-Tickets und User-Churn.

Sessions und Tokens sind die nächste Falle. Bei gestaffeltem Rollout können alte Sessions noch existieren. Entscheiden Sie, ob Sie sie akzeptieren, ablaufen lassen oder beide Token-Validatoren für eine kurze Zeit laufen lassen. Wenn Sie Signatur-Schlüssel rotieren, planen Sie das wie ein Release — nicht als Überraschung.

Randfälle tauchen immer auf: doppelte E-Mails aus Legacy-Importen, Nutzer in mehreren Orgs und alte Rollennamen wie "owner" vs. "admin". Beheben Sie diese mit einer Mapping-Schicht, nicht mit ad-hoc Datenbank-Edits.

Schema- und API-Änderungen rückwärtskompatibel gestalten

Rückwärtskompatibilität sorgt dafür, dass der Cutover ruhig bleibt. Stimmen Sie zuerst ab, was nicht geändert werden darf, weil die alte App noch davon abhängt.

Behandeln Sie die Datenbank wie einen Vertrag: Tabellennamen, Schlüsselspalten, Primärschlüssel und die Bedeutung bestehender Werte. Wenn der alte Code z. B. users.id als UUID und users.email als einzigartig erwartet, halten Sie das während der Übergangsphase stabil.

Trennen Sie dann sichere Änderungen von riskanten.

Add-only-Änderungen sind meist unproblematisch: neue nullable Spalten, neue Tabellen und neue Indexe.

Breaking Changes (Spalten umbenennen, Datentypen ändern, Constraints verschärfen) sollten warten, bis die neue App den gesamten Traffic bedient.

Ein praktisches Muster: erst erweitern, dann umschalten, dann zusammenziehen. Beispiel: Fügen Sie users.timezone als nullable hinzu, deployen Sie die neue App, die es schreibt, backfillen Sie alte Zeilen und überlegen Sie erst danach, es NOT NULL zu machen.

Praktische Kompatibilitäts-Checkliste

Bevor Sie eine Migration ausrollen, stellen Sie sicher:

• Neue Spalten beginnen als nullable oder mit Default.
• Neue Enums akzeptieren alte Werte (oder Sie mappen sie sicher).
• Constraints werden schrittweise verschärft (zuerst validieren, später erzwingen).
• Alte APIs funktionieren weiter, auch wenn die neue App Felder hinzufügt.
• Sie haben einen Plan, vorhandene Zeilen zu backfillen und zu verifizieren.

Alte Zeilen sind die Falle. Wenn neue Validierungsregeln Legacy-Daten ablehnen (fehlende Telefonnummern, ungültige States, leere Namen), beheben Sie das nicht, indem Sie Logins blockieren. Verwenden Sie tolerant lesende Abfragen, Migrationsskripte und gezielte Aufforderungen (fragen Sie Nutzer beim nächsten Login, fehlende Felder zu ergänzen).

Schritt-für-Schritt gestaffelter Rollout-Plan (nur-Lesen bis voller Traffic)

Behandeln Sie den Cutover als Reihe kleiner Wetten. Jede Phase sollte umkehrbar sein und einen klaren Test haben, der beweist, dass die neue App sich wie die alte verhält.

Stufen (vom sichersten zum riskantesten)

Starten Sie, indem Sie die neue App an Produktionsdaten anschließen, aber einschränken, was sie tun darf:

• Betreiben Sie die neue App im Nur-Lesen-Modus. Nutzer können browsen, suchen und Historie sehen, aber Schreibaktionen sind blockiert.
• Fügen Sie Shadow-Traffic für einige Schlüssend Endpunkte hinzu. Die alte App liefert Antworten, während die neue App dieselben Requests im Hintergrund ausführt und Sie die Outputs vergleichen.
• Aktivieren Sie eine kleine Menge von Schreibaktionen für eine winzige Gruppe per Feature-Flags (zuerst interne Nutzer, dann ein kleiner Prozentsatz).
• Steigern Sie den Traffic schrittweise (10 %, 25 %, 50 %, dann 100 %), mit Monitoring-Gates bei jedem Schritt.

Pausieren Sie zwischen den Schritten und werten Sie das Gelernte aus. Wenn etwas auffällig ist, stoppen Sie das Rollout und beheben das Problem, bevor Sie das Risiko erhöhen.

Kriterien zum Weitermachen

Schreiben Sie „Go/No-Go"-Checks im Voraus, damit Entscheidungen nicht unter Druck getroffen werden:

• Fehlerquote und Latenz bleiben im engen Vergleich zur alten App.
• Shadow-Antworten stimmen in Schlüssel-Feldern überein (Berechtigungen, Summen, Preise, Status).
• Keine unerwarteten Writes im Nur-Lesen-Modus (bestätigen Sie mit DB-Logs).
• Support-Tickets und Nutzerbeschwerden steigen nicht nach jedem Ramp.
• Ein Rollback-Runbook ist getestet und kann die alte App in Minuten wiederherstellen.

Schreibvorgänge während der Transition planen (Daten-Gabeln vermeiden)

Der schnellste Weg, einen Cutover zu ruinieren, ist, beide App-Versionen dieselben Records auf unterschiedliche Weise schreiben zu lassen. Sie brauchen eine klare Regel: Wer darf in welcher Rollout-Phase was schreiben.

Wählen Sie eine einzige Quelle der Wahrheit für Writes. Häufig schreibt zunächst die alte App weiter, während die neue App nur liest. Dann schalten Sie um: die neue App wird Writer und die alte App wird read-only oder hat Schreibendpunkte blockiert. Das verhindert stummes „Split-Brain".

Duale Writes klingen sicher, erzeugen aber oft Forks, die Sie erst Tage später bemerken — z. B. unterschiedliche Abo-Status oder doppelte Rechnungen. Führen Sie duale Writes nur durch, wenn Sie beweisen können, dass sie sicher sind.

Wenn duale Writes kurzfristig nötig sind, machen Sie Konflikte vorhersehbar:

• Machen Sie jeden Write idempotent mit einer stabilen Request-ID.
• Definieren Sie Konfliktregeln vorab (Last-Write-Wins für Profilfelder, aber niemals für Zahlungen).
• Fügen Sie eine kleine Write-Log-Tabelle hinzu (Request ID, User ID, Timestamp, betroffene Hauptentität).
• Lehnen Sie unbekannte Felder oder „best-guess"-Mappings ab.
• Setzen Sie strenge Feature-Flags für neue Write-Pfade, damit Sie sie schnell abschalten können.

Ein praktischer Ansatz: Beim Migrieren von Sign-ups lässt die neue App Accounts anlegen, routet Passwort-Resets und Billing-Änderungen aber über die alte App, bis alle Schreibpfade verifiziert sind.

Monitoring und Datenvalidierung während des Cutovers

Cutover ist mehr als ein Deploy. Es ist ein Live-Experiment, besonders während Sie Traffic stufenweise verschieben.

Starten Sie mit einer engen Menge an Signalen, die zeigen, ob Nutzer sich noch anmelden, browsen und Änderungen speichern können:

• Login-Erfolgsrate und Passwort-Reset-Erfolg
• Fehlerquote pro Endpoint (5xx, Timeouts, Auth-Fehler)
• Schreibfehler und Retries (Creates, Updates, Zahlungen, Einladungen)
• Latenz bei p95/p99
• Queue- und Hintergrundjob-Gesundheit (E-Mails, Webhooks, Billing-Sync)

Zahlen allein reichen nicht. Validieren Sie die Daten selbst bei jedem Traffic-Schritt (5 % dann 25 % dann 100 %): vergleichen Sie Zeilenanzahlen und Summen für die betroffenen Entities, prüfen Sie Konsistenz jüngster Aktivitäten (Foreign Keys, Timestamps, Status) und spot-checken Sie die letzten Writes auf offensichtliche Anomalien.

Beziehen Sie Nutzersignale mit ein. Ein Anstieg an Support-Tickets, ein plötzlicher Abbruch nach dem Login oder wiederholte „etwas ist schiefgegangen"-Screenshots zeigen oft Probleme, bevor Dashboards Alarm schlagen.

Setzen Sie Entscheidungsgrenzen, bevor Sie starten. Beispiel: wenn der Login-Erfolg für 10 Minuten um 2 % fällt oder Schreibfehler 0,5 % überschreiten, pausieren Sie das Rollout und untersuchen. Wenn die Ursache nicht schnell klar ist, rollen Sie zurück.

Rollback-Plan, den Sie in Minuten ausführen können

Rollback ist kein Scheitern. Es ist das Sicherheitsventil, mit dem Sie Nutzerkonten und Historie schützen.

Klare Rollback-Trigger festlegen

Wählen Sie eine kleine Menge Alarme, die Aktion erzwingen, nicht Diskussionen:

• Login- oder Signup-Fehler über einem Schwellenwert (z. B. 2 % für 5 Minuten)
• Verdächtige Writes (fehlende Pflichtfelder, unerwartete Nulls, duplizierte Records)
• Große Leistungsverschlechterung (Timeouts, DB-CPU ausgelastet, Backlog in Queues)
• Sicherheitswarnungen (Auth-Bypass, fehlende Permission-Checks)

Wenn ein Trigger feuert, sollte eine Person die Autorität haben, ihn auszulösen. Alle anderen führen aus.

Die „Minuten, nicht Stunden"-Rollback-Schritte

Schreiben Sie das als Notfall-Checklist und proben Sie es einmal:

• Schalten Sie den Traffic zurück auf die alte App (Load Balancer, Feature Flag oder Deployment-Toggle).
• Frieren Sie neue Writes in der neuen App ein (klare Wartungsmeldung zurückgeben).
• Bewahren Sie Beweise: Request-Logs, Error-Traces und ein Snapshot betroffener Tabellen.
• Leeren oder pausieren Sie Hintergrundjobs, damit sie nicht weiter fehlerhafte Daten schreiben.
• Verifizieren: eine Person prüft Logins und Kern-Workflows, eine andere prüft die Datenintegrität.

Für Teil-Writes behalten Sie eine einfache Recovery-Regel. Entweder taggen Sie neue Writes nach Quelle (old vs. new), damit Sie sie isolieren können, oder Sie queueen Writes und spielen sie erst nach Validierung nach.

Häufige Fehler und Fallstricke (und wie man sie vermeidet)

Die meisten Cutovers scheitern aus banalen Gründen: eine kleine Abweichung, die erst mit echten Nutzern und echter Historie sichtbar wird. Behandeln Sie Kompatibilität als Produkt-Feature, nicht als Last-Minute-Aufgabe.

Ein klassischer Fehler ist das Brechen der Nutzeridentität. Wenn Sie Primärschlüssel ändern, Nutzer umnummern oder UUID-Formate mittendrin tauschen, können Konten heimlich von Abos, Berechtigungen und Audit-Trails getrennt werden. Behalten Sie dieselben User-IDs durchgängig bei oder fügen Sie eine stabile Mapping-Schicht hinzu und testen Sie sie auf einem vollständigen Produktions-Snapshot.

Passwörter sind eine weitere Falle. Teams „migrieren" Auth und setzen versehentlich alle zurück, weil der neue Service die alte Hash-Methode nicht verifizieren kann (oder per-user Salt/Pepper vergisst). Lassen Sie die alte Verifikation weiterlaufen, re-hashen Sie beim erfolgreichen Login und loggen oder offenbaren Sie niemals Secrets beim Debugging.

Produktionsdaten werden Sie überraschen. Testdaten enthalten selten gelöschte Nutzer, doppelte E-Mails aus alten Importen, Zeitzonen-Sonderfälle, partielle Records oder Legacy-Flags, die das UI vor Jahren versteckt hat. Planen Sie Tests rund um Randfälle, nicht um Happy Paths.

Fünf Prüfungen verhindern die meisten Vorfälle:

• Sperren Sie User-ID-Format und Primärschlüssel für die Dauer des Cutovers.
• Bestätigen Sie Passwort-Hashing- und Session/Token-Regeln entsprechen dem alten Verhalten.
• Proben Sie mit einem produktionsähnlichen Snapshot und echten Migrationsskripten.
• Inventarisieren Sie Hintergrundschreiber (Jobs, Webhooks, Cron) und regeln Sie sie während des Rollouts.
• Verzögern Sie brechende Schema-Änderungen, bis die neue App 100 % des Reads und Writes bedient.

Kurz-Checkliste vor, während und nach dem Cutover

Behandeln Sie den Cutover wie eine Generalprobe, nicht wie einen einzigen Schalter.

Vor dem Cutover (proben, als wäre es echt)

Stellen Sie Backups durch Wiederherstellung in einer Testumgebung sicher und öffnen Sie die App gegen die wiederhergestellte Kopie. Üben Sie Migrationen End-to-End (apply, verify, rollback) mit produktionsähnlichem Volumen. Bestätigen Sie, dass Monitoring und Alerts Errors, Latenz und DB-Locks/langsame Queries abdecken. Führen Sie Auth-Flows durch (Login, Signup, Passwort-Reset, Session-Refresh, rollenbasierter Zugriff) für einige reale Rollen. Sample key tables (users, subscriptions/orders, audit/history) und prüfen Sie auf unerwartete Nulls, fehlende Indexe und inkonsistente jüngste Records.

Machen Sie einen zeitlich begrenzten Dry Run mit einer kleinen internen Gruppe. Wenn etwas unklar ist, machen Sie daraus einen Runbook-Schritt.

Während und nach dem Cutover (vertrauen, aber verifizieren)

Starten Sie mit einem winzigen Prozentsatz und steigern in Schritten. Bestätigen Sie, dass der Rollback-Schalter ohne Code-Deploy funktioniert (vor dem Launch proben). Validieren Sie Writes für die wichtigsten Flows (Profile, Zahlungen, Berechtigungen). Prüfen Sie, dass Hintergrundarbeit (Queues, Cron-Jobs, E-Mails, Webhooks) einmalig läuft, nicht doppelt. Machen Sie den Support bereit mit einer kurzen Status-Nachricht, einer Known-Issues-Liste und einem schnellen Weg, betroffene Nutzer zu finden.

Beispiel-Szenario: Eine SaaS-App neu bauen und trotzdem alle Historien behalten

Ein kleines SaaS-Team entscheidet, die Web-App neu zu bauen, weil die aktuelle langsam und instabil ist. Sie dürfen jedoch nichts in der DB verlieren: Benutzerkonten, Projekte, Rechnungen und Abo-Status müssen erhalten bleiben. Ziel: die App neu bauen ohne die Datenbank zu ändern und dann den Traffic sicher umschalten.

Zuerst bringen sie die neue App im Nur-Lesen-Modus live. Nutzer bearbeiten weiterhin in der alten App, aber die neue App kann einloggen, Projekte laden, vergangene Rechnungen zeigen und den aktuellen Plan anzeigen. Intern vergleicht das Team Zählungen und Summen (Projekte pro Nutzer, letzte Rechnungsbeträge, nächstes Verlängerungsdatum) zwischen alten und neuen Screens. Kunden bemerken nichts, aber das Team findet schnell, wo Annahmen auseinanderlaufen.

Als Nächstes rollen sie zu einer kleinen Kohorte aus: 5 % der Nutzer mit geringem Support-Risiko und gemischten Plänen. Sie beobachten Login-Erfolg, Projekt-Ladezeiten, Übereinstimmung der Rechnungsbeträge mit der alten App und neue Support-Tickets, die von fehlenden Daten berichten.

Am zweiten Tag entdecken sie eine Abrechnungsabweichung bei Jahresplänen. Die neue App zeigt „bezahlt" korrekt an, schreibt jedoch ein falsches next_billing_date, wenn ein Nutzer das Firmenprofil ändert. Das ist ein Rollback-Moment. Sie schalten den Traffic zurück auf die alte App, deaktivieren Writes in der neuen App und spielen die betroffenen Updates mit einem Script anhand der Audit-Logs nach. Niemand verliert Historie, und der Fix wird erneut im Nur-Lesen-Modus getestet, bevor die Kohorte wieder freigeschaltet wird.

Nächste Schritte und wann FixMyMess helfen kann

Behandeln Sie den Cutover-Plan als eigenes Projekt. Beginnen Sie damit, aufzuschreiben, was nicht kaputtgehen darf: Anmeldung, Abrechnung, wichtige Reports und Integrationen, die in die DB schreiben.

Bringen Sie früh Hilfe an Bord, wenn Sie Muster sehen wie intermittierende Login-/Session-Probleme über Umgebungen hinweg, ein Schema, das „organisch gewachsen" ist mit unklarer Zuständigkeit, oder Sicherheitslücken wie offenliegende Secrets und verdächtige SQL-Queries.

Wenn Sie ein KI-erzeugtes Prototyp geerbt haben, das jetzt unter echter Produktionslast versagt, konzentriert sich FixMyMess (fixmymess.ai) darauf, diese Lücken zu diagnostizieren und zu reparieren — besonders Auth-Probleme, unsichere Schema-Muster und brüchige Logik — sodass Ihr gestaffeltes Rollout- und Rollback-Plan dem tatsächlichen Code entspricht. Ein üblicher Einstieg ist ein kostenloses Code-Audit, das die echten Fehlerpunkte aufzeigt, bevor Sie Traffic umschalten.