For most enterprise commerce teams running Salesforce Commerce Cloud (formerly Demandware) or SAP Commerce Cloud (Hybris), the question is no longer whether they will leave the monolith, but when. Licence renewal cliffs, ageing on-premise Hybris estates approaching end-of-life, and the compounding cost of every customisation on a tightly coupled platform have turned replatforming from a strategic ambition into an operational inevitability.
This guide is deliberately practical. It is about the concrete journey off Salesforce Commerce Cloud or SAP Hybris and onto Elastic Path — the assessment work, the migration patterns, the data, the SEO risk, and the team you need to do it without a high-stakes weekend cutover. If you are weighing the broader business case, we cover that in our piece on the total cost of ownership of composable versus monolithic platforms; here we assume the decision is made and the real question is how.
Why the decision to replatform to Elastic Path arrives now
Three forces tend to converge and force the timing.
The first is the renewal cliff. Monolithic commerce contracts are typically multi-year, and the renewal conversation surfaces an uncomfortable truth: you are paying a percentage of gross merchandise value, or a steep platform fee, for software whose roadmap you do not control and whose flexibility you have long since exhausted. When the next renewal lands, finance asks whether there is an alternative — and there is.
The second is end-of-life pressure. SAP has set out timelines for Commerce Cloud and the older on-premise Hybris versions, and many organisations are running customised B2B or B2C storefronts on releases that are no longer comfortably supported. A forced upgrade to stay current is, in effort terms, often comparable to a replatform — but it buys you more of the same architecture rather than a way out of it.
The third, and most corrosive, is the cost of change on a monolith. On Salesforce Commerce Cloud, business logic lives in cartridges and controllers that are difficult to test in isolation. On Hybris, the OCC layer, impex imports, and a sprawling Spring configuration mean a small catalogue rule change can require a full regression cycle. Every customisation you added to differentiate has quietly become a tax on every future release.
When you decide to replatform to Elastic Path, you are choosing a composable, MACH-aligned (Microservices, API-first, Cloud-native, Headless) architecture. Elastic Path Commerce Cloud gives you product experience management through PXM, a dedicated Cart and Checkout service, and Composer for event-driven integrations — all consumed through APIs rather than embedded in a storefront codebase. That architectural shift is exactly what makes the migration approachable, because it lets you move in pieces.
Discovery and assessment: catalogue what you actually have
The single biggest cause of replatforming overruns is starting the build before you understand the estate you are leaving. A disciplined discovery phase pays for itself many times over.
Aim to produce three inventories.
Customisations. On Salesforce Commerce Cloud, audit every cartridge, every controller and pipeline, every Business Manager extension, and every job. On Hybris, catalogue your custom extensions, the data model deviations from the accelerator, custom impex flows, and any bespoke OCC endpoints. For each item, record what business capability it serves, whether that capability is still used, and whether Elastic Path provides it natively, via Composer, or whether it needs a custom microservice. A surprising proportion of monolith customisation turns out to be either dead code or functionality the new platform offers out of the box.
Integrations. Map every system the platform talks to: ERP (commonly SAP S/4HANA or NetSuite), the OMS, payment service providers, tax engines, the search and merchandising provider, the CDP or marketing stack, and any PIM that feeds product data. For each, document the direction of data flow, the protocol, the volume, and the latency tolerance. These integration points become the contract your new architecture must honour, and they often dictate sequencing.
Data. Profile the catalogue (products, variants, bundles, categories, assets), customer accounts and address books, pricebooks and price lists, promotions, and order history. Measure volumes and, critically, quality — duplicate SKUs, orphaned variants, inconsistent attribute usage, and encoding issues are far cheaper to confront now than mid-migration.
The output of discovery is a capability map that aligns each existing function to its Elastic Path destination, a prioritised integration list, and a data-quality remediation backlog. This is also where you decide your migration pattern.
Migration pattern: strangler-fig versus big-bang
There are two honest ways to replatform, and the difference matters enormously for risk.
A big-bang cutover rebuilds the full experience on Elastic Path and switches all traffic over at a single planned moment. It is conceptually simple and avoids the cost of running two platforms in parallel, but it concentrates all risk into one event. For a high-revenue site, a failed cutover is measured in lost orders per minute, and the rollback path is rarely as clean as the plan assumes. Big-bang can be defensible for smaller catalogues, single-brand sites, or where the legacy platform is genuinely about to go dark.
For most enterprise replatforms, the strangler-fig pattern is the safer and more pragmatic route. Named after the fig that grows around a host tree until it can stand alone, the pattern incrementally diverts functionality from the monolith to the new platform until the legacy system has nothing left to do and can be retired. You never have a single do-or-die moment; instead you have a sequence of small, reversible releases.
The enabling mechanism is an edge routing layer. You place a proxy or edge worker (a CDN edge function, an API gateway, or a reverse proxy) in front of both the legacy platform and the new Elastic Path-powered storefront. Routing rules then decide, per request, which system serves it. You might begin by routing a single category, one brand, a specific geography, or a percentage of traffic to the new stack while everything else continues to hit Salesforce Commerce Cloud or Hybris. As confidence grows, you widen the rules. Crucially, the customer never sees a domain change, and you can dial traffic back instantly if a release misbehaves.
A common, lower-risk first slice is read-heavy and SEO-sensitive but transactionally simple — product detail and category pages rendered against Elastic Path PXM — while cart, checkout, and order placement temporarily continue on the legacy platform. You then strangle the transactional path once the catalogue experience is proven. Sequencing the high-traffic, low-complexity surfaces first lets the team build operational muscle before touching the parts where mistakes cost orders.
Migrating the data: catalogue, customers, pricebooks, and order history
Data migration is where timelines quietly slip, so treat it as a workstream in its own right rather than a task at the end.
Catalogue and PIM. Elastic Path PXM is the destination for product data, and it models products, variations, hierarchies, and bundles richly. Map your Salesforce Commerce Cloud catalogue (master and site catalogues, variation attributes, shared variation attributes) or your Hybris classification system and category trees onto the PXM model. This is rarely a one-to-one transfer; the data-quality remediation identified in discovery happens here, and it is the natural moment to consolidate attributes and retire dead SKUs. If you operate a separate PIM upstream, decide whether it remains the source of truth feeding PXM via Composer, or whether PXM absorbs the role.
Customers. Migrate accounts, address books, and B2B account hierarchies. Passwords cannot be migrated in plaintext, so plan for either a hashed-credential import where formats are compatible, or a transparent re-authentication or password-reset flow on first login. For B2B, the account-to-buyer relationships and any contract pricing entitlements need careful mapping.
Pricebooks and price lists. Translate Salesforce Commerce Cloud pricebooks or Hybris price rows into Elastic Path price lists and pricing rules, preserving currency, customer-segment, and tiered/volume pricing. Promotions and discounts often have to be re-expressed rather than copied, because the rules engines differ; budget design time for this.
Order history. Decide deliberately how much history to move. Customers expect to see recent orders, but migrating ten years of order records into the live transactional system is usually unnecessary and risky. A common approach is to migrate a recent window (say, 12–24 months) into Elastic Path and keep older history in an archive or read-only service that the account area can query, rather than burdening the new platform with cold data.
Run the migration as repeatable, idempotent ETL jobs, not hand-crafted one-offs. You will run them many times — against sandbox, then staging, then production — and you want a reconciliation report after each run that proves counts and key totals match the source. Dry runs against production-scale data are the only reliable way to discover the long-tail data problems before go-live.
Preserving SEO and URLs through the transition
For any established commerce site, organic search is hard-won and easy to destroy. A replatform that quietly changes URL structures or drops metadata can erase years of ranking equity in weeks, so SEO preservation is a first-class requirement, not a post-launch fix.
Start by crawling the existing site to produce a complete inventory of indexed URLs, their current status codes, canonical tags, and the organic traffic and revenue attributed to each. This baseline is what you protect.
Wherever possible, keep URLs identical on the new storefront. The composable architecture gives you full control of routing in the frontend, so there is no technical reason the Elastic Path-powered storefront cannot serve /category/product-slug/ exactly as before. Where a URL genuinely must change, implement 301 redirects from the old URL to the new one — never 302s for permanent moves — and maintain a redirect map as a managed artefact. The edge routing layer is the natural place to enforce these redirects consistently across both old and new systems during the transition.
Beyond URLs, carry over title tags, meta descriptions, canonical tags, structured data (product, breadcrumb, and review schema), hreflang annotations for international sites, and XML sitemaps. Because the strangler-fig pattern moves traffic gradually, you can monitor Search Console coverage, crawl stats, and rankings on each migrated slice before widening, catching any regression while it is still small. That incremental visibility is one of the strongest SEO arguments for avoiding a big-bang cutover.
Running old and new in parallel
The strangler-fig approach means, by definition, a period where both platforms are live and serving real customers. Managing that parallel-running phase well is what keeps the migration boring — which is the goal.
Two concerns dominate. The first is data consistency. While cart and checkout straddle two systems, inventory, pricing, and order state must stay coherent. Designate a single source of truth for each data domain — typically the ERP or OMS for inventory and the new platform for newly placed orders — and use event-driven synchronisation through Elastic Path Composer so changes propagate rather than drift. Avoid a situation where both platforms believe they own the same data.
The second is operational observability. With an edge layer splitting traffic, you need unified monitoring across both stacks: error rates, latency, conversion, and order success measured per route so you can compare the new experience against the legacy baseline. Define clear rollback criteria in advance — if checkout success on a migrated slice drops below the legacy benchmark, traffic reverts automatically or at the press of a button. Parallel running costs money, because you are paying for two platforms at once, but that overlap is the premium you pay to eliminate cutover risk, and it should be planned and time-boxed rather than open-ended.
A phased roadmap with gates
A replatform of this scale is a multi-quarter programme. Phasing it with explicit gates keeps it controllable and gives stakeholders honest decision points.
Phase 0 — Discovery and foundations (4–8 weeks). Complete the customisation, integration, and data inventories. Stand up Elastic Path environments, establish the capability map, and build the SEO baseline. Gate: an agreed migration approach, scope, and budget envelope.
Phase 1 — Architecture and first slice (6–10 weeks). Build the edge routing layer, the frontend foundation, and the first integrations (typically catalogue from PXM, plus search). Migrate catalogue data into a sandbox and prove the ETL. Route a small, SEO-sensitive but transactionally simple slice — a category or brand — to the new stack. Gate: the first slice performs at or above the legacy baseline on speed, SEO, and stability.
Phase 2 — Transactional capability (8–12 weeks). Bring Cart and Checkout, payments, tax, and the OMS/ERP order flow onto Elastic Path. Migrate customers and pricebooks. Expand routing to more of the catalogue. Gate: end-to-end order placement on the new platform matches legacy conversion and order accuracy.
Phase 3 — Scale-out and parity (ongoing). Progressively strangle the remaining functionality — promotions, B2B account features, content, personalisation — widening the routing rules until the new platform serves the majority of traffic. Gate: feature parity confirmed against the agreed scope.
Phase 4 — Decommission (2–4 weeks). Route the last traffic across, archive residual order history, finalise the redirect map, and retire the legacy platform — ending the parallel-running cost. Gate: zero traffic on the legacy stack for an agreed soak period.
Treat these durations as illustrative shapes rather than commitments; the actual numbers depend entirely on catalogue size, integration count, and the depth of legacy customisation surfaced in discovery.
Team shape and honest cost guidance
A replatform is delivered by a cross-functional team that stays stable across the programme rather than a rotating cast. The core typically includes a programme lead or product owner who owns scope and the gate decisions; a solution architect responsible for the target architecture and the edge layer; backend engineers for Elastic Path configuration, Composer integrations, and custom microservices; frontend engineers for the headless storefront; a data engineer owning the migration ETL and reconciliation; a DevOps engineer for environments and observability; and a technical SEO specialist who is engaged from Phase 0, not called in afterwards. On the client side, you need empowered business owners for merchandising, finance, and operations who can make decisions without long approval chains.
On cost, be honest with stakeholders from the outset. The Elastic Path licence is usually the smaller part of the total; the larger investment is the implementation effort, the integration rebuild, and the parallel-running overlap. Discovery is comparatively cheap and de-risks everything after it, so resist the temptation to compress it. The compensating return is real: the elimination of monolith licence escalation, dramatically lower cost of change once you are on composable architecture, and the ability to evolve individual capabilities without full-platform regression. Framed over a three-to-five year horizon, the replatform typically pays back not through the licence line alone but through the reclaimed velocity of every change you make afterwards.
How McKenna Consultants can help
McKenna Consultants is a UK-based software development consultancy with over 25 years of engineering experience, and we deliver Elastic Path replatforms for organisations leaving Salesforce Commerce Cloud and SAP Hybris. We run the discovery and assessment that turns an ambiguous monolith into a clear capability map, design the edge routing layer that makes incremental migration safe, build the Composer integrations to your ERP, OMS, payment, and search systems, and own the data migration and SEO preservation that protect your revenue through the transition.
If you are facing a licence renewal, a Hybris end-of-life deadline, or simply the rising cost of changing anything on your current platform, we would welcome a conversation about what a phased move to Elastic Path could look like for your business. Get in touch to arrange an initial discovery discussion with our Composable Commerce team.
