Migrera till Adobe Commerce as a Cloud Service
Adobe Commerce as a Cloud Service innehåller en omfattande guide för utvecklare som övergår från en befintlig Adobe Commerce PaaS-implementering till det nya SaaS-erbjudandet (Adobe Commerce as a Cloud Service). Adobe Commerce as a Cloud Service utgör en avsevärd förändring till en helt hanterad, versionslös SaaS-modell som erbjuder förbättrade prestanda, skalbarhet, förenklade åtgärder och tätare integrering med den bredare Adobe Experience Cloud.
Förstå skiftet - jämför PaaS och SaaS
Viktiga skillnader
- [Endast PaaS]{class="badge informative" title="Gäller endast Adobe Commerce i molnprojekt (Adobe-hanterad PaaS-infrastruktur) och lokala projekt."} PaaS (aktuell): Merchant hanterar programkod, uppgraderingar, patchering och infrastrukturkonfiguration i Adobe hostingmiljö. Delad ansvarsmodell för tjänster (MySQL, Elasticsearch med flera).
- [Endast SaaS]{class="badge positive" title="Gäller endast Adobe Commerce as a Cloud Service- och Adobe Commerce Optimizer-projekt (SaaS-infrastruktur som hanteras av Adobe)."} SaaS (ny - Adobe Commerce as a Cloud Service): Adobe hanterar alla viktiga program, infrastrukturer och uppdateringar. Handläggarna fokuserar på anpassning via utökningspunkter (API:er, App Builder, UI SDK:er). Programkoden är låst.
Arkitekturkonsekvenser
- Versionslös plattform: Kontinuerliga uppdateringar innebär att ni inte behöver uppgradera några större versioner av kärnan.
- Mikrotjänster och API-first: Större förlitan på API:er för utbyggbarhet och integrering.
- Headless (standard):: Starkt stöd för fristående butiker (till exempel Commerce Storefront från Edge Delivery Services).
- Edge Delivery Services: Påverkan på frontendens prestanda och driftsättning.
Nya verktyg och koncept
Migreringssökvägar
Adobe Commerce as a Cloud Service har stöd för flera migreringssökvägar, beroende på tidslinjen, butiken och anpassningar.
Som ett alternativ till en fullständig migrering stöder Adobe Commerce as a Cloud Service en stegvis migrering med Commerce Optimizer eller en stegvis metod.
- Inkrementell migrering - Det här tillvägagångssättet innebär att migrera data, anpassningar och integreringar stegvis. Den här metoden är idealisk för stora handlare med många anpassningar som gradvis vill övergå sina komplexa anpassningar och data till Adobe Commerce as a Cloud Service i sin egen takt.
- Commerce Optimizer - Med den här metoden kan du migrera iterativt genom att använda Commerce Optimizer som en övergångsfas för att flytta komplexa anpassningar och data till Adobe Commerce as a Cloud Service i din egen takt. Commerce Optimizer ger tillgång till Merchandising Services som drivs av Catalog Views and Policies, Commerce Storefront från Edge Delivery samt Product Visuals powered by AEM Assets.
- Fullständig migrering - Detta innebär att migrera alla data, anpassningar och integreringar samtidigt. Den här metoden är perfekt för mindre handlare med få anpassningar som snabbt vill övergå till Adobe Commerce as a Cloud Service.
I följande tabell visas en översikt över migreringsprocessen för olika butiker och konfigurationer:
Som framgår av tabellen kommer åtgärderna för varje migrering att bestå av:
- Datamigrering - Använder det tillhandahållna migreringsverktyget för att migrera data från din befintliga instans till Adobe Commerce as a Cloud Service.
- Storefront - Befintliga Commerce Storefront med Edge Delivery-teknik och headless-butiker kräver inte reducering, men Luma-butiker kräver migrering till Commerce Storefront med Edge Delivery. PWA Studio butiker kan migreras till Commerce Storefront från Edge Delivery eller underhållas i sitt nuvarande skick. Adobe kommer att tillhandahålla acceleratorer för att underlätta migrering av butiker.
- API-nät - Skapa ett nytt nät eller ändra det befintliga. Adobe kommer att tillhandahålla förkonfigurerade nät som hjälp i den här processen.
- Integrationer - Alla integreringar måste utnyttja antingen startsatsen för integrering eller Adobe Commerce as a Cloud Service REST API.
- Anpassningar - Alla anpassningar måste flyttas till App Builder och API Mesh.
- Assets Management - All resurshantering kräver migrering. Om du redan använder AEM Assets behöver du inte migrera.
- Tillägg - Alla pågående tillägg måste återskapas som obearbetade tillägg. I slutet av 2025 kommer Adobe att ge åtkomst till våra populäraste tillägg för att minimera byggtider.
Migreringsfaser
I följande faser beskrivs de steg och överväganden som krävs för att migrera till Adobe Commerce as a Cloud Service.
Utvärdering och planering före migrationen
Denna fas är viktig för att minimera riskerna och fastställa en tydlig migreringsväg och identifiera problem innan de uppstår.
Identifiering och granskning av den aktuella miljön
Kodbasanalys:
- Identifiera alla anpassade moduler, teman och åsidosättningar.
- Analysera ändringar av kärnkoden och se vilka som behöver omfaktoriseras som en del av migreringen.
- Utvärdera tillägg från tredje part och fastställa kompatibilitet med Adobe Commerce as a Cloud Service. Finns det SaaS-kompatibla alternativ, eller behöver du skapa anpassade API-integreringar för App Builder-program?
- Identifiera kod eller funktioner som inte kommer att migreras.
Datakontroll:
- Utvärdera databasens storlek och komplexitet.
- Identifiera oanvända data eller tabeller för rensning.
- Granska befintliga import-/exportprocesser.
Integrationsgranskning:
- Lista alla externa system som är integrerade med Adobe Commerce (ERP, CRM, PIM, betalningsgateways, rederier, OMS och alla andra system).
- Utvärdera integreringsmetoder (API, egna skript och andra metoder).
- Utvärdera kompatibiliteten med Adobe Commerce as a Cloud Services API:er först och App Builder.
Prestandatester:
- Dokumentera de aktuella poängen för Lighthuse, sidinläsningstider och nyckeltal (KPI), som är en baslinje för att mäta förbättringar efter migrering.
Granskning av säkerhetskonfiguration:
- Utvärdera eventuella anpassade WAF-regler, IP-tillåtelselista och andra säkerhetskonfigurationer.
Definiera migreringsomfång och -strategi:
-
Avfasad och migrering från en gång till en: Utvärdera för- och nackdelar för varje tillvägagångssätt.
-
Identifiera viktiga affärsprocesser: Prioritera funktioner som måste migreras först, till exempel:
- Komplexa prisregler
- Anpassade affärsregler som tillämpas innan en order officiellt läggs eller bearbetas
- Komplexa skatteberäkningar
- Adressvalideringar
- Anpassad logik som utlöses efter att en order har placerats
-
Headless vs. monolitisk storefront: Beslutspunkt för ny storefront-utveckling eller anpassning av befintliga storefront.
-
Integrationsstrategi: Avgör hur befintliga integreringar omformas (API-nät, App Builder, direkt API).
-
Datamigreringsstrategi: Kontrollera om du tänker migrera med fullständiga historiska data, partiella data eller inga migrerade data.
Teamberedskap och utbildning:
- Bekanta dig med Adobe Commerce as a Cloud Service koncept, utvecklingsarbetsflöden och nya verktyg.
- Delta i praktisk utbildning med Adobe App Builder, Edge Delivery Services och Adobe Commerce as a Cloud Service-distributionskanaler.
Miljöinställningar och etablering:
- Etablera din Adobe Commerce as a Cloud Service-sandlåda och dina utvecklingsmiljöer med Commerce Cloud Manager.
Inkrementella migreringsfaser
Strategisk omfaktorisering och externalisering
Den här fasen består av kärnan i migreringen, med fokus på att anpassa kodbasen till det Adobe Commerce as a Cloud Service-molnbaserade paradigmet. Detta innebär att strategiskt implementera nya Adobe-tjänster och flytta bort anpassad logik från Commerce kärnplattform.
1. Migrera"pågående" anpassningar och tillägg till App Builder
Detta är en avgörande fas för att uppnå en"låst kärna" och framtidssäkra din lösning, som är central för arkitekturfilosofin i Adobe Commerce as a Cloud Service.
- Gör komplex logik externt till App Builder: Analysera befintliga anpassade moduler och tillägg från tredje part i din PaaS-kodbas. För komplex affärslogik, skräddarsydda integreringar eller mikrotjänster som inte kräver direkt bearbetning av Commerce-datorns kärndatamodell kan de omfaktoriseras och användas på nytt som serverlösa program i Adobe Developer App Builder.
- Utnyttja API-nät: För scenarier som kräver data från flera backend-system (t.ex. din Commerce-backend, ERP, CRM och anpassade App Builder-mikrotjänster) ska du implementera ett API-nätlager i App Builder. Detta konsoliderar olika API:er till en enda, högpresterande GraphQL-slutpunkt som används av din nya butik eller andra tjänster, vilket förenklar komplex datainhämtning.
- Händelsedriven arkitektur: Använd Adobe I/O Events för att utlösa App Builder-åtgärder baserat på händelser i din PaaS-instans (t.ex. produktuppdateringar, kundregistreringar, orderstatusändringar) eller andra anslutna system. Detta främjar asynkron kommunikation, minskar åtkopplingen och förbättrar systemets motståndskraft.
Fördelar: Detta steg minskar avsevärt den tekniska skuld som förknippas med djupt inbäddade anpassningar, snabbar upp övergången av din Commerce-instans till Adobe Commerce as a Cloud Service , förbättrar skalbarheten och den oberoende driftsättningen av anpassad logik samt främjar snabbare utvecklingscykler för tillägg.
2. Adobe SaaS-baserade marknadsföringstjänster från Adobe Commerce och integrering av katalogdata
Detta är en viktig inledande integrationspunkt med två alternativ för katalogdatahantering:
Utnyttja den befintliga SaaS-tjänsten för katalog som är integrerad med PaaS-serverdelen
Det här alternativet är ett övergångssteg som bygger på en befintlig integrering där din PaaS-server fyller i en befintlig instans av Adobe Commerce SaaS-tjänsten med data från katalogtjänsten, direktsökning och produktrekommendationer.
- Synkronisering av katalogdata: Se till att din Adobe Commerce CatalogS-instans fortsätter att synkronisera produkt- och katalogdata med din befintliga Adobe Commerce Catalog SaaS-tjänst. Detta är vanligtvis beroende av etablerade anslutningar eller moduler i din PaaS-instans. Catalog SaaS-tjänsten är fortfarande den auktoritativa källan för sök- och säljfunktioner och hämtar data från din PaaS-server.
- API-nät för optimering: Medan den headless storefront (på Edge Delivery Services) och andra tjänster direkt kan hämta data från Catalog SaaS-tjänsten rekommenderar Adobe att du använder API Mesh (i App Builder). API Mesh kan kombinera API:er från Catalog SaaS-tjänsten med andra nödvändiga API:er från din PaaS-backend (t.ex. inventeringskontroller i realtid från transaktionsdatabasen eller anpassade produktattribut som inte helt replikerats till Catalog SaaS-tjänsten) till en enda högpresterande GraphQL-slutpunkt. Detta möjliggör även centraliserad cachelagring, autentisering och svarsomvandling.
- Integrera Live Search och produktrekommendationer: Konfigurera SaaS-tjänster för Live Search och Product Recommendations så att de importerar katalogdata direkt från din befintliga SaaS-tjänst för Adobe Commerce Catalog, som i sin tur fylls i av din AppaS-serverdel.
Fördelar: Detta ger en snabbare väg till en headless storefront och avancerade SaaS-funktioner genom att utnyttja en befintlig och operativ Catalog SaaS-tjänst och dess integrationsflöde med din PaaS-backend. Den behåller emellertid beroendet av PaaS-serverdelen för den primära katalogdatakällan och tillhandahåller inte de sammanställningsfunktioner för flera källor som är inbyggda i den nya sammanställningsbara katalogdatamodellen. Det här alternativet är en giltig språngbräda mot en mer heltäckande sammansättningsbar arkitektur.
Använd den nya CCDM-modellen (Composable Catalog Data Model)
Detta är den strategiska, framtidssäkra lösningen för att utnyttja Adobe Commerce Optimizer. CCDM erbjuder en flexibel, skalbar och enhetlig katalogtjänst som är utformad för datagenerering från flera källor och dynamisk marknadsföring.
-
Intag och enhetlighet av data
-
Börja med att importera produkt- och katalogdata från din befintliga Adobe Commerce PaaS-instans (och/eller andra PIM/ERP-system) till den nya Composable Catalog Data Model (CCDM).
-
Koppla befintliga produktattribut till CCDM:s flexibla schema. Prioritera viktiga produktdata för första intaget.
-
Skapa robusta dataledningar för kontinuerlig synkronisering. Detta kan omfatta:
- Händelsestyrd (via App Builder): Använd Adobe I/O Events från din PaaS-instans för att aktivera offentligt tillgängliga eller anpassade Adobe App Builder-program. Dessa program omvandlar och skickar dataändringar (skapa, uppdatera och ta bort) till CCDM via dess API:er.
- Gruppinmatning: För stora initiala inläsningar eller periodiska massuppdateringar använder du säkra filöverföringar (till exempel CSV eller JSON) till ett mellanlagringsområde som bearbetas av Adobe Experience Platform (AEP) ingetjänster till CCDM.
- Direkt API-integrering (med App Builder orchestration): För mer komplexa scenarier kan App Builder fungera som ett orkestreringslager, göra direkta API-anrop till din PaaS-backend, omforma data och överföra dem till CCDM.
-
-
Katalogvy och principdefinition: Konfigurera katalogvyer (logiska grupperingar för unik katalogpresentation, t.ex. butiksvyer, regioner och B2B/B2C-segment) och definiera principer (regeluppsättningar för produktpresentation, filtrering och varuexponering) inom CCDM. Detta ger dynamisk kontroll över produktsortiment och visningslogik per katalogvy.
-
Integrera Live Search och produktrekommendationer: När katalogdata finns i CCDM kan du integrera Adobe SaaS-baserade Live Search- och Product Recommendations-tjänster. Dessa utnyttjar Adobe AI AI och maskininlärningsmodeller för överlägsen sökrelevans och personaliserade rekommendationer, och använder data direkt från CCDM.
Fördelar: Genom att abstrahera kataloghantering och identifiering i CCDM och tillhörande SaaS-tjänster får du bättre prestanda, AI-driven marknadsföring, avlastning av läsåtgärder från den gamla backend-funktionen och en stabil avskalning av den ledande funnel-upplevelsen.
3. Bygg upp din butik på Edge Delivery Services
När man har etablerat och anpassat data och anpassat dem externt blir fokus på att bygga upp en högpresterande frontlinje.
-
Inledande konfiguration: Konfigurera projektet med Adobe Commerce Storefront-mallen för Edge Delivery Services. Detta utgör en grundläggande, headless front som bygger på modern webbteknik.
-
Anslut till katalogtjänster och API-nät: Commerce Storefront använder data främst via GraphQL API
- Alternativ 1: Från den befintliga Catalog SaaS-tjänsten (via API Mesh) för produktinformation och försäljningsregler.
- Alternativ 2: Från CCDM för produktinformation och försäljningsregler.
- Från API Mesh för alla orkestrerade data från din gamla backend-server (PaaS-instans) eller anpassade App Builder-tjänster (t.ex. realtidslager, anpassade produktattribut och lojalitetspunkter).
-
Innehållsmigrering (AEM Services): Migrera befintligt statiskt innehåll (till exempel"Om oss"-sidor, blogginlägg och marknadsföringsbanners) till AEM Services, som ligger till grund för Commerce Storefront. Utnyttja AEM funktioner för framtagning av material och se till att materialet är optimerat för Edge Delivery Services.
-
Utveckla viktiga gränssnittskomponenter: Bygg upp viktiga användargränssnittskomponenter för produktinformationssidor (PDP), produktlistsidor (PLP) och sidor med allmänt innehåll med Edge Delivery Services komponenter för insticksprogram och anpassade React/Vue-komponenter. Prioritera centrala handelsflöden.
-
Integrering med befintlig kundvagn/utcheckning: Till att börja med kommer Edge Delivery Services storefront att skapa en leverans till din befintliga Adobe Commerce PaaS (eller någon annan tredjepartsplattform) för kundvagn och kassa. Detta innebär vanligtvis följande:
- Omdirigering: Användaren omdirigeras till den gamla plattformens inbyggda kundvagn- och utchecknings-URL:er och nödvändiga sessions- och kundvagnsidentifierare skickas.
- Direkt API-interaktion (med App Builder orchestration): Skapa anpassade kundvagn- och kassakomponenter i Edge Delivery Services som interagerar direkt med kundvagns- och kassan-API:er. Detta inbegriper ofta App Builder som en BFF (Backend-for-Front end) för att samordna samtal till flera backend-tjänster (till exempel PaaS-kundvagn, betalningsgateways och leveransräknare).
Fördelar: En blixtsnabb, SEO-optimerad och mycket flexibel butiksupplevelse. Denna fas bidrar direkt till en överlägsen kundupplevelse och lägger grunden till framtida innovation.
4. Datamigrering (stegvis process)
Datamigrering är en kritisk och mångfacetterad process som körs samtidigt med omfaktorisering och utveckling av butiker, vilket ger enhetlighet och integritet.
- Rensa och optimera befintliga data: Före en storskalig migrering kan du utföra omfattande datarensning, borttagning av dubbletter och validering i din befintliga PaaS-databas. Detta proaktiva steg är avgörande för att minimera överföringen av gamla dataproblem och säkerställa kvaliteten på data i den nya miljön.
Massdatamigreringar
Migrering av massdata innebär att du måste ta en fullständig datdump från Adobe Commerce PaaS-instansen, omvandla hela datauppsättningen och importera den till Adobe Commerce as a Cloud Service på en gång. Den här metoden används vanligtvis för den initiala datapifieringen.
-
Verktygstillgänglighet: Dedikerat verktyg för massdatamigrering för kundbruk för Commerce massdatamigrering kommer att vara tillgängligt på begäran under första kvartalet 2026. Om kunderna behöver hjälp med att migrera data satsvis på förhand kan Adobe på deras vägnar underlätta dataöverföringen.
-
Process:
- Fullständig dataexport: Extrahera en komplett datauppsättning från din Adobe Commerce PaaS-instans (till exempel produkter, kategorier, kundkonton, historiska orderdata, statiska block och sidinnehåll).
- Datatransformering: Använd nödvändiga omformningar för att anpassa extraherade data till schemakraven för de nya komponenterna i Adobe Commerce as a Cloud Service, inklusive Composable Catalog Data Model (CCDM) om den används, samt andra relevanta Adobe-tjänster eller databaser. Detta kan omfatta anpassade skript eller specialiserade datamappningsverktyg.
- Inledande import: Importera den omformade fullständiga datauppsättningen till respektive komponenter i Adobe Commerce as a Cloud Service. För produkt- och kategoridata fylls den valda katalogtjänsten (CCDM eller befintliga katalog-SaaS) i. För kund- och orderdata fylls transaktionsbackend-tjänster eller tillhörande tjänster i.
- Validering: Validera importerade data noggrant för att säkerställa fullständighet, exakthet och enhetlighet i alla nya system.
Interaktiv datamigrering
Interaktiv datamigrering fokuserar på synkronisering av inkrementella ändringar och borttagningar från källinstansen av PaaS till de nya Cloud Service-komponenterna, vilket säkerställer att data uppdateras fram till och efter avslutningen.
-
Verktygstillgänglighet: Verktyg som särskilt utformats för iterativ datamigrering kommer att vara tillgängliga under 2026.
-
Process:
- Deltaidentifiering: Upprätta mekanismer för att identifiera ändringar (skapande, uppdateringar och borttagningar) i viktiga datauppsättningar i din PaaS-miljö sedan den senaste synkroniseringen. Detta kan omfatta registrering av ändringsdata (CDC), tidsstämpeljämförelser eller händelsebaserade utlösare.
- Kontinuerlig synkronisering: Implementera robusta mekanismer för kontinuerlig, inkrementell datasynkronisering från din PaaS-miljö till de nya Cloud Service-komponenterna (till exempel CCDM och transaktionell serverdel). Detta är avgörande för att upprätthålla datans aktualitet och minimera driftstoppen under en övergång.
- Utnyttjar händelser: Använd Adobe I/O Events där det är möjligt för att aktivera App Builder-åtgärder för uppdateringar i realtid eller nästan i realtid från din PaaS-instans till de nya tjänsterna. En produktuppdatering i PaaS kan till exempel utlösa en händelse som uppdaterar motsvarande post i CCDM.
- API-drivna uppdateringar: För data som inte är händelsestyrda använder du schemalagda API-anrop (via App Builder eller andra integreringsplattformar) för att hämta ändringar från PaaS och överföra dem till de nya systemen.
- Felhantering och övervakning: Implementera robust felhantering, loggning och övervakning för alla iterativa dataledningar för att säkerställa dataintegriteten under hela processen.
Eftermigrering och pågående verksamhet
DNS-reducering och live:
- Planera noggrant DNS-brytningen med minimala driftavbrott.
- Övervaka webbplatsens hälsa och prestanda direkt efter lanseringen.
Åtgärder efter start:
Demonstrerar PaaS-miljön:
- Arkivera eller ta bort gamla PaaS-instanser och data säkert efter valideringsperioden.
Pågående utvecklingsarbetsflöde:
- Använd den versionslösa typen av Adobe Commerce as a Cloud Service, som har kontinuerliga små distributioner i stället för stora uppgraderingar.
- Använd Cloud Manager för att hantera miljöer och driftsättningar.
- Utnyttja App Builder för utökad funktionalitet utan att påverka kärnan.
Övervakning, prestanda och säkerhet:
- Övervaka webbplatsens prestanda, fel och säkerhetsloggar kontinuerligt.
- Utnyttja Adobe inbyggda säkerhetsfunktioner och följ vedertagna standarder.
Utbildning och dokumentation:
- Utbilda nya utvecklare och affärsanvändare på Adobe Commerce as a Cloud Service-plattformen och i arbetsflödena.
- Underhåll uppdaterad intern dokumentation för anpassade integreringar och processer.