Von Site Genesis zu SFRA oder PWA Kit
Die Migration von Site Genesis zu SFRA oder weiter zu einem PWA-Kit-basierten Storefront wird in den meisten Projektplänen als technisches Vorhaben behandelt: neue Templates, neue Architektur, neue Frontend-Technologie. Was dabei regelmäßig unterschätzt wird, ist der Content selbst – und genau das wird oft zum größten Zeitfresser im Projekt.
Kernaussage: Eine Plattform-Migration ohne durchdachte Content-Strategie verwandelt ein technisches Upgrade in ein Content-Migrationsprojekt mit ungeplantem Umfang. Wer Content von Anfang an mitplant, hält den Zeitplan ein.
Warum Content bei Plattform-Migrationen zum Risiko wird
- Content ist oft eng an alte Templates gekoppelt: Individuell im Code verankerte Inhalte lassen sich nicht automatisch in eine neue Architektur übernehmen
- Fehlende Content-Inventur: Ohne Überblick, welcher Content überhaupt aktiv genutzt wird, migrieren Teams oft mehr (oder weniger) als nötig
- Unterschätzter Umfang bei internationalen Shops: Jede zusätzliche Sprache und jeder zusätzliche Markt vervielfacht den Migrationsaufwand für gekoppelten Content
- Parallelbetrieb erforderlich: Während der Migration muss der bestehende Shop weiterlaufen – Content-Änderungen im Altsystem drohen bei der Migration verloren zu gehen
Wie sich Content-Risiken bei der Migration reduzieren lassen
Content-Inventur vor der technischen Planung
Bevor die technische Migration beginnt, sollte feststehen, welcher Content tatsächlich aktiv ist, welcher veraltet ist (siehe auch Content Debt abbauen) und welcher gar nicht erst mit übernommen werden muss. Das reduziert den Migrationsumfang oft erheblich.
Content-Entkopplung von der Storefront-Architektur
Liegt Content bereits in einem CMS, das unabhängig von der Storefront-Codebasis funktioniert, betrifft eine Frontend-Migration die Content-Ebene kaum – die Inhalte lassen sich unverändert an die neue Architektur andocken. Ist Content dagegen im Template-Code verankert, wird die Migration selbst zum Content-Projekt.
Schrittweise statt vollständige Migration
Content lässt sich häufig schrittweise migrieren – zuerst neue, aktive Kampagnen auf der neuen Architektur, dann historischer Content nach Priorität. Das vermeidet einen harten Cut-over-Zeitpunkt, an dem alles gleichzeitig funktionieren muss.
Freigabe- und Testphase mit echten Redakteuren
Vor dem vollständigen Umstieg sollten Content-Teams selbst in der neuen Umgebung arbeiten und Freigabe-Workflows testen – nicht nur Entwickler und Projektmanager.
Warum ein plattformunabhängiges CMS die Migration erheblich vereinfacht
Der entscheidende strukturelle Vorteil eines CMS, das von der Storefront-Codebasis entkoppelt ist: Eine Migration von Site Genesis über SFRA zu einem PWA-Kit-Storefront betrifft primär die Präsentationsschicht – nicht den Content selbst. Inhalte, Freigabe-Workflows und Übersetzungen bleiben unverändert nutzbar, während sich die technische Architektur darunter weiterentwickelt.
Zum grundsätzlichen Zeitrahmen einer CMS-Implementierung siehe CMS-Einführung für Salesforce Commerce Cloud. Zur Frage, wie sich Content-Rollback als Sicherheitsnetz während der Übergangsphase nutzen lässt, siehe Content-Rollback und Disaster Recovery.
Aus der Praxis: MOMENTVM-Kunden, die von Site Genesis oder SFRA zu einer neuen Storefront-Architektur migrieren, behalten ihren gesamten Content, ihre Freigabe-Workflows und Übersetzungen unverändert bei – weil diese von der Storefront-Codebasis vollständig entkoppelt sind.
Fazit
Plattform-Migrationen auf SFCC scheitern selten an der Technik allein – häufiger an unterschätztem Content-Aufwand. Wer Content-Inventur, Entkopplung von der Architektur und schrittweise Migration von Anfang an einplant, vermeidet den größten versteckten Zeitfresser im Projekt.
Häufig gestellte Fragen
Betrifft eine Storefront-Migration automatisch auch den Content?
Nur, wenn Content technisch an die alte Template-Architektur gekoppelt ist. Ist er davon entkoppelt, betrifft die Migration primär die Präsentationsschicht, nicht die Inhalte selbst.
Was ist der häufigste Grund für Zeitverzug bei SFCC-Migrationen?
Unterschätzter Content-Migrationsaufwand – nicht die technische Frontend-Umstellung selbst – ist in der Praxis der häufigste versteckte Zeitfresser im Projekt.
Sollte Content vor oder während der technischen Migration inventarisiert werden?
Vor der technischen Planung. Eine Content-Inventur zeigt, welche Inhalte aktiv genutzt werden, welche veraltet sind und welche gar nicht migriert werden müssen.
Lässt sich die Migration schrittweise statt auf einmal durchführen?
Ja, und das ist meist die risikoärmere Variante – neue, aktive Kampagnen zuerst auf die neue Architektur, historischer Content nach Priorität, statt eines harten Cut-over-Zeitpunkts.