Luma Bridge is a session-sharing mechanism that lets a modern Edge Delivery Services (EDS) storefront and a classic PHP-rendered Adobe Commerce instance coexist on the same domain without duplicating cart or authentication state. It's a targeted solution to a specific architectural problem, and it's worth understanding precisely what it does and doesn't do.

The problem it solves

Full headless migrations of mature Adobe Commerce installations are expensive, slow, and risky. Cart customizations, payment integrations, tax logic, loyalty flows, and customer account logic don't migrate themselves — and moving them all at once means months of parallel development, regression testing, and a high-stakes big-bang cutover. In practice, projects like this routinely run over budget, over schedule, and over the risk appetite of any reasonable stakeholder.

Luma Bridge cuts through that complexity

Instead of a costly all-or-nothing migration, it enables a genuinely phased approach — delivering measurable business value from day one, without holding everything hostage to the completion of the most complex parts of the project.

The strategy is straightforward: migrate catalog, PLP, and PDP pages to EDS first. These are the pages where performance and SEO gains are largest and the impact on conversion and discoverability is most immediate. Product catalog, categories, and pricing continue to be managed entirely within Adobe Commerce — but are surfaced to the EDS storefront via Adobe Live Search and the Adobe Catalog Service, providing a fast, API-driven data layer without duplicating commerce logic. Meanwhile, cart, checkout, and account pages continue running on the existing PHP backend — untouched, battle-tested, fully compliant. The two storefronts share session state transparently via cookies, so the end user experiences a seamless journey.

The business case is compelling:

• Faster time-to-value — Go live with a high-performance EDS storefront in weeks, not months, without waiting for the full backend rewrite
• Lower project cost — Scope the migration in phases; avoid the overhead of replicating every customization simultaneously
• Reduced risk — No big-bang cutover. Each migration phase is independently testable and reversible
• Immediate performance wins — Lighthouse up to 100 are achievable on the EDS front-end while the complex backend logic remains stable
• Preserved investment — Years of custom PHP development on cart, checkout, and account pages don't get thrown away; they stay in production until you are ready to replace them on your terms

In short: you get the front-end of the future without dismantling the backend of today.

How it works

Both storefronts must operate on the same top-level domain. Within that constraint, session continuity is maintained through two cookies:

Luma Bridge is implemented as a PHP module installed on Adobe Commerce. When enabled, Adobe Commerce is taught to recognize and issue the same cookies that the EDS drop-in components produce natively. Because both applications share a domain, the cookies are visible to both — no token exchange, no proxy, no session replication service.

CDN setup

One of the biggest challenges when working with Luma Bridge is configuring the routing layer correctly. Running two systems under the same domain — EDS with its own routing logic, and Adobe Commerce with its traditional controller-based architecture — means incoming requests must be intelligently routed to different backends depending on the URL structure or path.

In Adobe Commerce Cloud, this is relatively straightforward: Fastly is available out of the box and allows you to define routing rules at the edge, forwarding requests to the appropriate origin based on path patterns, headers, or other conditions.

In self-hosted or custom infrastructure setups, this responsibility shifts entirely to your own CDN or reverse proxy layer (e.g., Cloudflare, Akamai, or Nginx). You must explicitly:

• Configure routing rules to split traffic between EDS and Adobe Commerce origins
• Ensure consistent caching behaviour across both systems
• Carefully handle edge cases such as redirects, cookies, and authenticated sessions

A well-designed CDN configuration is not an afterthought — it is a critical architectural component that directly impacts performance, cache efficiency, and overall system stability.

Scope and Constraints

Supported configurations:

• EDS + Adobe Commerce Optimizer (ACO) + PaaS deployments
• Storefronts using the standard authentication and cart drop-ins from Adobe's Commerce Boilerplate

Not applicable to:

• PWA Studio or Vue Storefront implementations
• Custom headless front ends outside the EDS ecosystem

Domain alignment is a hard requirement. If your current infrastructure doesn't support running both applications under the same top-level domain, that work needs to be scoped and budgeted before anything else.

Production Reference:

German Financial Services Provider

A German financial services institution running Adobe Commerce on-premise — driven by compliance and security requirements — needed a modern storefront for a precious metals e-commerce offering without migrating their core transactional infrastructure.

Architecture:

• EDS handles the product catalog and browsing experience
• Adobe Commerce handles checkout, customer accounts, and order management, remaining entirely within the on-premise environment
• Luma Bridge maintains session continuity at the domain boundary

Integrations: A regional payment provider and a bespoke precious metals trading system — both integrated on the Adobe Commerce side, requiring no changes to accommodate the new EDS front end.

Outcome: The MVP launched with a Lighthouse performance score of approximately 95/100. The client's compliance posture and existing backend customizations were preserved intact.

Practical Considerations

• Domain architecture is a prerequisite. Same top-level domain is non-negotiable; plan DNS and infrastructure work accordingly.
• Backend PHP competency is required. Module installation, configuration, and maintenance are standard Magento backend work — this is not a purely front-end engagement.
• Existing checkout customizations survive. Luma Bridge doesn't touch your PHP checkout; it only ensures the session arriving there is valid. Audit your customizations, but they should carry through.
• Treat it as a migration pathway, not a target architecture. The phased approach it enables is the point — teams that plan the subsequent checkout migration up front will get the most out of it.