Von Aura zu LWR: einen B2B-Commerce-Store migrieren

Stellen Sie einen Aura-B2B-Store auf LWR um, wenn Sie Funktionen oder Änderungen brauchen, die in Aura schwer zu bauen sind, oder wenn eigener Aura-Code immer weiter wächst. Eine Frist gibt es nicht: Bis zum 27. Oktober 2026 hat Salesforce kein Abschaltdatum für Aura-Stores veröffentlicht. Salesforce empfiehlt das LWR-Template für neue Stores und bietet für bestehende einen Migrationsleitfaden1, aber kein Migrationswerkzeug. Sie legen einen neuen Store aus dem Template B2B Commerce (LWR) an und ziehen Komponenten, Checkout und Konfiguration um. Ich plane das als Neubau der Storefront auf denselben Commerce-Daten und fange im laufenden Aura-Store an.

Welchen Store betreiben Sie, und gibt es eine Frist?

Salesforce B2B Commerce, das Salesforce inzwischen auch als “Agentforce Commerce for B2B” vermarktet, gab es in drei Generationen: als Managed Package auf Visualforce, als Store auf der Kernplattform mit dem Aura-Template und als Store mit dem LWR-Template (Lightning Web Runtime). Wie Sie die Generationen unterscheiden, steht in B2B Commerce Versionen: Visualforce, Aura oder LWR?.

Laut Migrationsleitfaden2 können nur Orgs, die vor Spring ’23 für Commerce aktiviert wurden, noch das Aura-Template wählen. Salesforce empfiehlt für neue Stores das B2B-LWR-Template und legt bestehenden Aura-Stores nahe, eine Migration zu prüfen.

Ein Abschaltdatum gibt es nicht. Aura-Stores stehen nicht auf der Liste der aktiven Abkündigungen3, und der Leitfaden nennt keines. Die Liste sagt selbst, dass nicht aufgeführte Abkündigungen über Release Notes, Hilfeartikel oder gezielte E-Mails kommen. Lesen Sie also die Release Notes dreimal im Jahr mit. Bis dahin entscheiden Sie nach Funktionen und Aufwand, nicht aus Angst vor einem Datum, das niemand angekündigt hat.

Ein LWR-Store kennt nur Lightning Web Components

Die wichtigsten Unterschiede4 sind schnell aufgezählt, aber jeder betrifft eigenen Code:

Bereich	Aura-Store	LWR-Store
Komponenten	Aura-Komponenten und Lightning Web Components	Nur Lightning Web Components
Styling	Eigene CSS-Klassen	--dxp-Styling-Hooks, verknüpft mit dem Theme-Panel
Datenzugriff	force:recordData, lightning:recordForm	Wire-Service auf Lightning Data Service
Checkout	Checkout-Flows in Flow Builder	Salesforce Commerce Checkout, angeordnet in Experience Builder
Warenkorbseite	Record Page	Named Page

Zwei Zeilen verdienen Aufmerksamkeit. Die erste ist der Checkout. Für Aura-Stores schreibt Salesforce, dass Sie Checkout-Flows mit Flow Builder bauen5. LWR-Stores nutzen den Salesforce Commerce Checkout, der mit dem Store installiert wird. Dessen Integrationen für Versand, Steuern und Zahlung laufen getrennt von den Aura-Subflows, und für eigene Logik empfiehlt Salesforce Extensions statt Integrationen6. Wenn Ihr Aura-Checkout einen Subflow hat, der das ERP für eine Kreditprüfung aufruft, muss diese Logik neu gebaut werden. Wie Extensions funktionieren, steht in Commerce Extensions: Eigenentwicklung, die Updates übersteht.

Die zweite ist die Warenkorbseite. Sie ist keine Record Page mehr, sondern eine Named Page. Jede Komponente, die mit lightning/navigation zum Warenkorb navigiert oder einen Link dorthin baut, muss angepasst werden, so steht es auf der Seite Migrate Your Store7 des Leitfadens.

