Wenn WordPress als mögliche Zielplattform in Betracht gezogen wird, beschreibt die Vorbereitung, welche Nachweise, Entscheidungen und Zielkonfigurationen vor der Migration geklärt werden müssen.
Für die mögliche Auswahl von WordPress als Zielplattform beginnt die Vorbereitung mit den Daten, Beziehungen und Verantwortlichkeiten, die vor der Migration eindeutig sein müssen. Die Vorbereitung auf WordPress beginnt mit der Frage, was die Website tatsächlich ist. Dieselbe WordPress-Installation kann Publikation, Dokumentationsseite, Marketing-Website, Mitgliedschaftsumgebung, Verzeichnis, Lernplattform, Veranstaltungssystem oder das CMS rund um einen WooCommerce Store sein. Core Posts und CMS Pages können nur einen Teil der betrieblich relevanten Inhalte darstellen. Benutzerdefinierte Beitragstypen, Taxonomien, Metadaten, Medienbeziehungen, Benutzer, Plugin-Tabellen, Blocks, Builder-Layouts, Redirects und externe Kennungen können darüber entscheiden, ob die migrierte Website weiterhin bearbeitbar und verständlich bleibt.
Vorbereitung sollte Nachweise aus dem Quellsystem liefern, keine Annahmen. Jede wichtige Datensatzklasse braucht einen Eigentümer, einen Export oder ein Inventar, eine repräsentative Stichprobe und eine klare Bereitschaftsbedingung. WordPress-Core-Inhalte müssen von Plugin-eigenen Anwendungsdaten getrennt bleiben; ebenso muss die Vorbereitung des WordPress-CMS von der Vorbereitung für WooCommerce Products, Customers und Orders getrennt werden.
WordPress-Umfang und Datensatzeigentümer bestätigen
Legen Sie zuerst fest, welche Quelldatensätze zu WordPress Core gehören, welche Plugins oder benutzerdefiniertem Code, welche in externen Systemen verbleiben und welche bewusst ausgeschlossen werden. Diese Grenze verhindert, dass bei einer Migration jede Zeile der WordPress-Datenbank als gewöhnlicher Inhalt behandelt wird.
WordPress speichert mehrere Beitragstypen über dieselbe Posts-Infrastruktur, dennoch bestimmt der Beitragstyp weiterhin redaktionellen Zweck, Verwaltung, Templates, Berechtigungen, Archive und API-Verhalten. Benutzerdefinierte Taxonomien benötigen außerdem ihre Registrierungen und Objektbeziehungen; Metadaten brauchen das Plugin, Theme oder den Code, der ihre Schlüssel und Werte interpretiert.
| Vorbereitungsschritt | Verantwortlich | Vorzubereitender Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Vorgesehene Rolle der WordPress-Zielwebsite definieren | Website-Verantwortlicher und Content Lead | Einseitige Umfangsbeschreibung für Publishing, Marketing, Mitgliedschaft, Verzeichnis, Lernen, Commerce oder andere Anwendungsrollen | Jede wichtige Quell-Datensatzklasse hat einen vorgesehenen WordPress-, Plugin-, externen System-, Archiv- oder Ausschluss-Eigentümer. |
| WordPress-CMS-Umfang von WooCommerce oder anderem Anwendungsumfang trennen | Website-Verantwortlicher und Technical Lead | Objektgrenze für CMS Posts, CMS Pages, Medien, Benutzer, Menüs sowie anwendungseigene Products, Orders, Mitgliedschaften, Buchungen oder Übermittlungen | Kein Anwendungsdatensatz wird nur deshalb als normale CMS Page oder normaler Post behandelt, weil er WordPress-Tabellen nutzt. |
| Topologie der Quellwebsite dokumentieren | Technischer Verantwortlicher | Domainliste, Unterverzeichnisse, Sprachsites, Multisite-Netzwerk/-Sites, Staging-Instanzen und aktive öffentliche URLs | Das Team kann für jeden ausgewählten Datensatz bestimmen, welche Website oder welches Netzwerk ihn besitzt. |
| Autoritative externe Systeme identifizieren | Integrationsverantwortlicher | Kennungsmatrix für CRM, DAM, PIM, LMS, Marketing, Suche, Identität oder Dokumentensysteme | Externe Schlüssel und fortbestehende Systems of Record sind dokumentiert, bevor Feldzuordnungen beginnen. |
Bei Multisite ist die Website- oder Blog-ID Teil des Datensatzeigentums. Benutzer können netzwerkweit beteiligt sein, während Posts, CMS Pages, Begriffe, Optionen und viele Plugin-Datensätze websitebezogen bleiben. Das Vorbereitungspaket muss diesen Kontext erhalten, statt Datensätze nach Titel oder numerischer ID zusammenzuführen.
Quellzugriff, Backups und Umgebungsnachweise sichern
Eine WordPress-Migration benötigt mehr als einen Administrator-Login. Inhalte können über Datenbank, Uploads-Verzeichnis, Plugin-Verzeichnisse, Theme-Dateien, Sprachdateien, Objektspeicher, externe Medien und externe Services verteilt sein. Die Zugriffsvorbereitung muss das Quellsystem wiederherstellbar machen und dem Team ermöglichen, benutzerdefinierte Strukturen zu verstehen.
| Vorbereitungsschritt | Verantwortlich | Vorzubereitender Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| WordPress-Administrationszugriff bestätigen | Website-Administrator | Funktionierendes Administratorkonto und Liste eingeschränkter Administrationsbereiche | Erforderliche Posts, Pages, Benutzer, Medien, Plugins, Themes, Menüs und Einstellungen können inventarisiert werden. |
| Vollständiges Quell-Backup erstellen | Hosting- oder technischer Verantwortlicher | Datiertes Datenbank-Backup plus wp-content-Dateien, Uploads, Themes, Plugins und verfügbare Konfigurationsreferenzen |
Speicherort, Datum, Wiederherstellungsverantwortlicher und Aufbewahrungsdauer sind dokumentiert. |
| Umgebungsdetails erfassen | Technischer Verantwortlicher | WordPress-Version, PHP-Version, Datenbankversion, aktives Theme, Child Theme, aktive Plugins, Must-use-Plugins und relevante Serverdienste | Die Quellumgebung lässt sich ausreichend rekonstruieren, um Inhalts- und Plugin-Eigentum zu verstehen. |
| Geplante und Hintergrundprozesse dokumentieren | Plugin- oder Integrationsverantwortlicher | WP-Cron-Ereignisse, externe Scheduler, Queues, Webhook-Endpunkte und Batch-Prozesse, die Datensätze erzeugen oder aktualisieren | Automatisierte Schreiber sind bekannt und werden nicht mit statischen migrierten Inhalten verwechselt. |
| Exportnachweise sichern | Content- und technische Verantwortliche | WordPress-Exportdateien, soweit sinnvoll, Datenbank-/Tabelleninventare, Mediendateilisten und Plugin-spezifische Exporte | Für jeden ausgewählten Datenbereich gibt es ein wiederherstellbares Quellartefakt oder einen dokumentierten Abrufweg. |
Der integrierte WordPress-Exporter kann nützliche Inhaltsnachweise liefern, ist jedoch kein vollständiges Website-Backup und bildet nicht automatisch jede Plugin-Tabelle, Option, Mediendatei, Theme-Abhängigkeit oder externen Datensatz ab. Das Vorbereitungspaket sollte daher Inhaltsexporte von vollständigen Wiederherstellungsnachweisen unterscheiden.
Posts, CMS Pages, benutzerdefinierte Beitragstypen und Lebenszykluszustände inventarisieren
Listen Sie jeden Beitragstyp mit Datensätzen auf, nicht nur die Typen, die im Hauptmenü der Administration sichtbar sind. Berücksichtigen Sie Standard-Posts und CMS Pages, Attachments, bei Bedarf Revisionen sowie jeden registrierten benutzerdefinierten Beitragstyp. Dokumentieren Sie für jeden Typ Geschäftszweck, Datensatzanzahl, öffentlichen oder privaten Status, Editor-Funktionen, Elternbeziehungen, Autorenschaft, Daten, Archivverhalten und das verantwortliche Plugin oder die Codebasis.
| Datensatzbereich | Vorzubereitender Nachweis | Zu klärende Entscheidung | Bereitschaftsbedingung |
|---|---|---|---|
| Blog Posts | Beispiele mit Autoren, Daten, Auszügen, Categories, Tags, Kommentaren, Beitragsbildern und eingebetteten Inhalten | Welche Historie, Entwürfe, geplanten Datensätze, privaten Datensätze und Archive bleiben im Umfang? | Einbezogene und ausgeschlossene Lebenszykluszustände sind ausdrücklich festgelegt. |
| CMS Pages | Eltern-Kind-Matrix, Seitentemplates, Menünutzung, Formulare, Embeds und hochwertige Routen | Welche Hierarchie- und Seitentemplate-Abhängigkeiten müssen weiterbestehen? | Jede wichtige Page hat einen Ziel-Eigentümer und einen vorgesehenen Parent- oder Top-Level-Status. |
| Benutzerdefinierte Beitragstypen | Registrierungsquelle, Feldliste, Taxonomien, Berechtigungen, Archiveinstellungen und repräsentative Datensätze | Behält das Ziel den Typ, wandelt ihn um oder verbleibt er in einer anderen Anwendung? | Jeder aktive Typ besitzt eine Zieldarstellung und einen Bearbeitungsverantwortlichen. |
| Revisionen, Autosaves und Papierkorb | Anzahl und Aufbewahrungsbegründung | Sind historische Versionen betrieblich nützlich oder nur Datenbankhistorie? | Aufbewahrung ist eine bewusste Entscheidung und kein unreflektierter Standard. |
| Private oder geschützte Inhalte | Zugriffsverantwortlicher, Zielgruppe und aktueller Schutzmechanismus | Gehört der Zugriff zu WordPress-Rollen, einem Membership-Plugin oder einem anderen System? | Geschützte Datensätze haben eine dokumentierte Identitäts- und Berechtigungsabhängigkeit. |
Verwenden Sie Datensatzanzahlen nicht als einziges Inventarkriterium. Ein benutzerdefinierter Beitragstyp mit zwanzig Datensätzen kann komplexer sein als Tausende gewöhnlicher Blog Posts, wenn er von mehreren Taxonomien, Beziehungsfeldern, benutzerdefinierten Tabellen und öffentlichen Archiven abhängt.
Taxonomien, Begriffe, Menüs und Archivbeziehungen vorbereiten
WordPress-Taxonomien klassifizieren Objekte; Menüs ordnen Navigation. Beide sollten getrennt inventarisiert werden, selbst wenn eine Category oder ein Begriff zugleich in einem Menü vorkommt. Dokumentieren Sie für jede Taxonomie, ob sie hierarchisch oder flach ist, welche Beitragstypen sie klassifiziert, ob sie öffentliche Archive besitzt, welche Metadaten zu Begriffen gehören und ob gleichlautende Bezeichnungen in anderen Taxonomien vorkommen.
| Vorbereitungsschritt | Verantwortlich | Vorzubereitender Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Standard- und benutzerdefinierte Taxonomien inventarisieren | Content-Architekt oder Plugin-Verantwortlicher | Taxonomienamen, registrierte Objekttypen, Hierarchie, Term-Anzahl, Term-Metadaten und Archiveinstellungen | Jeder ausgewählte Begriff bleibt mit der richtigen Taxonomie und dem richtigen Objekttyp verbunden. |
| Doppelte oder veraltete Begriffe bereinigen | Content-Verantwortlicher | Entscheidungslisten zum Zusammenführen, Beibehalten, Umbenennen und Ausschließen | Ähnliche Bezeichnungen werden nur zusammengeführt, wenn sie dieselbe Klassifikation darstellen. |
| Navigationsstrukturen exportieren | Content-Verantwortlicher | Primäre, Footer-, Utility-, kontextbezogene und sprachspezifische Menübäume mit benutzerdefinierten Links | Menüposition ist getrennt von Inhaltshierarchie und Taxonomiezugehörigkeit dokumentiert. |
| Archivziele dokumentieren | SEO- und Content-Verantwortliche | URL-Liste für Category-, Tag-, benutzerdefinierte Taxonomie-, Autoren-, Datums- und Custom-Post-Type-Archive | Jedes wichtige Archiv hat ein vorgesehenes Ziel, einen Ersatz oder eine Redirect-Entscheidung. |
Term-IDs und Menüeintrags-IDs sind installationsspezifisch. Wenn Metadaten oder Builder-Datensätze auf diese IDs verweisen, müssen die Vorbereitungshinweise die referenzierte Taxonomie, den Begriff, das Menü oder Inhaltsobjekt benennen und nicht nur die alte Nummer.
Metadaten, benutzerdefinierte Felder, Optionen und Plugin-Tabellen zuordnen
Metadaten können ein einfacher redaktioneller Wert, eine Objektreferenz, serialisierte Konfiguration, Layoutdaten, eine externe Kennung oder Anwendungszustand sein. Erstellen Sie ein Key-Inventar für wichtige Post-, User-, Term- und Comment-Metadaten. Gruppieren Sie Keys nach Eigentümer und Zweck, statt jeden technischen Schlüssel ungeprüft erhalten zu wollen.
Plugins können außerdem eigene Tabellen anlegen, wenn ihre Domäne nicht in die WordPress-Core-Strukturen passt. Formulare, Mitgliedschaften, Lernsysteme, Veranstaltungen, Buchungen, Verzeichnisse, Redirects, Analysen und Integrationen verwenden häufig benutzerdefinierte Tabellen für Definitionen, Transaktionen, Historien oder Beziehungen.
| Vorbereitungsschritt | Verantwortlich | Vorzubereitender Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Geschäftskritische Metadaten-Keys inventarisieren | Plugin-Verantwortlicher und Content Lead | Key-Name, Objekttyp, Datenformat, Beispielwerte, nutzerbezogener Zweck und Typ des referenzierten Objekts | Jeder beibehaltene Key besitzt ein Zielfeld, einen Plugin-Eigentümer oder einen externen Eigentümer. |
| Objektreferenzfelder identifizieren | Technischer Verantwortlicher | Beispiele für Post-, Attachment-, User-, Term- und externe IDs in Metadaten | Referenzen können auf Zielobjekte übertragen werden, statt veraltete numerische IDs zu kopieren. |
| Serialisierte oder strukturierte Felder dokumentieren | Plugin- oder Builder-Verantwortlicher | Schemabeispiele, Wiederholfelder, Gruppen, JSON-/serialisierte Payloads und Felddefinitionen | Das Ziel kann die Struktur interpretieren oder eine Entscheidung zur Neustrukturierung ist dokumentiert. |
| Website- und Plugin-Optionen inventarisieren | Technischer Verantwortlicher | Geschäftsrelevante Optionen, zuständiges Plugin/Theme, Website-Geltungsbereich und Einordnung als Inhalt oder Konfiguration | Konfiguration wird nicht stillschweigend als migrierter Inhalt klassifiziert. |
| Benutzerdefinierte Tabellen inventarisieren | Plugin-Verantwortlicher und Datenbankadministrator | Tabellennamen, Zeilenzahlen, Primärschlüssel, Elternbeziehungen, Daten, Status und externe Schlüssel | Jede geschäftskritische Tabelle besitzt ein ausdrückliches Ziel, ein fortbestehendes externes System, ein Archiv oder eine Ausschlussentscheidung. |
Technische Caches, temporäre Datensätze, Logs, Sessions, generierte Indizes und aufgegebene Plugin-Daten sollten nicht nur deshalb einbezogen werden, weil sie existieren. Ihr Ausschluss sollte dokumentiert sein, damit spätere Datenbankvergleiche bewusste Bereinigung nicht als fehlende Inhalte interpretieren.
Medien, Blocks, Builder, Themes und eingebettete Inhalte vorbereiten
Die Medienvorbereitung muss Dateien und Referenzen erhalten. Dokumentieren Sie Beitragsbilder, Inline-Bilder, Galerien, herunterladbare Dokumente, extern gehostete Assets, Bildunterschriften, Alt-Text, Attachment-Metadaten und wiederverwendete Dateien. Identifizieren Sie Dateien, die im Uploads-Verzeichnis vorhanden, aber nicht mehr referenziert sind, sowie Referenzen auf fehlende Dateien.
Inhaltsdarstellung kann als Core Blocks, HTML des klassischen Editors, Shortcodes, Widgets, wiederverwendbare Blocks, Patterns, Template-Parts, Page-Builder-Metadaten, Theme-Optionen oder benutzerdefinierte Templates gespeichert sein. Die WordPress-Zielimplementierung kann einen anderen Builder oder ein anderes Theme verwenden; deshalb sollte die Vorbereitung wiederverwendbaren Inhalt von quellenspezifischen Layoutdaten trennen.
| Vorbereitungsbereich | Vorzubereitender Nachweis | Verantwortlich | Bereitschaftsbedingung |
|---|---|---|---|
| Mediathek | Dateiinventar, Attachment-Datensätze, Alt-Text, Bildunterschriften, Featured-Image-Beziehungen, Galerien und externe URLs | Content- und Medienverantwortliche | Priorisierte Dateien sind erreichbar und jede wichtige Referenz besitzt eine bekannte Quelldatei oder einen externen Eigentümer. |
| Core Blocks und klassische Inhalte | Repräsentative Inhalte mit Links, Embeds, Tabellen, wiederverwendbaren Blocks und komplexer Formatierung | Redaktioneller Verantwortlicher | Inhaltsmuster, die Konvertierung oder manuelle Rekonstruktion benötigen, sind identifiziert. |
| Shortcodes | Shortcode-Inventar, besitzendes Plugin/Theme, Beispielseiten und erwartete Ausgabe | Plugin-Verantwortlicher | Jeder kritische Shortcode besitzt einen weiterbestehenden Renderer oder eine Ersatzentscheidung. |
| Page Builder | Builder-Version, Templates, globale Abschnitte, Feldspeicher, Theme-Abhängigkeit und Beispiellayouts | Design- und technische Verantwortliche | Wiederverwendbarer Inhalt ist von Builder-spezifischen Darstellungsdaten getrennt. |
| Themes und Template-Parts | Aktives/Child Theme, benutzerdefinierte Templates, Widget-Bereiche, Template-Parts und globale Styles | Design-Verantwortlicher | Theme-Code wird als Implementierungsnachweis und nicht als gewöhnlicher Inhalt behandelt. |
Für die WordPress-Vorbereitung muss das endgültige Design noch nicht fertig sein. Es müssen jedoch genügend Eigentumsnachweise vorliegen, damit Builder-Daten, Theme-Code, Shortcodes und wiederverwendbare Inhalte nicht zu einem undifferenzierten Migrationsumfang vermischt werden.
Benutzer, Rollen, Autoren, Kommentare und datenschutzsensible Datensätze vorbereiten
WordPress-Benutzer können Autoren, Redakteure, Administratoren, Abonnenten, Mitglieder, Lernende, Anbieter oder Customers einer anderen Anwendung sein. Core-Rollen und Capabilities definieren Berechtigungen, während Plugins zusätzliche Rollen, Capabilities, Profile, Mitgliedschaften und Historien ergänzen können. Inventarisieren Sie Rolle und Anwendungsbeziehung getrennt.
| Vorbereitungsschritt | Verantwortlich | Vorzubereitender Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Benutzergruppen klassifizieren | Website-Administrator und Business-Verantwortlicher | Anzahl und Beispiele nach Rolle, Anwendungstyp, aktivem Status, Autorenschaft und Kontozweck | Autoren, Mitarbeiter, Mitglieder, Abonnenten und Anwendungsbenutzer werden nicht allein anhand der E-Mail-Adresse zusammengeführt. |
| Benutzerdefinierte Rollen und Capabilities dokumentieren | Technischer Verantwortlicher | Rollendefinitionen, benutzerdefinierte Capabilities, besitzendes Plugin/Code und repräsentative Benutzer | Erforderliches Zugriffsverhalten besitzt einen Ziel-Eigentümer; veraltete Privilegien werden ausgeschlossen. |
| Autorenschaft und Eigentum verknüpfen | Redaktioneller Verantwortlicher | Priorisierte Posts und benutzerdefinierte Datensätze mit Autor-/Eigentümerreferenzen | Einbezogene Datensätze besitzen auflösbare Zielautoren oder einen genehmigten Fallback-Eigentümer. |
| Kommentare und Bewertungen inventarisieren | Content- oder Community-Verantwortlicher | Status, Hierarchie, Autorenidentität, zugehörige Inhalte, Spam-/Ausschlussregeln und Plugin-Eigentum | Blog-Kommentare, Diskussionen, Testimonials und Commerce-Bewertungen bleiben korrekt klassifiziert. |
| Datenschutzsensible Felder identifizieren | Datenschutz- und Business-Verantwortliche | Feldinventar, Einwilligungsgrundlage, Aufbewahrungsregel und Zugriffsanforderung | Sensible Daten besitzen eine genehmigte Migrations-, Archivierungs-, Redaktions- oder Ausschlussentscheidung. |
Quell-Passwort-Hashes und externe Authentifizierungsidentitäten sollten getrennt von grundlegenden Benutzerprofilen dokumentiert werden. Ein Benutzerdatensatz kann im Umfang liegen, auch wenn die ursprüngliche Authentifizierungsinformation nicht übertragbar ist.
URLs, SEO-Metadaten, Redirects, Sprachen und Multisite-Kontext vorbereiten
Erstellen Sie ein Quell-URL-Inventar für hochwertige CMS Pages, Blog Posts, benutzerdefinierte Beitragstypen, Taxonomiearchive, Autorenarchive, Medien, Feeds und Plugin-Routen. Dokumentieren Sie Permalink-Struktur, Elternhierarchie, Taxonomie-Rewrite-Regeln, Domain-/Unterverzeichnis-Kontext, Canonical-URLs und bestehende Redirects.
SEO-Felder können in Kern-Datensätzen, Metadaten, Plugin-Tabellen oder externen Plattformen gespeichert sein. Inventarisieren Sie Titel, Beschreibungen, Canonical-Werte, Social-Felder, strukturierte Daten, Indexierungssteuerung und Redirect-Datensätze nach Eigentümer. Gehen Sie nicht davon aus, dass ein Plugin-Export jede Routenbeziehung enthält.
| Vorbereitungsschritt | Verantwortlich | Vorzubereitender Nachweis | Bereitschaftsbedingung |
|---|---|---|---|
| Priorisierte Quell-URLs erfassen | SEO-Verantwortlicher | Durch Analytics/Suche priorisierte URL-Liste mit aktuellem Status und Zielabsicht | Jede Prioritätsroute besitzt eine Entscheidung: beibehalten, ändern, zusammenführen, außer Betrieb nehmen oder umleiten. |
| Permalink- und Rewrite-Logik dokumentieren | Technischer Verantwortlicher | Permalink-Einstellungen, Rewrite-Regeln für benutzerdefinierte Beitragstypen und Taxonomien, Plugin-Endpunkte sowie Multisite-Pfad-/Domain-Regeln | Die Zielroutenarchitektur kann Inhaltsdatensätze von Archiven und Anwendungsendpunkten unterscheiden. |
| SEO-Dateneigentümer inventarisieren | SEO- und Plugin-Verantwortliche | Metadaten-Key-/Tabellenübersicht, Exportdateien, Canonical-Regeln, Indexierungsregeln und Sitemap-Quellen | Jeder beibehaltene SEO-Wert besitzt einen Ziel-Eigentümer. |
| Mehrsprachige Beziehungen vorbereiten | Lokalisierungsverantwortlicher | Sprachen, Übersetzungsgruppen, Locale-Codes, sprachspezifische Routen und Fallback-Regeln | Übersetzungen bleiben miteinander verbunden, statt zu unabhängigen Duplikaten zu werden. |
| Bestehende Redirects dokumentieren | SEO- oder technischer Verantwortlicher | Quelle, Ziel, Status, Eigentümer und Priorität | Doppelte, verkettete, veraltete und weiterhin erforderliche Redirects sind klassifiziert. |
Bei Multisite muss die Netzwerk-/Website-Beziehung Bestandteil der URL-Nachweise sein. Identische Slugs auf verschiedenen Websites sind unterschiedliche Routen und dürfen nicht ohne ausdrückliche Inhaltsentscheidung zusammengeführt werden.
Repräsentative Migrations-Testmuster auswählen
Die Auswahl repräsentativer Migrationsmuster sollte die strukturelle Vielfalt der Website abbilden und nicht nur aktuelle oder einfache Datensätze. Jedes Muster sollte die erwarteten Inhaltsbeziehungen, verknüpften Dateien, Routennachweise und verantwortlichen Prüfer benennen.
| Muster | Vorzubereitender Nachweis | Warum es in die Stichprobe gehört |
|---|---|---|
| Hierarchische CMS Page | Eltern-/Kindroute, Template, Blocks oder Builder-Daten, Medien, Menünutzung und SEO-Felder | Repräsentiert Page-Hierarchie, Darstellungsabhängigkeiten und Routing. |
| Blog Post mit Beziehungen | Autor, Categories, Tags, Kommentare, Beitragsbild, Embeds und Archivrouten | Repräsentiert redaktionelle Historie und Klassifikation. |
| Ein Datensatz jedes wichtigen benutzerdefinierten Beitragstyps | Taxonomien, Metadaten, Medien, öffentliche Route, besitzendes Plugin und verwandte Datensätze | Macht Plugin-Registrierung und Abhängigkeiten benutzerdefinierter Schemata sichtbar. |
| Metadatenintensiver Datensatz | Felddefinitionen, Referenz-IDs, Wiederholfelder, serialisierte Werte und externe IDs | Zeigt, ob Feldwerte interpretierbar bleiben können. |
| Benutzer mit Anwendungskontext | Rolle, Capabilities, verfasste Datensätze, Profildaten und Membership- oder andere Plugin-Beziehung | Repräsentiert Identität, ohne Core-Benutzer mit Plugin-Profilen zu verwechseln. |
| Komplexer Medien-/Inhaltsdatensatz | Galerie, Download-Datei, wiederverwendetes Attachment, Shortcode/Embed und interne Links | Repräsentiert Datei- und Inhaltsreferenzabhängigkeiten. |
| Mehrsprachiger oder Multisite-Datensatz, falls relevant | Website-/Spracheigentum, Übersetzungslinks, Routen und gemeinsame Benutzer | Macht Website-Grenzen und Lokalisierungsbeziehungen sichtbar. |
Ein Stichprobenregister sollte Quell-ID, gegebenenfalls öffentliche URL, Datensatzeigentümer, verwandte Objekte, Auswahlgrund und ungelöste Abhängigkeiten enthalten. Einfache Datensätze können den Basisfall bestätigen, komplexe Datensätze zeigen dagegen, ob die Umfangsnachweise vollständig sind.
Abschließendes WordPress-Bereitschaftstor abschließen
Konsolidieren Sie die Vorbereitungshinweise vor der Ausführung in einem einzigen Bereitschaftsregister. Ein ungelöster Punkt darf nur offen bleiben, wenn er einen Verantwortlichen, ein Entscheidungsdatum und eine definierte Auswirkung auf den Umfang besitzt.
| Bereitschaftsbereich | Bereitschaftsbedingung |
|---|---|
| Umfang und Eigentum | Jeder ausgewählte Datensatztyp gehört WordPress Core, einer benannten Plugin-/Custom-Anwendung, einem externen System, einem Archiv oder einem bewussten Ausschluss. |
| Zugriff und Wiederherstellung | Administratorzugriff, Datenbank-Backup, Datei-Backup, Umgebungsinventar und Wiederherstellungsverantwortung sind dokumentiert. |
| Inhaltsarchitektur | Posts, CMS Pages, benutzerdefinierte Beitragstypen, Taxonomien, Menüs und Lebenszykluszustände besitzen ausdrückliche Einbeziehungs- und Zielentscheidungen. |
| Benutzerdefinierte Daten | Wichtige Metadaten, Optionen, benutzerdefinierte Tabellen, Objektreferenzen und externe Kennungen besitzen bekannte Schemata und Eigentümer. |
| Medien und Darstellung | Priorisierte Dateien sind verfügbar; Builder-, Block-, Shortcode-, Theme- und Template-Abhängigkeiten sind klassifiziert. |
| Benutzer und Datenschutz | Rollen, Autorenschaft, Anwendungsprofile, Kommentare, Authentifizierungsabhängigkeiten und sensible Felder sind klassifiziert. |
| URLs und SEO | Prioritätsrouten, Permalink-Logik, Redirects, Sprach-/Website-Kontext und SEO-Dateneigentümer sind dokumentiert. |
| Stichproben | Das Stichprobenregister repräsentiert jedes wesentliche WordPress-Inhalts- und Anwendungsmuster im Umfang. |
Der WordPress-Umfang ist bereit, wenn das Migrationsteam für jeden ausgewählten Datensatz bestimmen kann, was er ist, wo die zugehörigen Daten liegen, wer seine Zieldarstellung besitzt und welche Quellnachweise diese Entscheidung stützen.
Fazit
Die Vorbereitung auf WordPress ist eine Eigentumsaufgabe über Inhalte, Klassifikation, Metadaten, Medien, Identität, Darstellung, Plugins, benutzerdefinierte Tabellen, Routen und externe Systeme hinweg. Ein vollständiges Backup und Administratorzugriff sind erforderlich, erklären jedoch keine benutzerdefinierten Beitragstypen, Taxonomiebeziehungen, Builder-Strukturen, Anwendungsprofile, Multisite-Grenzen oder Plugin-eigenen Datensätze.
Ein starkes Vorbereitungspaket macht diese Beziehungen ausdrücklich. Es trennt WordPress-CMS-Daten von WooCommerce oder anderen Anwendungsdomänen, erhält wiederherstellbare Quellnachweise, wählt repräsentative Stichproben und ordnet jeden wichtigen Datensatz vor Beginn der Migration einem Ziel, einem fortbestehenden externen Eigentümer, einem Archiv oder einem bewussten Ausschluss zu.
Häufige Fragen
Was sollte für eine WordPress-Migration zuerst vorbereitet werden?
Definieren Sie die Rolle der WordPress-Zielwebsite und klassifizieren Sie die Eigentümer der Quelldatensätze. Dadurch steht vor detaillierter Feldarbeit fest, ob jeder Datensatz zu WordPress Core, einem Plugin oder einer Custom-Anwendung, einem externen System, einem Archiv oder einem bewussten Ausschluss gehört.
Ist die WordPress-Exportdatei ein vollständiges Migrations-Backup?
Nein. Der integrierte Export kann nützliche Inhaltsnachweise liefern, doch ein wiederherstellbares Quellsystem benötigt üblicherweise zusätzlich Datenbank, Medien und andere wp-content-Dateien, Umgebungsdetails sowie Plugin-spezifische oder externe Datensätze, die der Export nicht abbildet.
Warum müssen benutzerdefinierte Beitragstypen und Taxonomien getrennt inventarisiert werden?
Sie können WordPress-Speicher teilen und trotzdem unterschiedliche Registrierungen, Berechtigungen, Editoren, Metadaten, Archive, Templates und Plugin-Eigentümer verwenden. Nur Titel und Inhaltskörper zu erhalten würde die Struktur nicht erhalten, durch die diese Datensätze verwaltbar bleiben.
Wie sollten benutzerdefinierte Felder und Metadaten vorbereitet werden?
Dokumentieren Sie Metadaten-Eigentümer, Objekttyp, Werteformat, Felddefinition, referenzierte Objekte, repräsentative Stichproben und vorgesehenes Ziel. Numerische IDs und serialisierte Werte sollten nicht kopiert werden, ohne die Datensätze oder Schemata zu übertragen, auf die sie verweisen.
Sollten Plugins und Themes als migrierte Inhalte behandelt werden?
Nicht automatisch. Plugins und Themes sind Implementierungsabhängigkeiten. Ihre geschäftskritischen Datensätze, Einstellungen, benutzerdefinierten Tabellen, Shortcodes, Templates und externen Links benötigen ausdrückliche Eigentumsentscheidungen; temporäre oder veraltete technische Daten können ausgeschlossen werden.
Wie unterscheidet sich die WordPress-Vorbereitung von der WooCommerce-Vorbereitung?
Die WordPress-Vorbereitung umfasst CMS Posts, CMS Pages, benutzerdefinierte Beitragstypen, Taxonomien, Metadaten, Medien, Benutzer, Menüs, Routen und Plugin-Anwendungsgrenzen. WooCommerce-Vorbereitung umfasst dagegen separat Products, Varianten, Customers, Orders, Coupons, Commerce-Bewertungen, HPOS, Checkout-Metadaten und Commerce-Erweiterungen.