Migrating from Adobe Commerce PaaS to ACCS: A Developer Checklist

This is the fourth post in my ACCS series. If you’re new here, start with the introduction to ACCS, then the ACCS vs Adobe Commerce on Cloud comparison. This one assumes you’ve already decided to move and now need a plan.

I’ve written it as the checklist I’d want pinned next to my monitor during a migration. It follows the phases in Adobe’s own migration guide (assess, modernize the application and data, modernize the storefront, cut over and operate), with my notes added. Everything about Adobe’s tooling comes from the Experience League migration docs. When something is my opinion or practice, I say so.

One thing to accept before you start: Adobe’s docs say plainly that none of the four areas (application, data, storefront, integrations) can be migrated without adapting them. There is no lift-and-shift.

Phase 1: Assessment and module audit

Adobe has a Migration Assessment Tool for this, and the docs say every migration should start with it. It scans your codebase (no production access needed beyond sharing the code) and produces a report linked to your IMS org. The report includes a complexity score: Low is 150 or below, Medium is 151 to 375, and High is above 375. Adobe says High usually means a phased migration that can take 12 to 24 months. That number alone is worth showing to your stakeholders early.

• ☐ Share the codebase with Adobe and get the assessment report.
• ☐ Read the Summary tab: complexity score, highest-impact modules, migration drivers.
• ☐ Check the data model section. Adobe advises a dedicated data workstream if there are more than 15 core table modifications.
• ☐ Note the storefront signals: custom theme, block count, core layout handle overrides and whether “Checkout” shows up under drop-in migration required.
• ☐ Export the module list and sort every module into one of three buckets (below).
• ☐ Ask the business, module by module: is this still used?

The assessment gives each module a recommendation of Rebuild, Refactor, Replace with a native feature, or Remove. I like to collapse that into three buckets for planning:

The third bucket is where projects slip. Class preferences and core table modifications are exactly what Adobe’s assessment flags as the riskiest patterns, and they have no direct equivalent on ACCS. Get those decisions made in week two, not month six.

Phase 2: Data and catalog migration

Data moves through the Commerce Data Migration Service, driven by a Docker-based CLI that your integrator runs on their own machine. The steps are extract and transform, load, verify, and report. Two caveats from the docs matter a lot. First, the bulk data migration tool is in Early Access and comes through Adobe’s Commerce Deployed Engineering engagement. Second, it moves first-party core commerce data only. Custom and third-party extension tables are not migrated, and system configuration isn’t either.

• ☐ Complete Adobe’s data migration scoping questionnaire (topology, entities, volumes, compliance, custom tables).
• ☐ Write down your current store and catalog configuration and set it up on the ACCS instance before migrating. It won’t come across on its own.
• ☐ List every custom or third-party table you need to keep and plan where it lives (an App Builder store or an external database).
• ☐ Do a full dry run on a sandbox, with the source live.
• ☐ Review the verification results (record counts, plus GraphQL and REST spot checks).
• ☐ Confirm the catalog has reached Catalog Service, Live Search and Product Recommendations. The docs say this ingestion happens automatically after load.

For dry runs, the guide uses a single command that runs the whole pipeline without maintenance mode:

./bin/console migration

For production, where orders must not change during extraction, the guide says to use the phased approach instead, with separate commands around the maintenance window:

./bin/console migration:before-maintenance
./bin/console migration:during-maintenance
./bin/console migration:cleanup

On a PaaS source, the extraction connects to the database through a tunnel opened with magento-cloud tunnel:open.

Phase 3: Customisations to App Builder

Adobe calls this “typically the most significant engineering effort” of the migration, and I agree. Every plugin, observer and preference you kept in Phase 1 needs a new home outside the core.

• ☐ Map async observers (after order save, after customer register) to events handled by App Builder actions.
• ☐ Map blocking logic (validation before checkout, custom shipping rates) to webhooks.
• ☐ Replace custom GraphQL resolvers that call third parties with API Mesh sources.
• ☐ Rebuild Admin grids and pages with the Admin UI SDK.
• ☐ Check Adobe Exchange for an existing app before building your own.
• ☐ Decide where persistent data lives. App Builder’s state library is file-based, and database storage is still in early access.

