Manually rewriting every PHP customization as an App Builder application is slow, expensive, and error-prone. This article walks through installing the tooling, how the conversion actually works, and just as importantly, what it will not do for you.

If you have a Commerce PaaS installation with years of accumulated PHP customization with plugins, observers, cron jobs, custom modules and you are looking at Adobe Commerce as a Cloud Service (ACCS), the question that stops most migration plans before they start is: what do we do with all this code? Before going further, it is worth being precise about what this tooling is and is not. It is not a magic button that turns your entire PHP codebase into App Builder overnight.

Why this exists: The real migration bottleneck

It is an AI coding agent running inside your existing IDE, given deep, structured knowledge of Commerce and App Builder through MCP (Model Context Protocol) servers. It reads your PHP code, understands the Commerce-specific patterns in it (observers, plugins, cron schedules, event dispatch), and generates the equivalent App Builder application: the action code, the event subscriptions, the app.config.yaml, and the package.json. You still review every line, you still test, and you still make the architectural calls about what should and should not move out of Commerce. Adobe's AI coding tools for Commerce (branded on Adobe's Experience League site as Commerce development MCPs and skills) reached general availability in this period, with partner communications describing them as available now as of April 2026. The tooling is an MCP-powered developer agent that understands both Commerce PHP patterns and App Builder architecture and assists in translating common Commerce extension patterns into App Builder architectures. It is not a deterministic one-to-one converter: architectural redesign is often required, and synchronous PHP behaviors frequently cannot be directly translated, which is exactly the honest limitation the rest of this article works through.

Every Commerce PaaS-to-ACCS migration conversation eventually arrives at the same wall: the client has a custom module that does something specific to their business syncs orders to an ERP (Enterprise Resource Planning), applies a custom pricing rule, sends a notification when a B2B credit limit is exceeded — and it is written as PHP that plugs directly into Commerce's core classes. ACCS has a locked core. That PHP simply cannot run there. It has to become something else: an App Builder action triggered by an I/O Event, a Commerce Webhook, or an Admin UI SDK extension.

Doing this translation by hand for a module with real business logic is genuinely slow work. A developer has to: read the PHP and understand exactly what it does, identify which Commerce extension point it hooks into (an observer? a plugin on a specific class? a cron job?), figure out the nearest App Builder equivalent (an I/O Event subscription? a webhook? a scheduled action?), write the JavaScript/Node.js action that replicates the behavior, and wire up the app.config.yaml and event registration correctly. For a module with a dozen small behaviors, this can take days. Across an entire PaaS codebase with 30 to 50 custom modules, it is easily weeks of work which is exactly the reason so many migration projects stall at the “what do we do with our customizations?” stage before they even begin.

Adobe's AI coding tools are aimed directly at that bottleneck. In a public session on this tooling, Adobe demonstrated a migration assessment scanning a real PHP codebase and producing a complete report mapped plugin analysis, extension points, complexity ratings, and a phased migration plan in a fraction of the time a manual assessment typically takes. That assessment does not do the migration for you, but it tells you exactly what you are dealing with before you commit a team to the work.

What the tooling actually is: MCP servers, skills, and starter kits

Three (in practice, four) components work together, and understanding each one clarifies what is happening when you use the tooling. Adobe's own documentation names them precisely, which resolves most of the naming uncertainty flagged in earlier review of this article:

• The Commerce Developer MCP Server: an MCP (Model Context Protocol) server that gives your AI coding agent access to a Retrieval-Augmented Generation (RAG) service over the current Adobe Commerce documentation set. When your agent needs to know “what is the correct way to subscribe to a commerce.company.created event,” it queries this server instead of relying purely on what it learned during training which matters because Commerce and App Builder APIs evolve, and stale training data produces wrong code. This is Adobe's officially documented name and description, confirmed on Adobe's developer documentation site.

• The App Builder MCP Server: a second MCP server focused specifically on App Builder development patterns; project structure, app.config.yaml syntax, runtime action conventions, and the extension point IDs for things like the Admin UI SDK and I/O Events. This helps the agent generate an App Builder project scaffold aligned with Adobe's recommended patterns. No AI coding system can reliably guarantee deployable correctness on the first generation attempt, so treat this as a strong starting scaffold that still needs review and testing before deployment, not a guarantee of a clean first-time aio app deploy.

• Commerce and App Builder Skills: a structured skill set (in the “agent skills” format supported by Cursor, Claude Code, and other agents) that encodes Commerce-specific architecture, implementation, DevOps, and testing workflows as guided procedures the agent follows, rather than free-form generation. This is the difference between an agent that “knows about App Builder” in a general sense and one that follows Adobe's actual recommended patterns step by step. Generated code from any of these components can still be wrong: event mappings may be incomplete, referenced APIs may be outdated relative to the Commerce version in use, and architectural assumptions embedded in generated scaffolding may not hold for a given codebase. Treat AI-generated App Builder code the way you would treat a capable but unfamiliar contractor's first draft a strong starting point that still needs a knowledgeable reviewer, not a finished product.

