# Adobe Commerce to ACCS Migration: Four Essential Workstreams Moving to Adobe Commerce as a Cloud Service (ACCS) is a full [platform re-architecture](https://www.krishtechnolabs.com/replatforming/), not a version upgrade and not a lift-and-shift migration. Adobe manages the core application, infrastructure, and patching entirely. All custom logic moves outside that core through App Builder and API Mesh. For merchants running [Adobe Commerce](https://www.krishtechnolabs.com/adobe-commerce-partner/) for several years, almost nothing inside the current core transfers unchanged. Teams that start scoping by asking "how long will this take" before they know what survives the move consistently discover the harder question at the worst possible moment in the project. ## Why Merchants Are Moving to ACCS The business case is about engineering capacity after the migration, not features on day one. Merchants who complete the move report consistent shifts: * **Upgrade cycles stop existing as projects.** Adobe applies updates continuously and teams validate in sandbox before production — eliminating upgrade projects entirely. * [**Product Recommendations**](https://www.krishtechnolabs.com/intelligent-recommendation-engine/) **and Live Search become bundled.** On PaaS these cost separate SKUs and integration effort. On ACCS they ship with the platform, changing the build-versus-buy math for teams running [PIM](https://www.krishtechnolabs.com/product-information-management/) and catalog operations. * **Infrastructure planning leaves the team's agenda.** Peak-traffic scaling becomes Adobe's responsibility rather than a capacity exercise before every sale event. * [**Adobe Experience Cloud**](https://www.krishtechnolabs.com/adobe-experience-cloud-partner/) **connections become native.** ACCS shares a data foundation with [AEM Assets](https://www.krishtechnolabs.com/adobe-experience-manager/), [Adobe Analytics](https://www.krishtechnolabs.com/adobe-analytics-services/), and [Adobe Target](https://www.krishtechnolabs.com/adobe-target-services/) without additional connector work. The migration itself is not cheaper. What changes is what engineering effort produces once the project closes. ## What Actually Changes When You Move to ACCS ### Adobe Owns the Core and That Changes Everything Downstream Adobe owns CDN, WAF, availability, scaling, and patching. No deployment pipeline exists for touching core application code. That single constraint reshapes every other architectural decision. Extensibility moves outside the core but splits by function. Server-side business logic becomes App Builder actions or webhooks. Data transformation and response shaping across sources belongs in API Mesh, not App Builder. Conflating the two consistently generates rework once build starts. ### Every Luma Storefront Requires a Complete Rebuild Luma does not exist on ACCS. Every Luma storefront and most customized themes sitting on top of it must be rebuilt on Commerce Storefront powered by Edge Delivery Services (EDS), or replaced with a [headless build](https://www.krishtechnolabs.com/headless-commerce/) on Next.js or similar using GraphQL. Luma's PHP templates, LESS stylesheets, and layout XML have no migration path. Treating it as a rebuild from the start, not a template migration, is what keeps timelines realistic. EDS storefronts built correctly show 40 to 60 percent improvements in Core Web Vitals over Luma. ### Bundled Merchandising Still Requires Setup Live Search, [Product Recommendations](https://www.krishtechnolabs.com/intelligent-recommendation-engine/), and Catalog Service ship with ACCS, a real cost saving over PaaS. [B2B](https://www.krishtechnolabs.com/b2b-wholesale-commerce-solutions/) features including company accounts, shared catalogs, and purchase orders are included but require entitlement assignment in Admin Console. The bundled license does not configure itself, storefront eventing for behavioral ranking and event collection needs separate setup. ## Four Workstreams That Run in Parallel, Not in Sequence Every ACCS migration involves four workstreams that must run simultaneously. Treating them as sequential is the most expensive planning mistake teams consistently make. ### Workstream 1: Data Migration Adobe's Bulk Data Migration Tool covers products, categories, customers, orders, and CMS content. It requires a support ticket and sits in controlled availability, requesting access late loses weeks unnecessarily. The tool does not handle custom database tables, third-party extension data, or non-standard schemas. Those require separate [data migration](https://www.krishtechnolabs.com/data-migration-services/) work scoped during assessment. Store settings, payment methods, shipping rules, tax configuration, and email templates all require manual recreation in ACCS Admin, none migrate automatically. Documenting the full current configuration before work starts prevents avoidable UAT gaps. ### Workstream 2: Storefront Rebuild on Edge Delivery Services This workstream carries the longest lead time and consistently gets scoped too late. EDS runs on a document-based block-component model with no equivalent in Luma's PHP templates. Treating it as a new build using existing UX requirements as input, rather than a migration of current templates, keeps timelines grounded. Adobe's EDS boilerplate covers PDP, PLP, search, cart, and checkout, shortening the build without eliminating it. Whether the storefront connects to ACCS through GraphQL directly or through an API Mesh layer is a decision worth making early since it shapes the integration architecture for everything that follows. ### Workstream 3: Customization Re-Platforming Every custom PHP module needs classification before build work starts. Three outcomes: dropped because ACCS now handles the functionality natively, rebuilt as an App Builder action or webhook for server-side logic, or moved to API Mesh for data transformation and aggregation across sources. Fifteen custom modules sound manageable until three of them turn out entangled with the GraphQL layer, requiring real App Builder rebuilding. Finding that in Phase 1 is manageable. Finding it mid-sprint is significantly more expensive. ### Workstream 4: Integration Re-Platforming Integrations wired to the Commerce database or built on polling REST endpoints do not survive the move. Adobe's Integration Starter Kit provides authentication, event subscription, transformation scaffolding, and retry logic as a foundation. The architectural shift moves teams toward event-driven [system integration](https://www.krishtechnolabs.com/system-integration-services/) through Adobe I/O Events, external systems subscribe to Commerce events and trigger App Builder actions in near real time. Krish's [Data Engineering team](https://www.krishtechnolabs.com/data-engineering-services/) uses this workstream to retire integration debt accumulated over years of on-premise patches rather than carrying it forward. ## Four Questions That Reveal What Kind of Project You Are Facing Before formal scoping, these questions show the real shape of your migration: * How many custom modules run inside your Commerce core and how deeply do they touch GraphQL? Surface-level modules are a different project than modules modifying checkout logic or extending core resolvers. * Which third-party extensions does your storefront depend on and do ACCS-compatible equivalents exist? You cannot answer this without auditing each one individually. * How many external systems connect directly to your Commerce database or REST endpoints? Every ERP, CRM, OMS, and shipping provider needs a re-platformed connection, database-wired integrations do not survive the move. * Is your storefront Luma, PWA Studio, or already headless? Luma means a full EDS rebuild. PWA Studio can migrate or stay. Headless storefronts on GraphQL are largely unaffected by the backend change. ## What a Structured Assessment Produces A proper discovery phase before build work begins should cover: * Codebase audit — every custom module, its purpose, what it touches, and its target ACCS pattern * Data audit — database size, custom tables outside the Bulk Migration Tool, and data quality issues * Integration mapping — every connected system, current method, and ACCS compatibility * Configuration capture — every Admin setting that will not migrate automatically * Performance baseline — Lighthouse scores and KPIs for post-migration validation * Storefront path decision — EDS rebuild, PWA Studio migration, or headless build decided early since it drives the longest lead time ## The Three Migration Approaches Available **Full migration** moves data, storefront, and integrations simultaneously. It suits merchants with limited customization who want the fastest path to cutover, at the cost of every workstream needing to be complete before go-live. **Incremental migration** stages each workstream while the existing platform stays live. The EDS storefront can go live before backend integrations are complete with API Mesh bridging the gap. This is the realistic path for merchants carrying years of customization and integration debt. **Commerce Optimizer** serves as a transitional step, letting merchants adopt Merchandising Services on top of the existing backend before committing to full cutover. A practical way to reduce decision risk for teams still evaluating whether the full re-platform makes sense now. ## Where ACCS Migrations Stall The same failure patterns appear consistently: * Teams assume configuration migrates with data and find gaps in UAT rather than Phase 1 * The storefront rebuild gets treated as a late-stage task rather than the critical path item it almost always is * Module complexity gets underestimated by counting modules rather than checking GraphQL entanglement * The Bulk Migration Tool support ticket goes in late rather than at project start * The initial bulk load gets planned without a change-data-capture strategy for the data gap before go-live ## How Krish Approaches an ACCS Migration An [Adobe Commerce](https://www.krishtechnolabs.com/adobe-commerce-partner/) to ACCS migration is four workstreams running in parallel against a locked core, not a sequential checklist. That is a different kind of project than most teams have managed before, which is why assessment carries more weight here than in a typical replatform. Krish's [Adobe Experience Cloud](https://www.krishtechnolabs.com/adobe-experience-cloud-partner/) practice runs the module audit, data audit, and integration mapping as a single Phase 1 engagement. Every customization gets classified before build work starts. The existing platform stays live throughout an incremental migration. Where catalog and merchandising intersects with broader data strategy, [our AI and Data team](https://www.krishtechnolabs.com/artificial-intelligence-and-data/) scopes the Composable Catalog Data Model decision alongside the migration rather than after it, because it shapes how the storefront consumes product data from day one. The complete workstream breakdown, migration path comparison, and full checklist lives in the [Adobe Commerce to ACCS migration guide](https://www.krishtechnolabs.com/blog/adobe-commerce-to-accs-migration-guide/). If you want to know what ACCS actually requires from your specific environment, we can run that [readiness assessment](https://www.krishtechnolabs.com/ecommerce-audit/) against your real codebase.