Die China-Websites von Ingersoll Rand, in fünf Monaten vom Oracle Content Manager migriert.

20+

Marken-Mandanten in China

5

Monate bis zur Auslieferung

5

Kernteam

Tausende

Migrierte Seiten

Zehntausende

Migrierte Media-Assets

Zehntausende

Verarbeitete Weiterleitungen

• OCM-Stichtag eingehalten
• 9 Seitentypen
• Dutzende wiederverwendbare Blöcke
• 2 aktive Sprachen
• AWS China
• 24/7-Monitoring

Technische, organisatorische und regulatorische Hürden trafen auf einen festen End-of-Life-Termin.

Die Plattform war ein bestehendes globales Produkt. Jede einzelne der folgenden Rahmenbedingungen hätte den Termin für sich genommen kippen können.

1. China lief auf einem CMS, das abgeschaltet wurde.

   Die neu gebaute Plattform lief global auf Contentstack, mit Produktionslogik, die an CMS-spezifische Daten gebunden war. China lief noch auf dem alten Build mit dem Oracle Content Manager, weil Contentstack in der Region nicht verfügbar war. Als OCM sein End-of-Life ankündigte, brauchte China einen neuen Weg zu einem festen Termin, ohne ein zeitlich offenes Rewrite.

2. AWS China war eine regulatorische Vorgabe für eine Live-Plattform.

   Die Plattform musste für den regionalen Rollout innerhalb von AWS China laufen. Gemeinsam mit einem lokalen Infrastruktur-Partner haben wir AWS China aufgesetzt und ein 24/7-Monitoring eingerichtet. Die Infrastruktur musste im selben Zeitrahmen stehen wie das CMS, denn Ausfallzeit war für eine live betriebene, kundenorientierte Plattform nicht verhandelbar.

3. Anforderungen kamen aus verschiedenen Regionen und Zeitzonen.

   Der China-Rollout musste für China funktionieren und zugleich Feature-Anfragen des globalen Teams aufnehmen. Die Entscheider saßen in unterschiedlichen Zeitzonen. Anforderungen zu sammeln und in Einklang zu bringen erforderte anhaltenden Einsatz auf unserer Seite, und das gesamte Projekt baute auf dem auf, was wir zusammengetragen haben.

4. Das Scoping war ein Ergebnis, noch bevor eine Zeile Code ausgeliefert wurde.

   Ingersoll Rand hat uns die Verantwortung dafür übertragen, wie die Umsetzung geplant wird. Bevor Code geschrieben wurde, haben wir Scoping-Sessions mit den Stakeholdern durchgeführt, um den Kreis der Redakteure, das Content-Modell, den Redaktions-Workflow und die Integrationen mit dem Rest des Unternehmens zu definieren. Diese Phase ist der Grund, warum das Projekt pünktlich ausgeliefert wurde.

5. Die OCM-Abschaltung gab den Launch-Termin vor.

   Wir haben geliefert, indem wir eine klare Linie zwischen Arbeit gezogen haben, die vor der Abschaltung fertig sein musste, und Arbeit, die für die Zeit danach eingeplant werden konnte. Diese Entscheidung fiel früh und hatte über die gesamte Umsetzung Bestand. Deshalb kam das Projekt pünktlich ins Ziel, ohne bei den für den Launch entscheidenden Teilen Abstriche zu machen.

Ein fünfköpfiges Kernteam im Continuous-Delivery-Betrieb.

Eine Content-Provider-Schicht hält das Frontend von jedem konkreten CMS unabhängig.

Das Frontend von Ingersoll Rand ist eine komplexe Next.js-Anwendung, und die neu gebaute Plattform war eng an Contentstack gekoppelt. Ein CMS einfach gegen ein anderes zu tauschen hätte die kurzfristige Migration gelöst, aber dasselbe architektonische Problem in neuer Form belassen. Zudem hätte es Chinas Payload und den Rest der Plattform auf Contentstack als zwei auseinanderlaufende Codebasen zurückgelassen.

Die zentrale Entscheidung war, einen Content-Provider-Service im Frontend einzuführen. Die Schicht wählt den aktiven Provider über Konfiguration aus und validiert Ein- und Ausgaben mit Zod. Der Rest der Anwendung sieht einen gemeinsamen Content-Vertrag und erhält Daten in einem einheitlichen Schema, unabhängig davon, welches CMS hinter der Schnittstelle liegt.

Wir haben Adapter für beide Systeme gebaut, Contentstack und Payload, gegen denselben Vertrag. Seitentypen, Feature-Blöcke, Medien, Rich Text, Routing, SEO, Regionalisierung, Navigationskarten, Distributoren, Gated Content und Mandantenkonfiguration wanderten hinter Provider-Adapter. Zuvor verstreute Provider-Logik wurde zentralisiert, und kleinere Refactorings verbesserten Routing, Datenabbildung und Cache-Grenzen.

Payload erfüllte die technischen Anforderungen und die regionale Vorgabe.

Payload wurde gegenüber anderen selbstgehosteten CMS-Optionen für seine Flexibilität, seine entwicklerorientierte Architektur und sein Erweiterungsmodell gewählt. Sein moderner Stack machte individuelle Entwicklung auf einem engen Zeitplan schneller. Das war für die Teile der Plattform entscheidend, die über das Standardverhalten hinausgehen mussten, darunter granulares RBAC, individuelle Dashboards, eigene API-Endpunkte und die Projektion der Navigationskarte.