For storefront-specific work built on the AEM Boilerplate Commerce starter kit, Adobe also documents a fourth component, the dropins MCP Server, which provides structured data about drop-in slots, events, containers, and design tokens. It is outside the scope of a PHP-to-App-Builder conversion project but worth knowing about if the same team also touches storefront customization.

All three (or four, if the storefront kit is selected) are installed together against one of two starter kits: the Commerce Integration Starter Kit (for back-office integrations: ERP, CRM (Customer Relationship Management), OMS - Order Management System) or the Commerce Checkout Starter Kit (for checkout, payment, shipping, and tax extensions). Adobe's setup flow also lists a third option, AEM Boilerplate Commerce, which additionally installs the dropins MCP server for storefront work. The starter kit you choose determines the project scaffold the tooling works within; pick the one that matches the kind of PHP module you are converting first.

Setting up the tooling: The exact steps

This is precise and mechanical, follow it in order. It assumes you already have Node.js (LTS, v22.x or higher), npm or yarn, and Git installed, and that you are working in Cursor, Claude Code, GitHub Copilot, or another agent-skills-compatible IDE. On Windows, a Bash shell is also required (Git Bash or WSL). The steps below match Adobe's currently published manual setup instructions exactly; Adobe also now offers a newer, automated single-command setup (aio commerce extensibility app-setup) that handles Developer Console project creation and starter kit cloning together, which is worth trying first since it is Adobe's current recommended path, with the manual steps below as the fallback if it runs into issues.

Step 1: Install the Adobe I/O CLI and required plugins

Step 2: Clone the relevant starter kit

Step 3: Run the interactive AI tools setup

After this completes, the setup has installed MCP server integration, agent skills, and Commerce-specific development tools and workflows into your project. For Cursor specifically, you will find the skills under .cursor/skills/. For GitHub Copilot, look for copilot-instructions.md in the .github folder.

Step 4: Authenticate and enable the MCP server

For Cursor: restart the IDE, open the Command Palette (Cmd+Shift+P or Ctrl+Shift+P), run View: Open MCP Settings, find commerce-extensibility MCP Server in the list, and turn it on. Confirm it shows Status: Connected/Active.

For GitHub Copilot in VS Code: restart VS Code, open the Extensions view, find MCP SERVERS - INSTALLED, and use the gear icon next to commerce-extensibility MCP Server to start it if it is stopped. Adobe's own documented example output shows the log ending with the line “Discovered 10 tools” once the server is running correctly; this is Adobe's own current published example, though as with any actively developed MCP server the exact tool count can change in future releases, so treat the number as illustrative of what a healthy connection looks like rather than a fixed value to match exactly.

Verify the whole setup with a test prompt and ask your agent something that requires genuine Commerce-specific knowledge. This exact prompt is the one Adobe's own documentation uses for this verification step:

“What are the differences between Adobe Commerce PaaS and Adobe Commerce as a Cloud Service when configuring a webhook that activates an App Builder runtime action?”

If the MCP server is working, the agent's answer will reference specific, current Commerce documentation rather than a generic explanation. If the answer feels vague or generic, the agent is not actually using the MCP tools — explicitly ask it to use the available MCP tools, or re-check the server connection status.

The conversion workflow: What actually happens when you convert a PHP module

Here is the practical sequence, based on how the tooling is designed to be used and demonstrated by Adobe. Say you have a PHP observer that fires when an order is placed and sends the order to an external ERP system.

1. Give the agent the PHP module as context. Open the module in your IDE (the observer class, the events.xml registration, any related helper classes) so the agent can read the actual code, not just a description of what it does.

2. Describe the goal in plain language. For example: “Create an App Builder extension that sends an event to our ERP system whenever an order is placed on Commerce.” You do not need to write a formal specification; natural language is the interface.

3. The agent asks clarifying questions before generating anything. This is a deliberate and important part of the design — in Adobe's own demonstration of this tooling, the agent asked: Is this a SaaS (ACCS) or PaaS Commerce backend? Should the event trigger before or after the order is placed? What kind of event do you want to send? Is the integration with the external system single-direction or bidirectional? Is this a UI extension or a headless application? Is state management required between invocations? Answer these precisely — the quality of the generated code depends directly on the quality of these answers.

4. The agent proposes a plan before writing code. You see the intended approach, which Commerce event it will subscribe to, what the App Builder action structure will look like, whether state management (Adobe I/O State) is needed, before any files are generated. Review this plan critically. This is your checkpoint to catch a wrong architectural assumption before it becomes 200 lines of generated code.

