Migrations-Checkliste

Nutzen Sie diese Liste in einer Planungssitzung mit den Personen, die Ihre aktuelle Website gebaut haben. Ein “Nein” ist für sich genommen kein Hindernis. Es zeigt Ihnen, wo die Arbeit liegt.

1. Technik

• Die Site nutzt Next.js App Router, oder das Team akzeptiert zusätzlichen Aufwand für ein anderes Server-Framework. (Warum)
• Inhalte können in Servercode abgerufen werden, und das Delivery-Token kann in einer Server-Umgebungsvariable liegen.
• Die Site kann für jede umgezogene Seite einen integrierten Fallback behalten, damit sie auch funktioniert, wenn Atlas nicht erreichbar ist.
• Das Team kann eine Route für die Vorschau, eine für Webhooks und einen Build-Bericht beim Start hinzufügen.

2. Design und Komponenten

• Seiten bestehen aus wiederverwendbaren Abschnitten (Hero, Karten, FAQ, Call-to-Action). Einmalige Seiten können trotzdem eine einzelne Komponente mit Feldern sein.
• Sie haben jeden Seitentyp aufgelistet: Startseite, Produkt, Artikel, Landingpage, Rechtliches und so weiter.
• Für jeden Abschnitt wissen Sie, welche Teile Redakteure ändern (Text, Bilder, Links, Listen) und welche im Code fest bleiben.
• Interaktive Teile (Rechner, Konfiguratoren, Karten, Animationen) bleiben in Ihrem Code. Redakteure füllen nur deren Texte und Einstellungen.

3. Inhalte in Ihrem aktuellen CMS

• Sie können Seiten, Einträge und Bilder exportieren: per Datenbank-Dump, API, CSV oder einen KI-Agenten, der die alte Site liest.
• Wiederkehrende Inhalte (Produkte, News, Team, Standorte) lassen sich Collections zuordnen.
• Sie haben benutzerdefinierte Felder aufgelistet und kennen ihre Typen: Text, Rich Text, Zahl, Datum, Link, Bild, Referenz, Liste.
• Sie wissen, wo das aktuelle CMS Code in Inhalten ausführt: Shortcodes, Embeds, HTML-Blöcke, Skripte. Jedes davon braucht eine Ersatzkomponente. Siehe Ihr aktuelles CMS im Vergleich.
• Sie haben eine Liste der URLs und Weiterleitungen, die bleiben sollen, damit Suchmaschinen-Rankings nicht verloren gehen.
• Sprachen und ihre Fallback-Regeln sind klar. Rechts-nach-links-Sprachen brauchen dir="rtl"-Unterstützung in Ihren Komponenten.

4. Funktionen, von denen Ihre Site abhängt

Prüfen Sie jede einzelne gegen den Funktionsstatus, bevor Sie sich festlegen:

• Formulare und Lead-E-Mails: Development und die Live-Website (in der Abschlussprüfung vor dem Release).
• Chatbot: Development und die Live-Website (in der Abschlussprüfung vor dem Release).
• Leads an ein CRM oder ein anderes System senden: CRM-Push und die Leads API decken heute nur Development-Leads ab; Leads der Live-Website erreichen Sie über Webhooks.
• Analytics: Atlas zählt Seitenaufrufe pro Route, ohne Cookies, in Development und auf der Live-Website. Behalten Sie Ihre bestehende Analytics-Lösung.
• Suche auf Ihrer Site: Atlas bietet keine Site-Suche. Behalten Sie Ihre eigene oder bauen Sie sie aus der Einträge-API.
• E-Commerce, Checkout, Mitglieder-Logins: nicht Teil von Atlas. Diese bleiben in Ihrem Code oder Ihren bestehenden Diensten.
• Zeitgesteuerte Veröffentlichung, Übersetzungen, Weiterleitungen, SEO-Felder: unterstützt.

5. Personen und Freigaben

• Sie wissen, wer bearbeitet, wer prüft und wer Production-Releases freigibt.
• Alle, die sich anmelden, können die Atlas-Anmeldung nutzen. Single Sign-on mit Ihrem eigenen Identitätsanbieter ist nicht verfügbar.
• Rechts- und Sicherheitsprüfer haben Sicherheit und die offenen Punkte in den FAQ gelesen.

Ergebnis

• Überwiegend ja: Folgen Sie der schrittweisen Migration.
• Mehrere Nein in den Abschnitten 1 bis 3: Beginnen Sie mit einem Pilot für einen Seitentyp.
• Ihre Site hängt von Punkten in Abschnitt 4 ab, die nicht verfügbar sind: Warten Sie oder lassen Sie diese Teile vorerst außerhalb von Atlas.