Learn how one implementation team guided Sunstar through a PaaS-to-SaaS migration, discovering that the real work was not moving data, but redefining how the system communicates and deciding what to leave behind.

Adobe Commerce as a Cloud Service was introduced in the summer of 2025, and it immediately stood out as more than just another product release. It addressed a set of challenges seen repeatedly across projects: growing infrastructure complexity, increasing operational overhead, heavy reliance on customizations, and the constant effort of keeping systems stable, secure, and scalable.

For the first time, there was a clear alternative, a model where much of the operational responsibility shifts from the merchant and implementation partner to Adobe. Scaling, monitoring, availability, infrastructure maintenance, and platform security become managed services, allowing merchants and their partners to focus more on building business capabilities instead of running the platform itself.

One of the first candidates that came to mind was Sunstar. Now here is that journey, not just a step-by-step guide, but as a reflection on what actually changes when moving from PaaS to SaaS, and what it really takes to get there.

Why Sunstar was the right candidate for this transition

Sunstar was a particularly strong fit for this transition because they were already deeply invested in the Adobe ecosystem, running Adobe Experience Manager (AEM) as the storefront layer and Adobe Commerce as the commerce backend. At the same time, their implementation relied on relatively limited custom Commerce capabilities, which significantly reduced the migration effort and complexity.

Just as importantly, Sunstar is a customer strongly driven by innovation and focused on keeping their digital platform aligned with modern performance, scalability, and architectural standards.

It started five years ago and not with Adobe Commerce

When work with Sunstar began more than five years ago, Adobe Commerce was never intended to be the centerpiece of the architecture. That role was taken by Adobe Experience Manager, a content and experience management solution.

Commerce at the same time had a clearly defined responsibility: it owned the catalog and little beyond that. Product attributes, category structures, and metadata were managed in Adobe Commerce, while AEM handled everything related to content and experience. In many ways, this setup resembled a content-driven platform powered by a catalog backend, rather than a traditional eCommerce system.

And for quite some time, it worked remarkably well.

When one system became two: Scaling the model

As the platform evolved, so did its complexity. A second Adobe Commerce instance was introduced for the US region, while EMEA continued to operate independently. At the same time, each region managed two parallel catalogs; one for professionals and one for consumers.

Interestingly, none of this affected the storefront. A single AEM frontend continued to orchestrate everything, connecting to multiple commerce backends and assembling the experience dynamically. Checkout was not part of Adobe Commerce either. It was embedded directly into AEM, reinforcing the idea that Adobe Commerce was not the "engine of experience", but rather the engine of structured data.

This separation worked. But it also created a system that required careful coordination across multiple layers.

Introducing SaaS capabilities without breaking anything

The first shift came with the introduction of Catalog Service and Live Search. From an architectural perspective, this was already a move toward SaaS, but from a delivery perspective, nothing changed.

The frontend continued to call the same endpoints. Adobe Commerce simply proxied those requests to the new services. This abstraction layer made the transition almost invisible. And that invisibility is important, because it creates the expectation that moving further toward SaaS will remain low-risk and incremental, with existing integrations and frontend implementations continuing to work largely unchanged.

At that point, moving further toward SaaS looked like a natural next step: low risk, incremental, straightforward.

The assumption that turned out to be only partially true

When Adobe Commerce as a Cloud Service became available, the decision to move felt logical. The project had very limited customization: no complex modules, no deep platform overrides, only a few isolated features around URL handling and data import. Compared to many commerce projects, this was a clean setup.

Which led to a reasonable assumption: "If there is little customization, the migration should be simple."

That assumption turned out to be only partially true.

Where SaaS becomes real: The API layer

The biggest change did not happen in the backend. It happened where nobody initially expected it, in the contract between frontend and backend.

On Adobe Commerce Cloud, even with Catalog Service in place, the system still supported standard endpoints. They acted as a compatibility layer, shielding the frontend from deeper changes. On SaaS, that layer disappears. The frontend is no longer talking to "Adobe Commerce as before." It is talking directly to SaaS services with different API contracts, authentication models, and integration patterns.

Instead of a single application exposing legacy-compatible endpoints, the architecture shifts toward a unified graph of Commerce services, often orchestrated through API Mesh. That changes both the frontend integration strategy and the responsibilities of the implementation team. Suddenly: queries need to be rewritten, response structures need to be adapted, assumptions about data availability need to be revisited.

The migration was no longer about moving data. It became about redefining how the system communicates.

Migration as alignment, not just transfer

