How are teams planning AEP + App Builder adoption alongside existing Adobe Commerce implementations?

Hi ​@abhay5683 

Great thread — this is the conversation I'm having with most clients right now, so here's the pattern that's actually worked rather than the theory.

1. Introducing AEP without disrupting current Commerce operations — start strictly one-directional.

The lowest-risk entry point is streaming data out of Commerce into AEP while changing nothing in the transactional path. Two channels do most of the work: storefront behavioural events via the Adobe Client Data Layer + Experience Platform Web SDK, and back-office events (order placed, order status change, customer updates) via Adobe I/O Events for Adobe Commerce, where you subscribe to specific observer/plugin events declaratively (bin/magento events:subscribe …) rather than writing custom modules to emit them. The Data Connection extension handles the mapping into XDM.

The critical discipline is that phase one is read-only from Commerce's perspective — nothing in checkout or order placement depends on AEP being available. Activation (AEP driving experiences back into Commerce) is a separate phase with a genuinely different risk profile, and conflating the two is what makes these programmes feel scary to stakeholders.

2. What App Builder actually gets used for.

In practice it clusters into three patterns, roughly in adoption order:

• Third-party integrations — ERP/OMS/PIM synchronization that used to be cron-based PHP modules inside Commerce, now Runtime actions triggered by I/O Events. Usually the first and easiest win.
• Admin UI extensions via UI Extensibility, so custom admin screens live outside the Commerce codebase entirely.
• Async orchestration — event-driven workflows where I/O Events handles delivery, retry and dead-lettering instead of a hand-rolled queue consumer.

Worth adding API Mesh to the same conversation: composing GraphQL across Commerce, Catalog Service and third-party sources at the mesh layer removes a lot of the custom resolver code that historically had to live in-process.

3. The architectural challenges that actually bite during phased modernization.

• Consistency semantics change. In-process plugins run synchronously inside the transaction; Runtime actions don't. Anything that must be atomic with order placement (inventory decrement, fraud gating, custom totals) cannot simply move out-of-process — teams discover this mid-migration more often than they'd like.
• Observability splits in two. Logs live in Commerce Cloud/New Relic and in Runtime activations and I/O Events tracing. Agree a correlation-ID convention before the first integration ships, not after the first production incident.
• Runtime execution limits. Actions have execution-time and payload ceilings, so a large catalog export can't be lifted and shifted from a PHP cron — it needs chunking or fan-out by design.
• Credential and workspace sprawl. IMS technical accounts, OAuth server-to-server credentials and per-environment Developer Console workspaces need to be codified into your pipeline early; hand-configured environments become the bottleneck surprisingly fast.
• XDM modelling effort is consistently underestimated. Mapping Commerce's EAV/quote/order entities onto XDM schemas is where timelines slip, far more often than the plumbing.

4. Handling legacy custom modules — classify before you migrate.

I'd bucket every module into four categories and treat them differently:

• (a) Core-behaviour overrides — preferences/rewrites, direct DB access. Highest upgrade risk and hard blockers for ACCS. Refactor these first, to plugins or out entirely.
• (b) Integrations — cron, API, feed. Prime candidates to move to App Builder, and the easiest early wins to demonstrate value.
• (c) Storefront/theme customizations — leave these until a storefront replatform decision is actually on the table.
• (d) Genuine in-process domain logic — custom pricing, custom totals, cart rules. Keep in Commerce for now, and treat these as the long pole for any ACCS conversation.

Run the Upgrade Compatibility Tool plus a dependency audit to produce that inventory objectively, rather than from institutional memory — the list is almost always longer and messier than the team expects.

5. ACCS readiness through composable services.

The hard constraint is that ACCS is SaaS and closed to in-process PHP customization, so "readiness" really means: can every customization be expressed as out-of-process extensibility? Concretely that's —

• eliminate rewrites/preferences and direct DB access
• stop persisting custom data in your own tables (move to custom attributes on core entities, or external storage accessed via App Builder)
• replace custom GraphQL resolvers with API Mesh
• replace admin UI customizations with UI Extensibility apps
• make integrations event-driven rather than polling
• adopt Catalog Service/Live Search rather than manipulating the search index in-process

The cheapest governance change available today is gating every new customization request on "would this survive on ACCS?" Otherwise you're refactoring debt out of one side while quietly adding it back on the other.

On data synchronisation patterns specifically, one rule worth setting early: keep Commerce as system of record for transactional data and AEP for profile/behavioural data, and avoid bidirectional sync of the same field — that's the root of most production incidents I've seen in this space. Also make every event consumer idempotent (dedupe on order/entity ID), because I/O Events delivery is at-least-once, so duplicates are a matter of when, not if.

The phasing that's worked in practice:

1. Observe — one-directional event streaming into AEP, zero changes to the transactional path.
2. Extract — move integrations out of Commerce into App Builder, starting with the least business-critical one to build team confidence with the toolchain.
3. Refactor — eliminate rewrites, direct DB access and custom resolvers; this is the real ACCS-readiness work and the least glamorous phase.
4. Activate — AEP-driven experiences feeding back into the storefront, once the operational and governance groundwork is solid.

Most teams want to start at step 4 because that's where the visible business value is. Starting at step 1 is what makes step 4 survivable.

Hey ​@abhay5683 ,

