Documentation for Adobe API Mesh reconfiguration for Adobe Commerce migration from PAAS to SAAS.

Hi ​@LkKu ,

“Reconfigure existing mesh” in that table just means:

Reuse your current API Mesh project and update its configuration so it talks to the new Commerce SaaS back end instead of the old PaaS one, instead of throwing it away and starting from scratch.

In practice, reconfiguring an existing mesh during PaaS -> SaaS migration usually means:

• Point Commerce sources at the new SaaS endpoint
  • Update the graphql endpoint in your meshConfig from your PaaS GraphQL URL to the new Commerce SaaS / OneGraph URL and environment-specific path.
    • Ref: “API Mesh—Create a new mesh or modify the existing one” in https://experienceleague.adobe.com/en/docs/commerce/cloud-service/migration/overview
• Adjust auth and headers
  • Swap any legacy auth and custom headers for the Commerce SaaS headers (for example x-api-key, Magento-Environment-Id, store codes, etc.) as described in the SaaS/Storefront API docs and your tenant setup.
• Add/replace SaaS services as sources: Where you previously called the monolith directly, you now either:
  • call the Commerce SaaS OneGraph endpoint, or
  • add separate sources for Catalog Service / Live Search / Product Recommendations, and adjust resolvers or transforms to stitch them with Commerce data.
  • Ref: API Mesh’s “multiple sources” pattern in https://experienceleague.adobe.com/en/docs/commerce-learn/tutorials/extensibility/api-mesh/getting-started-api-mesh https://developer.adobe.com/graphql-mesh-gateway/
• Clean up PaaS-only sources and logic
  • Remove or simplify any sources that pointed to your old PaaS instance (direct DB APIs, legacy integrations) that are now replaced by SaaS or App Builder services.

From the storefront’s perspective, the Mesh endpoint and schema stay largely stable; you’re just swapping and enriching the upstream sources behind it.