Back to blog
PHP extensions to App Builder: Adobe hands the conversion to AI agents
October 11, 2026Adobe Commerce

Architecture, performance, security — platforms built to last

PHP extensions to App Builder: Adobe hands the conversion to AI agents

By SMART SOLID SOLUTIONS



Every Magento replatforming discussion eventually hits the same wall: the extensions. A ten-year-old store carries dozens of PHP modules — built in-house, bought then patched — that live inside the very process of the core. That is precisely the code the SaaS edition, Adobe Commerce as a Cloud Service, no longer accepts: every customisation must be rewritten outside, on App Builder. Until now, that conversion was priced by hand, module by module, and it was often what buried the business case. Adobe has decided to tool the job with two complementary pieces: a hosted migration agent, and official skills for the coding assistants your teams already use.


An agent that works from an approved plan


The Commerce Developer Agent is a tool hosted by Adobe, reached through an Adobe sign-in, covering two scenarios: creating an App Builder application from a blank page, or converting an existing Commerce extension. Its distinctive trait speaks directly to decision-makers: it generates nothing without a validated plan. The agent first produces a blueprint — an architecture plan broken into phases — which the developer reads, amends and approves before any code is written. Generation then relies on the official App Builder scaffolds: Commerce event subscriptions, webhooks, a settings screen for the merchant, data persistence. The result exports as an archive, ready to join your repository and delivery pipeline.


The documentation is just as clear about the limits, to its credit. All generated code must be reviewed before it goes anywhere near production: Adobe presents the agent as a starting-point generator, not an autonomous developer. It does not build your continuous integration, your local environment or your API Mesh wiring; a session handles one project at a time, and a generation run can take around five minutes.


Open skills for your own assistants


The second piece may be the more interesting one for teams that are already equipped. Adobe publishes official skills: executable playbooks that teach a coding assistant the correct App Builder patterns — initialising an application, subscribing to events, wiring webhooks, creating merchant configuration, persistence or an admin interface, and converting an existing project. They follow the open agentskills.io standard and install with one command (npx skills add adobe/skills) into Claude Code, Cursor, VS Code Copilot or Gemini CLI. The public adobe/skills repository, under the Apache 2.0 licence, already holds dozens of them — Commerce, but also AEM, Analytics and Workfront.


The nuance is strategic. The hosted agent brings you into Adobe's tool; the skills bring Adobe's knowledge into your tool. For a team that already has its review discipline, its conventions and its pipeline, the second route fits in without changing anything about delivery — and without depending on a portal's roadmap.


What this changes in a migration case file


  • The estimate changes in kind. The right question is no longer how many days a full rewrite takes, but how many of your modules fit the covered patterns: events, webhooks, configuration, storage, admin screens. Those convert quickly at a predictable cost; whatever alters the order process inside the core remains a genuine architecture project.
  • Review becomes the main cost line. Code arrives faster, but every line must be read; your senior developers shift from authors to reviewers. Without a solid review gate — acceptance tests, continuous integration, a hard rule of never shipping unreviewed code — a generator merely produces debt faster.
  • Vendor lock-in has to be weighed piece by piece. The skills follow an open standard and run in the assistant of your choice; the target code, however, remains App Builder, hence Adobe's infrastructure. Conversion is a platform commitment: decide it for the platform, not for the convenience of the tool.

Where to start


  • Inventory your extensions and sort them into two columns: covered by the patterns above, or anchored in the core process. The second column measures your real distance to SaaS.
  • Pilot on a single extension of medium complexity: blueprint, generation, then an honest measure of the review and hardening time. That is your unit cost of conversion; multiplying it beats any abstract estimate.
  • Set the guardrails before accelerating: replayable tests on critical journeys, mandatory review, no production without a human read. Generation speed is only worth as much as your quality control.

Unveiled at Summit in the spring, the agent reached general availability at the end of September, and App Management now has its own entry in the Commerce Admin. Adobe's message for 2027 is plain: rewriting your extensions is no longer a reason to postpone the decision — the vendor supplies the workers. What remains yours to supply is the one thing that cannot be generated: the site foreman.