5. The agent generates the App Builder project files. This typically includes the runtime action (actions/order-sync/index.js or similar), the event registration in app.config.yaml, any required package.json dependencies, and, if requested, a corresponding test file.

6. You review, test, and deploy. Run aio app deploy to a Development workspace, verify the generated action actually fires on the correct event and produces the correct behavior against a staging Commerce instance, and only then promote to Production.

7. Security review for generated code goes beyond functional correctness: authentication and credential handling, secret management, PII (Personally Identifiable Information) handling, and compliance requirements deserve the same scrutiny. Generated code that works correctly on a staging instance can still have a security or data-handling issue that functional testing alone will not catch.

What converts cleanly, and what does not

This is the single most important section for setting realistic expectations. Based on how out-of-process extensibility works architecturally, some PHP patterns map to App Builder cleanly and predictably. Others do not, and pretending otherwise even with AI assistance produces a migration that looks done but is subtly broken.

The clearest theme in this table is worth stating explicitly: many Commerce internals have no external event, no webhook equivalent, and no safe async migration path at all, which is a distinct, harder problem than “this will take longer to convert.”

The Migration Assessment tool: Understanding your codebase before converting anything

Before converting any individual module, run the Migration Assessment tool against your full PaaS or on-premises codebase. This is a real, currently documented Adobe product, not a placeholder name, confirmed on Adobe's Experience League documentation and described in Adobe's own product messaging as performing a static and semantic analysis of your code base, cataloging customizations, data structures, integrations, and third-party modules — exactly the framing this article uses. Processed reports are accessible through Adobe's Experience Cloud shared-assessments interface, and no access to your production environment is required beyond initially sharing your project codebase. The report itself is organized into three tabs: Summary, Module Reports, and Report Reliability; with a weighted Complexity Score that maps to a Migration Complexity rating using fixed thresholds. It produces a report that:

• Maps every custom PHP module to its Commerce extension points (which events it observes, which classes it plugs into, which cron jobs it registers).

• Flags code that requires refactoring versus code that can be converted with minimal changes.

• Identifies where a custom PHP module should become an App Builder action versus an Admin UI SDK extension versus something that needs architectural redesign.

• Highlights data storage needs, where a module relies on custom database tables that need a different persistence approach (Adobe I/O State, an external database, or an API Mesh-fronted data source) once it is out-of-process.

• Assigns a complexity level per module and recommends a phased migration order — start with the low-complexity, high-value conversions to build team confidence and tooling familiarity before tackling the genuinely hard cases.

The output is exportable, which matters practically: it becomes the artifact you use to build a migration plan, estimate effort per module, and communicate technical risk to stakeholders who are not going to read PHP source code but do need to understand why the migration will take the time it takes. It also generates a description of each custom module that can be used as direct input for the AI coding tools covered earlier in this article, connecting the assessment phase directly to the conversion phase.

Working with the agent effectively: What good prompting looks like

The quality of what the AI tooling produces is directly proportional to the quality of the context and instruction you give it. A few practical habits that make a measurable difference:

• Always specify PaaS vs ACCS explicitly. Many Commerce APIs remain conceptually aligned between the two platforms, but extensibility and operational patterns (webhook configuration, event availability, and Admin customization approaches) differ significantly. If you do not specify which target you are converting for, the agent may generate code for the wrong deployment model.

• Give it the whole module, not a fragment. If your observer calls three helper classes, include all three in context. An agent that only sees the observer class itself will guess at what the helpers do, sometimes correctly, sometimes not.

• Ask it to explain its plan in your own words before generating code. If the agent's restated understanding of what the PHP does is wrong, you have caught a misunderstanding before it becomes 200 lines of code built on a wrong premise. This costs 30 seconds and saves an hour of debugging generated code that solved the wrong problem correctly.

• Use the slash commands for repeatable tasks. The tooling includes a /search-commerce-docs command and other slash commands documented in the skills and prompts reference, use these for direct documentation lookups rather than relying purely on the agent's memory, especially for API details that change between Commerce versions.

• Test with production-like data, not just the happy path. An AI-generated conversion that passes on clean sample data can still fail on the edge cases your real production Commerce data contains: null fields, unusual character encodings, orders with zero line items. Do not skip this because the code “looks right”.

• Do not skip the runtime cleanup step. Generated App Builder projects accumulate unused actions, test scaffolding, and configuration during iterative development. Before deploying to Production, review app.config.yaml and the actions folder for anything the agent generated during exploration that should not ship. A generated App Builder project being clean and deployable is not the same as it being production-ready operationally.