Erst im Aura-Store vorbereiten, dann wechseln

Der Leitfaden trennt die Vorbereitung im Aura-Store vom Wechsel auf einen neuen LWR-Store. Ich halte mich an diese Trennung, weil die Vorbereitung laufen kann, während Händler weiter bestellen.

Vorbereitung im laufenden Aura-Store (Prepare for Store Migration8):

1. Bestand aufnehmen. Suchen Sie im Setup nach Lightning Components, um alle Aura-Komponenten und Lightning Web Components zu sehen.
2. Aura-Komponenten ersetzen. Lightning Web Components laufen in Aura- und LWR-Stores, oft ohne Änderung. Aura-Komponenten können Lightning Web Components enthalten, aber nicht umgekehrt, also stellen Sie zuerst die inneren Komponenten um. Lässt sich eine Aura-Komponente noch nicht ersetzen, reduzieren Sie sie auf eine dünne Hülle. Am Ende müssen alle Aura-Komponenten weg.

Für Entwickler

Wie baue ich Datenzugriff und Events für LWR um?

• Datenzugriffe nach oben ziehen. Halten Sie Datenoperationen in der äußersten Komponente. Dann ändert sich die Datenschicht an einer Stelle, und innere Komponenten bleiben wiederverwendbar.
• Events umbauen. Aura-Events, deklariert mit aura:event, werden in Lightning Web Components zu DOM-Events.
• Wire-Adapter nutzen. Ersetzen Sie force:recordData durch @wire und Adapter aus den Namespaces lightning/ui*Api und Commerce. Apex-Methoden, die Sie behalten wollen, lassen sich in Lightning Web Components importieren.

Der Wechsel:

1. 01

   Store anlegen

   Im Setup einen Store aus dem Template B2B Commerce (LWR) anlegen. Laut Leitfaden ist ein neues Template nötig, um die Migration abzuschließen (Create a Store with the LWR Template (öffnet in einem neuen Tab)).

2. 02

   Umbau abschließen

   Komponenten in ein SFDX-Projekt legen, den Umbau abschließen, die Navigation zum Warenkorb anpassen und das Branding auf Styling-Hooks übertragen.

3. 03

   Konfiguration übertragen

   Die Store-Konfiguration per Change Set vom alten in den neuen Store übertragen.

4. 04

   Veröffentlichen

   Deployen, Komponenten in Experience Builder platzieren, Vorschau auf Desktop und Mobilgerät prüfen, veröffentlichen.

Salesforce schreibt, dass Sie den Store nicht von Grund auf neu bauen müssen und die Migration vor allem Umbau ist. Für die Commerce-Daten stimmt das. Für die Storefront würde ich mich nicht darauf verlassen: neue Site, neues Styling, neuer Checkout und neue Warenkorbseite ergeben zusammen einen Neubau von allem, was der Käufer sieht. Ich schätze und teste es auch so.

Was lässt der Leitfaden offen?

Der Leitfaden behandelt Komponenten und Store-Konfiguration. Zu Katalog, Buyer Groups, Entitlement Policies und Preisbüchern sagt er nichts, ebenso wenig zu URLs und Lesezeichen der Händler. Planen Sie ausdrücklich, wie der neue Store an die bestehenden Buyer Groups und Preisbücher angebunden wird, und testen Sie das mit echten Käuferkonten, bevor ein Händler den Store sieht.

Experience-Metadaten lassen sich in einer Pipeline besser führen als mit Change Sets. Salesforce beschreibt das Deployment von Store-Metadaten9 mit der Salesforce CLI und den Typen ExperienceBundle oder DigitalExperienceBundle, versioniert in Git. Dieselbe Seite warnt, dass manche Einstellungen nicht in den Metadaten stecken und von Hand nachgezogen werden müssen, und nennt Domains, URLs und Single Sign-on als Aufgaben nach dem Deployment. Schreiben Sie diese Einstellungen vor dem Wechsel auf. Wo Store-Konfiguration in einer Pipeline hingehört, beschreibt das DevOps-Kapitel Daten und Konfiguration.