Adobe also offers AI-assisted tooling here: the Commerce Developer Agent in the browser and the Commerce Developer MCP for your IDE. Both read the assessment and help scaffold App Builder extensions. The docs say nothing is generated until you approve a blueprint, and that output must be reviewed by your team. The setup command for the IDE tools, per the assessment docs (Node.js 22.x and the Adobe I/O CLI required):

aio commerce extensibility tools-setup

My view: use them to speed up scaffolding, but don’t let a generated app go to production without the same review you’d give a junior’s pull request.

Phase 4: Integrations and ERP

Integrations get assessed alongside everything else, but Adobe notes that implementation depends on the scenario, using App Builder, API Mesh, Adobe I/O Events and the ACCS APIs.

• ☐ Draw every integration: system, direction, frequency, trigger and data owner.
• ☐ Replace cron-driven exports from Commerce with event-driven App Builder flows where you can.
• ☐ Confirm each external system (ERP, PIM, OMS, tax, shipping) can reach the new endpoints and auth model.
• ☐ Look at the backend Integration Starter Kit before you write ERP sync from scratch.
• ☐ Agree on retry and error handling with the ERP team. Out-of-process means network calls, and network calls fail.

Phase 5: Storefront rebuild on EDS

Luma isn’t supported on ACCS, so the storefront is a rebuild on Edge Delivery Services. I covered the setup in detail in my Edge Delivery Services storefront for ACCS post. Adobe’s assessment says a custom theme always means a dedicated frontend workstream, and checkout listed under drop-in migration is the most complex storefront task.

• ☐ Create the storefront with Site Creator and clone the boilerplate.
• ☐ Run npm install, then npm run install:dropins (the boilerplate disables npm lifecycle scripts, so this step is manual).
• ☐ List custom checkout, cart and PDP behaviour and decide: slot, extended drop-in or new drop-in.
• ☐ Move CMS and Page Builder content into documents.
• ☐ Train merchandisers on document authoring early, not in launch week.

Phase 6: SEO and redirects

This section is my own practice rather than anything Adobe-specific. URL structures almost always change when you move from Luma to a new storefront, and lost rankings are the most expensive bug you can ship.

• ☐ Crawl the current site and export every indexable URL, plus the top landing pages from analytics.
• ☐ Build a 301 redirect map from old URLs to new ones (products, categories, CMS pages).
• ☐ Carry over titles, meta descriptions, canonicals and structured data.
• ☐ Generate and submit new sitemaps on launch day.
• ☐ Read Adobe’s storefront SEO docs for how EDS handles indexing and metadata.

Phase 7: Testing, cutover and rollback

• ☐ Do end-to-end test orders through every payment method and shipping method.
• ☐ Test each event and webhook path, including what happens when the receiving service is down.
• ☐ Load test the storefront and your App Builder actions, not just Commerce.
• ☐ Do at least one full rehearsal of the phased data migration with real timings.
• ☐ Freeze catalog and config changes before the window.
• ☐ Lower DNS TTLs a few days ahead.
• ☐ Write the rollback plan: keep the PaaS store intact and ready, and decide upfront who calls a rollback and by when.
• ☐ Plan how orders placed on ACCS during a rollback would get back to the old system or ERP.

The rollback items are my own practice. Adobe’s docs cover the migration side, not your go/no-go process. I’ve seen teams skip the last point and regret it.

Phase 8: Post-launch

• ☐ Watch 404s and redirect hits daily for the first two weeks.
• ☐ Set up monitoring for App Builder apps (OpenTelemetry) and the storefront (RUM dashboards). New Relic isn’t included on ACCS, so bring your own account if you need it.
• ☐ Keep an eye on the in-app update notices. You get a 30-day window to test updates on your sandbox before they reach production.
• ☐ Keep up with the @dropins/* package updates in your storefront repo. Your fork doesn’t update itself.
• ☐ Decommission the PaaS environment only after the rollback window has passed and data has been archived.

Final thoughts

If I had to pick one piece of advice, it’d be this: spend more time on Phase 1 than feels comfortable. Every module you retire there is code you never have to rebuild, test or migrate data for. Adobe’s own docs say assessments routinely surface unused features, and in my experience that’s true on almost every store.

Then work in parallel. Data dry runs, App Builder rebuilds and the EDS storefront can all move at once once the module buckets are agreed. Copy this checklist into your project tracker, assign owners, and treat every unchecked box in Phase 7 as a launch blocker.