Der China-Rollout brachte zudem eine regionale Vorgabe mit sich. Das gewählte CMS musste innerhalb von Festlandchina betrieben werden können, wo Contentstack nicht verfügbar war. Payload erfüllte sowohl die technischen als auch die regionalen Anforderungen.

Ein dediziertes CMS auf Payload, zugeschnitten auf das interne Team.

Der Arbeitsbereich unterstützt 20+ Marken-Mandanten in der Region China. Mehrere Redakteure verwalten lokalisierte Inhalte, Mandantenkonfiguration, Weiterleitungen, Seitenhierarchie und wiederverwendbare Content-Blöcke in einer einzigen gemeinsamen Umgebung. Das Content-Modell unterstützt heute 9 Seitentypen und wurde so entworfen, dass neue Seitentypen und Blöcke ergänzt werden können, ohne das System neu zu denken.

Die Performance der öffentlichen Website sollte nicht davon abhängen, wie viele Redakteure gerade aktiv sind.

Payload leistet im Hintergrund erhebliche Datenbankarbeit rund um Entwürfe, Versionen, Lokalisierung und Beziehungen. In der ersten Ausbauphase konnte Aktivität im CMS die Performance der Consumer-Website beeinflussen. Für eine Enterprise-Plattform ist eine solche Kopplung riskant.

Gelöst haben wir das, indem wir das Lesemodell verändert haben. Kritische öffentliche Daten werden nicht direkt aus der Payload-Datenbank ausgeliefert. Stattdessen liest das Frontend aufbereitete Projektionen, die von Redis gestützt werden. Die Mandantenkonfiguration wird als aufbereitete Daten gecacht. Navigationskarten werden separat neu aufgebaut und gespeichert, wobei veröffentlichte und Entwurfszustände unabhängig voneinander behandelt werden. Öffentlicher Traffic liest aus dem veröffentlichten Snapshot, und die Entwurfsvorschau führt veröffentlichte und Entwurfsknoten zusammen, wenn Redakteure Änderungen vor der Veröffentlichung prüfen.

Damit rückte Payload in die richtige Rolle. Es bleibt das Redaktionssystem, in dem Inhalte modelliert, geprüft und veröffentlicht werden. Das Frontend konsumiert schnelle, stabile Daten, die für den Laufzeitbetrieb aufbereitet sind.

Eine manuelle Migration, bei jedem Schritt durch QA geprüft.

Die Migration Chinas von OCM + dem alten Build zu Payload + dem neu gebauten Frontend umfasste Tausende Seiten, Zehntausende Media-Assets und Zehntausende Weiterleitungen. Die Migration wurde manuell von einem koordinierten Migrationsteam durchgeführt. Jedes migrierte Artefakt wurde von QA und Stakeholdern gegen die alte Implementierung geprüft, um sicherzustellen, dass der volle Umfang über Inhalte, Struktur, Medien und Routing hinweg erhalten blieb.

Die manuelle Migration war eine bewusste Entscheidung für ein Asset dieser Bedeutung. Mit einem festen Termin und einer mandantenfähigen Produktivplattform auf der anderen Seite des Umschaltens hatte die Parität mit dem alten Build oberste Priorität. Die Prüfung gegen das Quellsystem gab beiden Teams die Sicherheit, dass nichts unbemerkt durchrutschte.

Die Integration des Ingersoll Rand Form Builders zeigt, wie sich das CMS in eine bestehende Enterprise-Umgebung einfügen musste. Redakteure fügen keine rohen Formular-IDs in Payload ein. Wir haben einen Bearbeitungsablauf gebaut, in dem sie die Form-Builder-Instanz auswählen, eine Gruppe wählen und dann eine veröffentlichte Vorlage auswählen, die über die externe API abgerufen wird. Auf der Frontend-Seite durchsucht die Anwendung Content-Blöcke nach Formularverweisen, ruft die Daten in Stapeln von dieser API ab und übergibt die aufgelösten Formulardaten an den Seitenadapter.

QA war durchgängig. Ein dedizierter Ingenieur arbeitete vom ersten Tag an Seite an Seite mit der Entwicklung.

Ein dedizierter QA-Engineer arbeitete während des gesamten Projekts Seite an Seite mit der Entwicklung. Eine separate UAT-Umgebung wurde vorgehalten, damit QA und Stakeholder Arbeit unter produktionsnahen Bedingungen prüfen konnten, bevor etwas ausgeliefert wurde.

Vor dem Go-live gaben QA und Stakeholder eine manuelle End-to-End-Prüfung über Inhalte, Workflow, Integrationen und migrierte Daten frei. Der Launch selbst wurde durch eine Launch-Checkliste und einen Rollback-Plan abgesichert, damit ein termingetriebenes Umschalten nicht davon abhängen musste, dass beim ersten Mal alles glattläuft.

Die Übergabe war ein eigenständiges Ergebnis.

Content-Redakteure wurden Schritt für Schritt in dedizierten Live-Workshops an das System herangeführt und gingen dabei reale Redaktionsszenarien auf der Live-Plattform durch. Diese Sessions wurden mit einer funktionsbezogenen schriftlichen Dokumentation kombiniert, auf die Redakteure später zurückgreifen können und die die Teile des CMS abdeckt, die sie täglich nutzen, darunter Seitenhierarchie, Blöcke, Publikations-Workflow, Weiterleitungen und mandantengebundene Berechtigungen.

Die Kombination aus begleiteten Sessions und Referenzdokumentation war bewusst gewählt. Live-Workshops schaffen schnell Sicherheit. Schriftliche Dokumentation erhält sie, nachdem das Projektteam abgezogen ist.