Wann lohnt sich der Umstieg?

Ich würde die Migration planen, wenn mindestens einer dieser Punkte zutrifft:

• Eine Funktion, die Sie brauchen, fehlt im Aura-Store oder ist dort schwer zu bauen. Die Ankündigungen von Salesforce aus 2026, etwa B2B Search, der Buyer Agent, Headless Commerce und Bestellvorlagen, sagen nicht, welches Store-Template sie voraussetzen. Prüfen Sie das für jede Funktion in Release Notes und Dokumentation, bevor Sie die Migration damit begründen.
• Eigener Aura-Code wächst weiter. Jede neue Aura-Komponente ist Code, den Sie später neu schreiben.
• Der Checkout muss ohnehin geändert werden. Eine neue ERP-Schnittstelle oder eine neue Zahlart ist ein guter Anlass, den Checkout auf LWR mit Extensions neu zu bauen, statt einen Flow zu erweitern.
• Der Partner, der den Store gebaut hat, geht. Ein neuer Partner sollte nicht erst Aura lernen müssen.

Läuft der Store stabil, mit wenig eigenem Code und ohne geplante Änderungen, ist Abwarten eine legitime Entscheidung. Die Vorbereitungsschritte lohnen sich trotzdem, weil Lightning Web Components in beiden Stores laufen.

Rechenbeispiel: Ein Maschinenbauer betreibt seit 2021 einen Aura-Store mit rund 30 eigenen Komponenten und einem Checkout-Flow mit Kreditprüfung im ERP. Im ersten Quartal ersetzt das Team die inneren Komponenten im Aura-Store durch Lightning Web Components und liefert sie mit den normalen Releases aus. Im zweiten Quartal baut es den LWR-Store in einer Sandbox auf, setzt die Kreditprüfung als PlaceOrder-Extension neu um und überträgt das Styling ins Theme-Panel. Dann wechselt eine Pilot-Buyer-Group in den neuen Store, der alte bleibt zwei Wochen als Rückfallebene online, und die übrigen Gruppen folgen, wie in B2B-Shop für Händler einführen beschrieben.

Aura-Komponenten und Checkout-Subflows auflisten

Beginnen Sie mit der Bestandsaufnahme: alle Aura-Komponenten, der Checkout-Flow mit seinen Subflows und jede Stelle, die auf den Warenkorb verlinkt. Entscheiden Sie dann, welche Komponenten Sie in den nächsten zwei Releases im Aura-Store ersetzen. Den Wechsel selbst planen Sie in Ihren Release-Kalender ein, mit Regressionstests für Suche, Warenkorb und Checkout, denn drei Salesforce-Releases im Jahr treffen den alten und den neuen Store. Die übrigen Themen dieses Kapitels, von Agenten bis zur Einführung, stehen im Masterclass-Kapitel Agenten, Migration, Einführung.

Quellen9

1. 1Migrationsleitfaden (öffnet in einem neuen Tab)developer.salesforce.com
2. 2Migrationsleitfaden (öffnet in einem neuen Tab)developer.salesforce.com
3. 3Liste der aktiven Abkündigungen (öffnet in einem neuen Tab)help.salesforce.com
4. 4wichtigsten Unterschiede (öffnet in einem neuen Tab)developer.salesforce.com
5. 5Checkout-Flows mit Flow Builder bauen (öffnet in einem neuen Tab)developer.salesforce.com
6. 6Extensions statt Integrationen (öffnet in einem neuen Tab)developer.salesforce.com
7. 7Migrate Your Store (öffnet in einem neuen Tab)developer.salesforce.com
8. 8Prepare for Store Migration (öffnet in einem neuen Tab)developer.salesforce.com
9. 9Deployment von Store-Metadaten (öffnet in einem neuen Tab)developer.salesforce.com