The actual migration process followed a structured path: mapping existing functionality, identifying what could be dropped, rebuilding missing capabilities using Adobe App Builder, and adapting frontend integrations.

Identifying what could be dropped became an important part of the exercise. For example, SaaS no longer required migrating a custom import extension that previously handled catalog import logic. Similarly, modules that modified GraphQL outputs were no longer needed, because this responsibility moved into Adobe API Mesh as part of the new integration architecture.

A key aspect of this project was the clear distribution of responsibilities. Adobe was deeply involved throughout the process: supporting the migration planning, taking ownership of rebuilding required custom logic using Adobe Developer App Builder, and guiding both the technical and organizational transition.

Another important step before the actual migration was system consolidation. The two existing PaaS instances (EMEA and US) were first aligned and prepared, allowing simplification of the landscape before moving to SaaS.

How to's

Step 1. Map existing functionality and identify what can be dropped.

Before touching the platform, audit every customization. Modules that modified GraphQL outputs and custom import extensions may no longer be needed; those responsibilities shift to API Mesh and native SaaS services. (Adobe Commerce PaaS → SaaS migration.)

Step 2. Consolidate instances before migrating.

If running multiple regional PaaS instances, align and prepare them first. Moving to a single SaaS instance with a unified catalog is not only possible — it is logical, because scalability is no longer tied to infrastructure planning handled by the project team. (Applies where multiple PaaS instances exist.)

Step 3. Rebuild missing capabilities in Adobe App Builder and adapt frontend integrations.

Rewrite queries, adapt response structures, and revisit assumptions about data availability. The frontend is no longer talking to Adobe Commerce as before, it is talking directly to SaaS services with different API contracts, authentication models, and integration patterns. (API Mesh orchestration required for unified graph architecture.)

Migration execution: More predictable than expected

From a technical perspective, the data migration itself was surprisingly smooth. Adobe provided an internal migration tool that analyzed the existing database structure, mapped data between PaaS and SaaS, and performed a controlled, consistent transfer.

The process was executed under strict conditions: maintenance mode enabled, no data changes during migration, full validation after transfer. This made the migration itself largely predictable and reliable, removing much of the risk typically associated with large-scale data moves.

But again, the real effort was not in copying data. It was in aligning APIs, responsibilities, and system boundaries. This is where SaaS forces clarity.

Outcome:

• Fewer systems to manage

• Fewer support issues

• No infrastructure ownership

• No patching cycles

• No environment maintenance

In other words, the platform became quieter. And that's often the strongest signal that architecture is working.

Key takeaways

• The biggest change did not happen in the backend — it happened in the contract between frontend and backend. Plan for API rewriting, not just data migration.

• "If there is little customization, the migration should be simple." That assumption turned out to be only partially true. The abstraction layer that shielded the frontend on PaaS disappears on SaaS.

• Identifying what could be dropped became an important part of the exercise. SaaS forces clarity on what the system actually needs to keep.

• System consolidation before migration matters. Aligning multiple PaaS instances first simplifies the landscape and reduces SaaS migration complexity.

• On PaaS, flexibility comes from the ability to modify anything. On SaaS, flexibility comes from designing within constraints — fewer customizations, more reliance on APIs, clearer separation of concerns.

The platform becoming quieter after go-live — fewer support issues, no patching cycles, no environment maintenance — is often the strongest signal that architecture is working.

What I'd do differently today

Looking back, the migration was not about adopting SaaS. It was about removing everything that made SaaS difficult.

The real question was never "Can we move to SaaS?" It was "How much of our current system do we actually need to keep?" Because in the end, the success of this project didn't come from what was migrated. It came from what was decided to leave behind.

Actionable next steps

1. Audit every customization before scoping the migration. Classify each one: does it need to be rebuilt in App Builder, moved to API Mesh, or dropped entirely? The answer to that question defines the real scope of work.

2. Do not assume limited customization means simple migration. Map the API contract between your frontend and backend explicitly — that is where the real migration effort lives.

3. Consolidate multiple PaaS instances before moving to SaaS. Align multiple instances first; simplifying the landscape before the migration reduces risk significantly.

4. Plan for API rewriting, not just data transfer. Queries need to be rewritten, response structures need to be adapted, and assumptions about data availability need to be revisited when the compatibility layer disappears.

5. Use Adobe's internal migration tool for the data transfer itself. With maintenance mode enabled and full validation after transfer, the data migration is the more predictable part of the process.

6. After go-live, measure success by what disappears: support issues, patching cycles, environment maintenance, infrastructure overhead. A quieter platform is the outcome.