Die gemeinsame Migrations-Checkliste #

Jede Migration auf diesen Seiten durchläuft dieselben Phasen. Die Anleitungen zu den einzelnen Wegen ergänzen, was für eine bestimmte Quelle oder ein bestimmtes Ziel gilt; diese Seite ist der Rahmen, in den sie alle passen. Übertragen Sie die Checklisten in das Aufgabensystem Ihres Projekts und haken Sie sie ab.

Übersicht Migration · Werkzeuge: Die Import- und Export-Werkzeuge von Exponential · Abbildung: Inhalte auf Exponential abbilden

Inhalt #

• 1. Bestandsaufnahme: wissen, was Sie haben
• 2. Umfang und Verantwortliche für jeden Teil festlegen
• 3. Das Inhaltsmodell abbilden
• 4. URLs und Weiterleitungen
• 5. Metadaten für Suchmaschinen
• 6. Den Import bauen und proben
• 7. Testen
• 8. Umstellung
• 9. Rückweg
• 10. Nach dem Go-live
• 11. Wiederkehrende Risiken

1. Bestandsaufnahme: wissen, was Sie haben #

• To do: Jede Adresse der alten Site. Crawlen Sie sie (eine Sitemap allein übersieht verwaiste Seiten), exportieren Sie das Zugriffsprotokoll des Servers der letzten Monate und listen Sie die Adressen auf, auf die Suchmaschinen und andere Sites verlinken. Diese Liste bestimmt die Weiterleitungen in 4.
• To do: Jeder Inhaltstyp und wie viele Elemente es davon gibt, in jeder Sprache.
• To do: Medien: Bilder, Dokumente, Videos; wo sie gespeichert sind; Gesamtgröße; welche noch referenziert werden.
• To do: Benutzer und Gruppen: wie viele, welche davon Redakteure, welche Mitglieder der Site sind; ob Passwörter übernommen werden können (meist nicht, siehe 3).
• To do: Formulare, Kommentare, Bewertungen, Shop-Bestellungen, Newsletter: Daten, die keine „Inhalte“ sind, aber irgendwohin müssen oder archiviert werden.
• To do: Integrationen: Single Sign-on, Suche, Webanalyse, Zahlung, E-Mail, Feeds, APIs, die andere Systeme aufrufen.
• To do: Eigener Code: Plugins, Module, Extensions, Templates, geplante Jobs.
• To do: Recht und Aufbewahrung: was aufbewahrt werden muss, was nicht übernommen werden darf (personenbezogene Daten, die Sie nicht mehr brauchen, bleiben am besten zurück), wer die Abnahme erteilt.

2. Umfang und Verantwortliche für jeden Teil festlegen #

3. Das Inhaltsmodell abbilden #

Schreiben Sie die Abbildung als Tabelle pro Inhaltstyp auf, bevor Sie Importcode schreiben. Die wichtigen Spalten:

• To do: Eine Klasse pro Typ der Quelle oder weniger Klassen mit einer Typauswahl: pro Typ entscheiden.
• To do: Jedes Feld einem Attribut zugeordnet oder bewusst verworfen.
• To do: Formatierter Text: entscheiden, wie HTML zu XmlText wird (oder auf der Symfony-Plattform zu RichText) und was mit Inline-Styles, Skripten und Iframes geschieht (verworfen oder in benutzerdefinierte Tags oder Einbettungen umgewandelt).
• To do: Taxonomie: Orte (ein Baum), Schlüsselwörter (ezkeyword), Tags (eztags) oder Beziehungen.
• To do: Medien: ein eigenes Bild-/Dateiobjekt pro Asset, verknüpft oder eingebettet, damit es wiederverwendet werden kann.
• To do: Sprachen: ein Objekt mit Übersetzungen, nicht ein Objekt pro Sprache.
• To do: Benutzer: Die Passwort-Hash-Typen der Quelle kann das Ziel selten lesen. Planen Sie ein Zurücksetzen ein (eine E-Mail mit einem Link), sofern die Anleitung Ihres Weges nicht sagt, dass die Hashes übernommen werden.
• To do: Jedes Objekt erhält eine Remote-ID, die seine Quelle benennt (wp-post-1234), damit ein erneuter Import aktualisiert statt zu duplizieren und damit sich Weiterleitungen daraus erzeugen lassen.

Die Details zu jedem Konzept stehen unter Inhalte auf Exponential abbilden.

4. URLs und Weiterleitungen #

