Charting the Path from 20-Year Legacy Ecosystem to Composable Commerce
Global Commerce Operator
The Situation
A global commerce operator with a presence in more than twenty countries and over two hundred operating locations came to Black Magic through a delivery partner. The business was embarking on a broad digital transformation, moving from a traditional retail model toward a mobile-first, digital-first footprint.
Two decades of organic growth had left the client with a tangled ecosystem: on-site infrastructure, cloud-based backend workflow systems, in-house applications, and purchased tooling stitched together over many cycles. Systems of record were fragmented. The same concept (a product, a transaction state, a location) lived in several places with inconsistent vocabulary and no single authoritative source. Business-critical state was often recalculated on every API call because no system actually owned it.
The client needed an honest enterprise architecture assessment, a forward-looking target architecture that was implementable, and a phased transformation plan that didn’t require a rip-and-replace the business couldn’t survive.
The Approach
Rather than treating this as a pure architecture exercise, we framed the engagement around three sequential phases the client could actually execute against.
Phase 1 asked the foundational question: what is a product? Before any platform selection can hold up, the business has to agree on what it actually sells, how catalogs are structured across hundreds of locations, and where the SKU boundaries lie. We documented the current definitions, surfaced the inconsistencies, and proposed a canonical product model that could scale across the full location footprint while giving each site the autonomy to manage its own catalog.
Phase 2 was the eCommerce engine selection and target architecture. We recommended Elastic Path Commerce Cloud (EPCC) as the headless commerce core and designed the surrounding architecture around it. The target design included:
One EPCC catalog per operating location (approximately two hundred catalogs), each with a location-specific hierarchy and SKU set, so regional teams could manage their own inventory without contending with a single monolithic catalog.
A custom Cart extension, implemented via EPCC Flows, to associate each Cart Item with a specific Media Item ID, enabling accurate fulfillment and preview rendering during the buy flow.
A new API layer on AWS (Spring Boot on EC2 with an ASG and ALB) to front both EPCC and existing legacy services, using the facade pattern as a deliberate transitional architecture rather than an end state.
A React front end, ideally sharing a code core with the existing kiosk React application to avoid divergent implementations of the same flows.
Native support for twelve currencies and five or more languages, matching the client’s global footprint.
Braintree and PayPal payment integrations, keyed off EPCC order orchestration.
Phase 3 was the transformation plan. This is where most assessments fall over. We identified which downstream systems, teams, and processes the transformation would impact, sequenced the work to minimize business risk, flagged the known risks and dependencies, and wrote justifications for every major recommendation so engineering leaders could defend the architecture inside the organization long after we’d stepped away.
Two Design Calls Worth Highlighting
A new system of record for a critical state. “Is this item available for sale and delivery?” was the most expensive question in the client’s system, and no service actually owned the answer. We designed a dedicated fast-path service with a simple state flag, allowed it to call back to legacy systems during Phase One, and defined the write paths so every state transition would flow into the new service as it matured. A straightforward CRUD API, backed by clear ownership semantics, replaced a complex amalgamation of data across multiple systems.
Event-driven pipelines to the warehouse. The client’s BI team ran on Snowflake and could not lose continuity of key reports at cutover. We designed EPCC to emit events to an SQS queue, a fleet of Lambdas (NodeJS or Micronaut depending on shared-code needs) to transform and enrich, and S3 as the staging layer before Snowflake pipelines ingested. Asynchronous, serverless, operationally cheap.
Deliverables
An enterprise architecture assessment covering all major cloud and on-site systems
A Phase One target architecture document with application-level and data-level design
C4 model architecture diagrams at system, container, and component levels
A proposed business-wide entity relationship model to replace fragmented definitions
Event payload specifications for the EPCC integration
Payment and product workflow specifications
A sold/unsold media state model with recommended implementation
A three-phase transformation plan with sequencing, risks, and justifications
What Made It Land
Enterprise architecture work fails when it’s written for the architect and not for the people who have to implement it. We wrote for engineering leads, platform owners, and the executives signing off on budget. Every recommendation came with the “why,” and every piece of the target architecture mapped to a specific existing system it was replacing or augmenting.
We also resisted the urge to over-design. A facade API layer is not beautiful, but in a twenty-year legacy environment it’s often the bridge that lets the business keep shipping while the new world is being built underneath. Calling that out explicitly, rather than pretending the cutover would be clean, was part of why the plan was credible.
The Takeaway
Digital transformation at scale isn’t a platform decision, it’s an ordering problem. Which systems get replaced first, which get wrapped, which get retired, and in what sequence: that’s the actual work. Black Magic brings deep enterprise architecture experience and a bias toward pragmatic, defensible transformation plans that engineering teams can actually ship.
If your organization is staring down a legacy ecosystem and trying to find a path to Elastic Path, Snowflake, and a modern AWS-backed composable commerce stack, that is the kind of engagement we’re built for.