This is basically every client conversation I've had this year, so glad someone's asking it out loud.

Honestly the "full replatform" pitch is a much harder sell now than it was even 18 months ago. Clients have been burned by big-bang migrations before, so the moment you can show them a path where Commerce keeps running exactly as-is while you bolt on AEP for the customer data and personalization side, they relax a bit.

What's worked for us: don't let AEP anywhere near the transactional path early on. We push Commerce order and customer events out through Adobe I/O Events, AEP picks them up for identity stitching and audience building, and that's it for phase one. No real-time personalization, no checkout dependency on AEP being up. Once that pipe is boring and reliable (took us about two sprints to actually trust it), then you start layering in the fancier stuff.

App Builder for us is mostly glue right now, not brains. Normalizing webhook payloads, exposing a clean API for legacy modules so they're not reaching into Commerce core directly, that kind of thing. I'd be nervous putting anything truly business-critical in there without a solid retry and dead-letter-queue story. We had a cold start issue bite us early on that made us rethink what actually belongs in an App Builder action versus what stays in Commerce.

Legacy modules is the messy part, always is. We just go through them one by one. Is this actually still needed, can it die, or does it get wrapped behind an interface so nothing downstream cares that it's still the old code underneath. That wrapping step is the one everyone wants to skip because it feels like extra work for no visible payoff, but it's the thing that makes the eventual migration not a nightmare.

On ACCS, nobody I'm working with is migrating today, but the smart clients are quietly setting themselves up so it wouldn't be traumatic if they decided to in a year or two. Less direct DB and core overrides, more stuff living behind APIs and events. Doesn't cost much now and pays off later.

If I'm honest the hardest part isn't any of the flashy stuff, it's just data sync between Commerce and AEP. Ordering, idempotency, what happens when an event gets replayed or arrives late. It's a boring plumbing problem but it'll wreck your personalization accuracy if you don't get it right up front.

Anyway, would love to hear how others are handling schema ownership between the two systems. Who signs off when the AEP data model needs to change because Commerce changed something upstream? That's been our biggest source of "wait, who broke this" moments.

​@abhay5683,  This is a great discussion. The points around phased adoption, event reliability, and legacy-module classification are particularly relevant.

One additional thing I would add is to establish a clear responsibility boundary between Commerce, App Builder, and AEP before starting the modernization work.

My preferred mental model would be:

Commerce → transactional system and source of truth
App Builder → integration, orchestration, and out-of-process business capabilities
AEP → customer data, behavioral data, segmentation, and activation

Adobe's current Commerce architecture supports this separation through App Builder, Events, Webhooks, API Mesh, and Admin UI SDK, while Commerce Data Connection can send storefront, back-office, and profile data into Experience Platform.

The part I think is easy to underestimate is contract governance. Before moving integrations out of Commerce, I'd want to define:

Event ownership → schema/XDM contract → source of truth → delivery semantics → idempotency → replay strategy → downstream ownership

Otherwise, the technical migration may succeed while the data architecture becomes harder to operate.

I also wouldn't treat AEP as another integration/middleware layer. Its value is in unifying Commerce data with data from other enterprise sources and using that data for segmentation, personalization, and other Experience Platform use cases.

One practical pattern I would be interested in hearing about is how teams define the boundary for synchronous vs. asynchronous business logic. Anything that must affect the current Commerce transaction may need a synchronous Commerce/webhook extension point, while integrations, enrichment, and downstream processing are much better candidates for event-driven App Builder flows. Adobe's current extensibility model supports both event-driven and synchronous webhook patterns.

For me, that leads to a useful modernization question:

Before moving a capability, can we clearly identify its business owner, system of record, latency requirement, and failure/replay behavior?

Once those are explicit, the choice between keeping it in Commerce, moving it to App Builder, or feeding it into AEP becomes much easier to make.

Hi ​@abhay5683 
Great question. I'd approach this as outcome-led, phased modernization, rather than a big-bang replatform or assuming every use case needs App Builder.

For AEP, I'd first define the data contract and the requirements for identity, consent, and latency. Commerce data can include distinct data types—storefront behavior, back-office events, and customer profile data—so I'd choose the collection path based on the data rather than treating one method as the answer for everything https://experienceleague.adobe.com/en/docs/commerce-merchant-services/data-connection/fundamentals/connect-data

For integrations and custom logic, I'd use App Builder selectively where out-of-process extensibility or event-driven workflows are a good fit, and evaluate API Mesh when the need is to compose APIs across systems. I'd also check whether existing middleware or Commerce APIs already meet the requirement before adding another layer, then validate latency, retries, idempotency, monitoring, and operating cost in a pilot.

For legacy customizations, I'd inventory them and decide case by case what to retire, replace with native functionality, keep in the current PaaS implementation for now, or redesign using supported extension points. If ACCS is a target, I wouldn't assume in-process PHP customizations will carry over unchanged; I'd start with an assessment of modules, dependencies, data, storefront, and integrations, then sequence the work.

A practical starting point could be one low-risk, measurable integration or customization, with clear ownership and success criteria, then expand based on what the pilot shows.

Curious what others have learned: Which use cases have been the best first candidates for App Builder, and how are you deciding between App Builder, API Mesh, existing middleware, and direct Commerce APIs?