• To do: Entscheiden Sie für jede alte Adresse: dieselbe Adresse auf der neuen Site, eine 301-Weiterleitung auf ihre neue Adresse oder bewusst ein 410/404 (entfernt).
• To do: Erzeugen Sie die Weiterleitungstabelle aus dem Import: Remote-ID zu neuem Knoten, alte Adresse zu neuer Adresse.
• To do: In Exponential bewahren Sie eine alte Adresse auf eine von drei Arten (alle beschrieben unter URLs und Aliase):
  • Der eigene URL-Alias des Knotens: wenn der alte Pfad der neue Pfad sein kann (about-us/team). Setzen Sie den Namen des Objekts oder einen eigenen Alias so, dass der Alias passt.
  • Ein eigener URL-Alias am Knoten, der (mit 301) auf die Hauptadresse des Knotens weiterleitet: einer pro abweichender alter Adresse.
  • Ein URL-Platzhalter (news/* zu articles/{1}) für ganze Gruppen, die sich nach einem festen Muster geändert haben.
• To do: Adressen mit Query-Strings (?p=123, index.php?id=5) oder mit Dateiendungen, die das Alias-System bereinigt: Behandeln Sie diese im Webserver oder in einem kleinen Weiterleitungsmodul vor Exponential, aus derselben Tabelle.
• To do: Testen Sie jede Weiterleitung automatisch (Status und Ziel), nicht nur stichprobenartig.
• To do: Behalten Sie Weiterleitungen mindestens ein Jahr bei; so lange brauchen Suchmaschinen und alte Links sie.

5. Metadaten für Suchmaschinen #

• To do: Titel und Meta-Beschreibungen: auf Attribute abbilden. xrowmetadata (in composer.json vorausgesetzt) fügt einen Metadaten-Datentyp mit Titel, Schlüsselwörtern und Beschreibung hinzu sowie einen Cronjob für XML-Sitemaps.
• To do: Kanonische Adressen, hreflang für Übersetzungen, robots-Regeln: im Pagelayout nachbilden.
• To do: Eine XML-Sitemap auf der neuen Site (xrowmetadata oder bcgooglesitemaps), nach dem Go-live eingereicht.
• To do: Strukturierte Daten (JSON-LD), die die alte Site hatte: auflisten und in Templates neu aufbauen.
• To do: Analyse- und Verifizierungs-Tags.

6. Den Import bauen und proben #

• To do: Nutzen Sie zuerst die vorhandenen Werkzeuge (Die Import- und Export-Werkzeuge von Exponential); schreiben Sie ein Skript nur für das, was diese nicht können.
• To do: Machen Sie den Import wiederholbar: Er liest einen eingefrorenen Export, gleicht über die Remote-ID ab und aktualisiert, was bereits vorhanden ist.
• To do: Protokollieren Sie jedes Element: angelegt, aktualisiert, übersprungen (und warum).
• To do: Proben Sie mindestens zweimal an einer Kopie des Ziels. Messen Sie die Dauer jedes Laufs; daraus ergibt sich das Zeitfenster für die echte Umstellung.
• To do: Zählen Sie nach jedem Lauf: Elemente pro Typ und Sprache, Mediendateien, Benutzer, Weiterleitungen. Vergleichen Sie mit der Bestandsaufnahme.

7. Testen #

8. Umstellung #

• To do: Kündigen Sie der Redaktion das Einfrieren an; stoppen Sie Änderungen an der alten Site.
• To do: Letzter Export, letzter Import, Zählung, Test der Weiterleitungen.
• To do: Senken Sie die DNS-TTL einen Tag vorher; schalten Sie DNS oder den Proxy um.
• To do: Leeren Sie die Caches und wärmen Sie die meistbesuchten Seiten vor (./console exp:warm, ./console exp:preload --apply).
• To do: Beobachten Sie in den ersten Stunden die Protokolle (./console exp:explogs) und die 404-Liste; ergänzen Sie Weiterleitungen für das, was dort auftaucht.
• To do: Reichen Sie die Sitemap ein; prüfen Sie die Search Console jeder Suchmaschine auf Crawling-Fehler.

9. Rückweg #

• To do: Lassen Sie die alte Site bis zur Abnahme schreibgeschützt weiterlaufen. Der Rückweg besteht darin, DNS oder den Proxy zurückzuschalten.
• To do: Bewahren Sie eine Sicherung des Ziels auf, die unmittelbar vor dem letzten Import erstellt wurde, damit sich ein fehlgeschlagener letzter Import wiederholen lässt.
• To do: Legen Sie im Voraus fest, was einen Rückweg auslöst (zum Beispiel: mehr als ein festgelegter Anteil wichtiger Seiten defekt, Anmeldung funktioniert nicht) und wer darüber entscheidet.
• To do: Änderungen, die nach dem Go-live auf der neuen Site vorgenommen wurden, gehen bei einem Rückweg verloren, sofern sie nicht festgehalten werden; halten Sie das Zeitfenster kurz.

10. Nach dem Go-live #

• To do: 404-Bericht zwei Wochen lang täglich, danach wöchentlich.
• To do: Suchmaschinen-Ranking und Zugriffe mit dem Stand vorher verglichen.
• To do: Altes System archiviert (Export plus Datenbank-Dump) und zum vereinbarten Termin abgeschaltet.
• To do: Dokumentation dessen, was abgebildet wurde, für die nächste Migration.

11. Wiederkehrende Risiken #

Diese Seite ist Teil der Exponential-Dokumentation und freie Dokumentation unter der GNU Free Documentation License 1.3 oder einer späteren Version (die Lizenz dieser Dokumentation).