Observability (logging, monitoring), retry and idempotency handling, scaling behavior under load, and deployment governance (separate workspaces, review gates) all need the same deliberate attention for AI-generated actions that they would for hand-written ones, the AI tooling accelerates getting to working code, not the operational hardening that follows it.

A realistic view of the time savings

Based on Adobe's own demonstrations, published figures, and the nature of the tooling, the honest way to describe the time savings is this: the tooling compresses the mechanical parts of conversion — boilerplate generation, correct app.config.yaml syntax, correct event subscription patterns — from hours to minutes, and Adobe cites 60 to 70 percent faster App Builder conversion as its own headline figure for this. It does not compress the parts of the work that require human judgement: deciding whether a plugin's logic can tolerate asynchronous execution, deciding what happens if the external system is unavailable, deciding how to handle a partial failure. Those decisions still take the time they take.

For a codebase with many small, well-isolated, event-driven customizations (order sync to a CRM, a notification on stock threshold, a custom email trigger), the tooling can genuinely take conversion from days to hours per module. For a codebase with deeply intertwined PHP that reaches into Commerce's pricing engine or checkout flow, the tooling accelerates the mechanical scaffolding but the architectural redesign work is unchanged, and pretending otherwise in a project timeline is how migrations go over budget.

Key takeaways

• This is an AI coding agent with Commerce-specific knowledge, not an automatic converter. It runs inside your existing IDE via the Commerce Developer MCP Server and App Builder MCP Server (Adobe's own confirmed product names) and generates App Builder code based on your PHP and your instructions. You still review, test, and make architectural decisions.

• Setup is a mechanical CLI process, confirmed against Adobe's current documentation: install the Adobe I/O CLI and plugins, clone a starter kit, run aio commerce extensibility tools-setup (or the newer single-command aio commerce extensibility app-setup), authenticate with aio auth login, and enable the MCP server in your IDE.

• Authentication is required for the RAG service to work, confirmed directly in Adobe's setup documentation. Without it, the agent falls back to potentially outdated general knowledge instead of current Commerce documentation.

• The agent asks clarifying questions before generating code, answer them precisely. If you cannot answer them confidently, you do not yet understand your own legacy PHP well enough to migrate it safely.

• Not everything converts. Observers, cron jobs, and REST endpoints convert well where a matching extension point exists. Anything synchronous inside the Commerce checkout or pricing path with no external surface has no App Builder equivalent and needs architectural redesign, not conversion.

• Run the Migration Assessment tool before converting anything: it is a real, currently documented Adobe product with a Summary/Module Reports/Report Reliability structure and a weighted Complexity Score, and its output feeds directly into the AI coding tools as module descriptions.

• The time savings are real and Adobe has published a figure for them: roughly 60 to 70 percent faster App Builder conversion. Mechanical scaffolding goes from hours to minutes; architectural judgement calls take exactly as long as they always did.

Additional resources

• AI coding tools overview — MCP servers, skills, and supported agents

• AI coding tools setup — installation, CLI plugins, IDE configuration

• Skills, prompts, and commands — slash commands and sample prompts

• Use cases — common extension patterns for REST APIs, checkout, and events

• Best practices — planning mode, testing, deployment, anti-patterns

• Commerce Integration Starter Kit — the reference repo for back-office integrations

• Commerce Checkout Starter Kit — the reference repo for checkout, payments, shipping, tax

• Adobe I/O CLI — the command-line tool that powers the setup process

• Migration Assessment tool — AI-powered PaaS-to-ACCS codebase analysis

Actionable next steps

1. Install the Adobe I/O CLI and the three required plugins today, even before you have a specific module to convert: npm install -g @adobe/aio-cli. Getting the environment set up is a short task that removes friction when you are ready to start real conversion work.

2. Pick one small, well-isolated PHP observer as your first test conversion, something like an order-placed notification or a simple cron job, not your most complex custom module. Use it to learn the workflow, the clarifying questions the agent asks, and how to evaluate the generated code before attempting anything business-critical.

3. Before your next ACCS migration proposal or estimate, run the Migration Assessment tool against the client's PaaS codebase. Use the exportable report — module list, complexity ratings, phased plan — as the basis for your effort estimate and your stakeholder communication, rather than a gut-feel estimate.

4. Build your own internal reference list, categorizing your organization's most common PHP customization patterns (observer types, plugin types, cron patterns you have written repeatedly across projects) against the conversion difficulty table in this article. This becomes a reusable estimation tool for every future migration your team scopes.

5. If you use Cursor or GitHub Copilot already, run the setup command against a low-risk test project this week: aio commerce extensibility tools-setup, or the newer aio commerce extensibility app-setup. Ask the test prompt suggested in Adobe's documentation and confirm the MCP server responds with current, specific Commerce knowledge before relying on it for real project work.