Website-Schnittstellen und Datenmigration
Welche Daten sollen aus welchem System in die Website gelangen – und was muss nach einem Wechsel erhalten bleiben? Eloquin klärt Datenquellen, Felder, Zuständigkeiten und Fehlerfälle. Daraus entstehen ein nachvollziehbarer Schnittstellenumfang oder eine überprüfbare Migration mit abgestimmter Abnahme.
Für Website- und CMS-Verantwortliche
Wir benennen führendes System, Übertragungsrichtung, Felder, Auslöser oder Takt und erwartete Bestätigung. Bei einem Fehler ist festgelegt, wer ihn sieht und wie ein erneuter Versuch ohne unbeabsichtigte Doppelverarbeitung erfolgt.
Zu übernehmende Inhalte, Status, Medien, Beziehungen und URL-Zuordnungen erhalten konkrete Regeln. Probelauf, fachliche Freigabe, Änderungen bis zum Wechsel und Rücknahme werden ausdrücklich eingeplant.
Benötigt werden verantwortliche Dateninhaber, erlaubter Testzugang und ein verständliches Zielmodell. Sie erhalten Feldzuordnung, Prüfprotokoll, offene Fehlerfälle und die vereinbarte technische Umsetzung beziehungsweise Übergabe.
Diese Leistung behandelt Website-, Inhalts- und Formularübergaben. Shop-Schnittstellen und Shopmigration vertiefen Artikel, Bestände und Bestellungen. Eine WordPress-Umsetzung ist eine CMS-Entscheidung; Hosting ist ein Betriebsauftrag. Ein Systemwechsel oder neuer Server ist nicht automatisch Teil einer Datenzuordnung.
Illustratives Feldmapping und Probelauf
Aufgabe: Ein Unternehmen übernimmt drei redaktionelle Datensätze aus einem alten CMS. Veröffentlichte Artikel sollen ihre vorgesehenen Pfade behalten; Entwürfe dürfen nicht versehentlich öffentlich werden. Im Ziel gilt je öffentlichem Pfad genau ein Inhalt.
Für jeden Datensatz wird die alte Kennung als externe Identität erhalten. Die folgenden Modellpfade sind Textbeispiele und keine neu angelegten Eloquin-URLs.
Auf schmalen Bildschirmen können Sie die Tabelle horizontal verschieben, um alle Spalten zu lesen.
| Quelle → Ziel | Vereinbarte Regel | Fehlerfall und Abnahme |
|---|---|---|
legacy_id → external_id | Die Ganzzahl 104 wird zur stabilen Kennung altcms:104. Bei erneutem Einlesen wird derselbe Quelldatensatz wiedererkannt. | Fehlende oder doppelte Quellkennung: Fall zurückstellen. Ein wiederholter Lauf darf keinen zweiten Zielinhalt für dieselbe Kennung erzeugen. |
path → public_path | /ratgeber/montage-planen wird für den dafür freigegebenen Artikel unverändert übernommen. Pfadzuordnung ist eine eigene Regel, kein Nebenprodukt des Titels. | Zwei unterschiedliche Quellkennungen mit demselben öffentlichen Pfad: Konflikt sichtbar halten, keinen Inhalt still überschreiben. |
headline → title und body → content | Titel und Hauptinhalt werden vollständig übernommen. Vereinbarte Formatumwandlungen werden anhand einer erhaltenen Quelle geprüft. | Leerer erforderlicher Inhalt oder unzulässige Formatierung: keine stille Veröffentlichung. Absätze, Überschriften und Links in der Zielansicht vergleichen. |
status → publication_status | published wird veröffentlicht, draft bleibt Entwurf. Ein unbekannter Quellstatus wird nicht als öffentlich interpretiert. | Statusfehler zurückstellen; die Fachperson bestätigt die tatsächliche Sichtbarkeit in der getrennten Testumgebung. |
cover_file → media_reference | Eine vorgesehene freigegebene Beispieldatei montage.jpg wird genau dem Artikel zugeordnet; Beschreibung und Bezug zum Inhalt bleiben erhalten. Ein nicht vorgesehenes optionales Titelbild wird nicht erfunden. | Fehlende Datei oder ungeklärte Freigabe: als offener Medienfall ausweisen. Bild, Verweis und Ausgabe im Ziel gemeinsam prüfen. |
source_updated_at → source_modified_at | Das fachlich relevante Quelldatum bleibt erhalten. Der Importzeitpunkt wird getrennt protokolliert. | Nicht lesbares Datum: zurückstellen oder ausdrücklich freigegebene Regel anwenden. Ein Import erzeugt kein angeblich neues redaktionelles Änderungsdatum. |
Quelle: „Montage planen“, Pfad /ratgeber/montage-planen, Status published, Hauptinhalt und freigegebene Beispieldatei vorhanden.
Ergebnis: Ein Zielartikel erhält altcms:104, den unveränderten Pfad, den vollständigen Inhalt und die passende Medienreferenz. Fachliche Stichprobe und Zielansicht werden protokolliert.
Quelle: „Montage planen – Zusatz“, eine andere Quellkennung, aber derselbe öffentliche Pfad wie 104.
Ergebnis: Dieser Fall wird mit Grund zurückgestellt. Die Fachperson entscheidet, ob es eine Korrekturfassung, einen eigenständigen Inhalt oder einen Dubletteneintrag gibt. 104 wird nicht überschrieben.
Quelle: „Servicecheck vorbereiten“, eigener Modellpfad /ratgeber/servicecheck, Status draft, vollständiger Text; ein Titelbild ist für diesen Inhalt im Beispiel nicht vorgesehen.
Ergebnis: Der Datensatz wird als nicht öffentlicher Zielentwurf mit altcms:106 übernommen. Er wird beim Abgleich mitgezählt, erhält aber keine öffentliche Freigabe.
Drei Quellen = zwei übernommene Zielinhalte + ein zurückgestellter Konflikt. Von den zwei Zielinhalten ist einer öffentlich vorgesehen und einer ein Entwurf. Es fehlt kein still verworfener Datensatz.
Ein zweiter Probelauf mit demselben Bestand muss weiterhin diese zwei Identitäten und denselben offenen Konflikt zeigen. Zusätzlich werden Inhalte, Status, Modellpfade und Medienbezug geprüft. Eine passende Gesamtzahl allein würde eine vertauschte Bildzuordnung oder eine versehentliche Veröffentlichung des Entwurfs nicht erkennen.
Für einen echten Auftrag werden größere Bestände anhand der festgelegten Regeln geprüft und die fachlichen Stichproben begründet. Ein endgültiger Wechsel erfolgt erst nach Abnahme und einem Plan für zwischenzeitlich geänderte Daten. Die Zielseite oder der neue Systemstand darf offene Konflikte nicht verdecken.
Wiederkehrende Übertragung
Bei einer Website-Anfrage an ein CRM wird beispielsweise festgelegt: Die Website bestätigt zuerst ihre Annahme, eine technische Kennung ordnet den Vorgang zu, das Zielsystem bestätigt die erlaubte Übernahme und eine fehlende Bestätigung bleibt als eigener Fehler sichtbar. Ob dafür eine Warteschlange oder ein anderer Mechanismus passt, hängt von den tatsächlichen Systemen und dem vereinbarten Betrieb ab.
Das Konzept benennt außerdem, welche Felder überhaupt weitergegeben werden, wer sie pflegt, welche Zugangsdaten wo sicher verwaltet werden und welche Protokollinformationen für die Fehlerbearbeitung erforderlich sind. Zugangsdaten oder vollständige Anfrageinhalte gehören nicht in eine erste Projektbeschreibung.
Die WordPress-Dokumentation zu Schnittstellenschemata zeigt beispielhaft, wie Datenstruktur und erlaubte Eingaben beschrieben werden können. Welche Felder ein konkretes Fremdsystem anbietet, wird vor der Umsetzung anhand seiner eigenen Dokumentation und Testmöglichkeiten geprüft.
Probelauf, Abnahme und Übergabe
Quellen, Dateninhaber, erlaubten Umfang und Zielmodell abgleichen. Inhalte, Medien und URL-Entscheidungen werden gemeinsam erfasst.
Zuordnungen in einer eigenen Testumgebung durchführen. Fehlerfälle, Wiederholung und fachliche Zielausgabe erhalten dokumentierte Abnahmekriterien.
Freigabe, letzte Änderungen, Rücknahme und zuständige Personen benennen. Laufende Übertragungen benötigen zusätzlich klare Beobachtung und Fehlerbearbeitung.
Wenn sich URLs ändern, erläutert Google die Vorbereitung einer passenden URL-Zuordnung. Eine Datenübernahme allein garantiert keine unveränderte Suchentwicklung. Der eigene Fachartikel Relaunch mit bestehenden URLs vorbereiten zeigt diese Entscheidung an einer vollständigen Beispielmatrix.
Die Webentwicklung ordnet technische Umsetzung und Übergabe ein. Der Leitfaden zum Anfrage-Tracking vertieft die Trennung zwischen Klick, Annahme und weiterer Verarbeitung. Umfang und Aufwand hängen etwa von Datenmodellen, Beziehungen, Medien, Schnittstellen, Qualitätslücken und laufenden Änderungen ab.
Vor der Zusammenarbeit
Eine Schnittstelle überträgt Daten wiederkehrend zwischen vereinbarten Systemen. Eine Migration überführt einen abgegrenzten Bestand in ein Zielsystem, oft mit einem späteren Wechsel. Beide brauchen Zuordnungsregeln und Fehlerbehandlung; Umfang, Wiederholungen und Betriebsaufgaben unterscheiden sich.
Das lässt sich erst anhand vorhandener Zugänge, dokumentierter Schnittstellen, Datenmodelle und erlaubter Nutzung beurteilen. Systeme, Versionen, Berechtigungen und Testmöglichkeiten werden vor einer Umsetzungszusage geprüft. Eine allgemeine Seite ersetzt diese technische Prüfung nicht.
Der vereinbarte Datenbestand erhält stabile Quellkennungen und definierte Prüfregeln. Probeläufe gleichen Mengen, wichtige Felder, Status, Medien und Beziehungen ab. Zurückgestellte Datensätze bleiben mit Ursache sichtbar. Wiederholbarkeit und Dublettenbehandlung werden gezielt geprüft.
Welche URLs, Medien und Verweise erhalten bleiben sollen, wird vorher festgelegt. Bei URL-Änderungen wird eine fachlich passende Zuordnung vorbereitet. Verfügbarkeit, Nutzungsrechte und technische Verweise von Medien gehören zur Prüfung; eine Kopie allein bestätigt ihre richtige Einbindung nicht.
Der nächste Schritt
Nennen Sie Quell- und Zielsystem, Datenarten und den Anlass des Übergangs. Beschreiben Sie bekannte Konflikte zunächst ohne Passwörter oder vertrauliche Exporte.
