Multi-Platform Consolidation
One group, four platforms, zero shared view.
A retail group running several brands often ends up running several commerce platforms — Adobe Commerce for one, a legacy Java stack for another, Shopify for a third, each with its own CMS and its own OMS/WMS/ERP wiring. Nothing ships because every change touches four systems. This is what actually consolidating that estate looks like.
Why estates sprawl
Nobody chose this mess on purpose.
Every platform in the estate was a rational local decision. The irrational part is what four rational decisions add up to five years later.
Acquisitions
Each brand arrives with its own commerce stack. Folding a JSP monolith and an Adobe Commerce instance into one company doesn't fold their platforms — that happens later, if ever.
Brand autonomy
A brand team wins the right to run its own storefront because the shared platform was too slow to ship its launch. Reasonable in the moment, expensive by year 3.
The campaign platform that stayed
A CMS or storefront gets stood up for one seasonal campaign, ships on time, and nobody schedules the decommission. Five years later it's load-bearing.
Vendor-driven fragmentation
One brand's agency prefers Salesforce Commerce Cloud, another's prefers Shopify. Each choice was locally correct — nobody owned the sum.
The real cost
The cost compounds every quarter it's deferred.
Not a vague productivity tax. The sprawl shows up as specific, measurable drag on every roadmap item that touches more than one brand.
Same change, four platforms
A promo-eligibility rule or a tax update gets implemented once per platform, by different teams, on different release calendars — and drifts the moment one ships late.
Integration count vs. platform count
Every platform that talks to OMS, WMS, ERP, and CDP adds its own point-to-point wiring. Add a platform and the integration surface doesn't grow linearly — it grows against every existing system it needs to reach.
Single view of inventory
Stock sits in four systems of record with four sync cadences. No one can answer 'what do we have, right now, across brands' without a manual reconciliation.
Estimates stop meaning anything
A feature that touches checkout on one platform is a two-week job. The same feature across four platforms is a four-team negotiation, and nobody can say how long that takes.
“We stopped being able to estimate anything that touched more than one brand — every feature became a negotiation between four teams before it became a build.”
Deciding what consolidates
Five questions decide it, not intuition.
Consolidation is not a religion. Some brands genuinely need their own storefront, and forcing them onto shared infrastructure trades one kind of pain for another.
Catalog and pricing overlap
If two brands sell materially the same product types under the same pricing logic, a shared catalog and pricing engine removes real duplication. If SKUs, attributes, and price books barely overlap, sharing them creates coupling with no payoff.
Fulfilment shape
Brands shipping from the same DCs on the same carriers belong on a shared order and inventory spine. A brand with its own 3PL and SLAs is a different fulfilment problem, not just a different frontend.
Regulatory or market separation
A brand selling into a regulated category, or into a market with local data-residency or tax rules, often needs its own storefront and checkout regardless of how similar the catalog looks.
Revenue at risk during the move
The brand earning the most per hour of downtime is not where consolidation starts. Sequence by how much room there is to be wrong.
Team ownership
A brand team that built and defends its own platform is a stakeholder, not a migration target. Consolidating without their buy-in produces a program that technically ships and politically fails.
Consolidation patterns
Pick the target, then the seam.
Four ways to get from sprawl to a single system of record, in order of how fast they concentrate risk versus how fast they pay off.
Target-platform migration
Pick one commerce engine and move every brand onto it as separate storefronts. Fastest to a single system of record; highest short-term migration cost, and the target platform has to genuinely fit every brand's catalog and fulfilment model.
Shared core, thin brand fronts
One commerce engine, multi-storefront, each brand's frontend free to diverge in presentation. Catalog, pricing, identity, and orders live once; brand identity lives in the frontend layer, not the backend.
Shared services behind an anti-corruption layer
Leave each platform's commerce engine in place, but extract catalog, pricing, identity, and orders into services that every platform reads through a translation boundary. Slower to full consolidation, lowest risk per step.
Strangler fig, brand by brand
Whichever target pattern is chosen, cut over one brand's traffic at a time behind the anti-corruption layer, prove parity, then move the next. The legacy platform for each brand keeps running until its last route moves.
The anti-corruption layer is the same seam used in legacy system modernization — the difference here is the seam has to hold for four platforms at once, not one. Microsoft's reference writeups on the anti-corruption-layer pattern and strangler fig are the two patterns worth reading before scoping this.
The staged-migration pattern is how we moved a national gifting brand off JSP templates fronting an IBM CMS, brand section by brand section, onto React and then Next.js micro-frontends — migrated paths now score 90+ on Lighthouse, with the legacy stack still serving sections that hadn't migrated yet. The shared-services pattern is closer to how we run embedded engineering for a luxury retailer whose storefront, headless content layer, and Java integrations span Salesforce Commerce Cloud and Adobe Experience Manager at once.
Sequencing
The second brand should be cheaper than the first.
- 01Brand one
Smallest revenue, richest edge cases
Start with the brand that has the least to lose if something goes wrong, but enough real complexity in its catalog, pricing, and fulfilment to force the shared services layer to be genuinely general — not a special case dressed up as an abstraction.
- 02In parallel
Product identity and integration inventory, group-wide
While brand one's cutover runs, reconcile SKUs across every brand and inventory every point-to-point integration in the estate. Both are prerequisites for every later brand and don't depend on brand one finishing first.
- 03Brand two
The delta is the proof
If the shared services layer built for brand one was actually shared, brand two's cutover needs a fraction of the net-new integration work. If brand two costs almost the same as brand one, the layer wasn't shared — it was rebuilt per brand with extra steps.
Data unification
One product, one customer, one order state.
Orders and inventory carry the most cross-brand value, and the most risk if they drift. Identity carries the most legal exposure if it's done sloppily.
Product identity
Reconcile SKUs across brands to a shared identifier before anything else moves. GS1's GTIN standard is the reference point most enterprise catalogs already use for cross-system product identity — extend it, don't reinvent it.
Customer identity and consent
A shared customer record across brands needs a single consent and marketing-preference model, not four. Get legal and privacy involved before the first brand's customer data crosses the boundary — retrofitting consent is worse than designing it in.
Orders and inventory as the spine
These two entities carry the most cross-brand value and the most operational risk if they drift. Stream them via change-data-capture — Debezium is the common open-source reference implementation — instead of nightly batch syncs that are always a day stale.
Where duplication is fine
Brand-specific content, merchandising rules, and promotional copy don't need a shared model. Forcing every brand's marketing team through one CMS schema to satisfy a consolidation program is optimizing the wrong layer.
Reference points worth reading before scoping the data model: GS1's GTIN standard for cross-brand product identity, and Debezium for change-data-capture patterns that keep orders and inventory current without batch sync lag.
What actually breaks
Six failure modes, named.
Not the technology. The technology is usually the easy part. These six show up in nearly every consolidation program, in some order.
The brand team that never agreed
A brand's platform ships from a team with headcount, a roadmap, and a P&L tied to it. If they experience consolidation as something done to them, the program gets slow-walked from inside — tickets stall, sign-offs take weeks, nobody escalates the blocker.
Pricing and promo rules that were never written down
The rules live in whatever the legacy platform's code happens to do. Migrating without extracting them first means re-discovering edge cases in production, usually during a promotion, usually the expensive way.
SEO cannibalisation at cutover
Two brands consolidating onto shared product pages can end up competing for the same search terms instead of each ranking independently. URL strategy and canonicalization need a decision before cutover, not after rankings drop.
The integration nobody owns
A point-to-point feed into ERP or WMS that predates everyone currently on the team. It works, nobody understands why, and it's the one thing that breaks during the first shared-services cutover because no one tested against it.
The 'temporary' platform that outlives the program
A brand gets a deadline extension, then another. Eighteen months later its legacy platform is still live, still needs security patches, and the consolidation program is paying to maintain the thing it was supposed to retire.
Sequencing by politics, not risk
The loudest brand goes first because they asked first, not because they're the safest starting point. The result is the highest-risk brand absorbing the least-proven playbook.
“The pricing rules were never a document. They were whatever the JSP templates happened to do, and we only found the exceptions when a promotion hit them in production.”
The honest take
When to consolidate — and when to leave it alone.
We sell consolidation. We also tell buyers when keeping brands separate is the right call. The question is which fits the group in front of us, not which we prefer.
When to consolidate
Catalog, pricing, and fulfilment genuinely overlap
Shared infrastructure removes real duplicated work instead of forcing brands into a model that doesn't fit them.
The integration count is the actual bottleneck
If every roadmap item stalls on "which four systems does this touch," the shared spine pays for itself in estimate accuracy alone.
Leadership can fund the second brand
Consolidation that stops after one brand is a rewrite with a bigger blast radius, not a consolidation. Budget for at least two.
When to leave brands separate
A brand's revenue model depends on independence
If a brand's roadmap speed is a competitive advantage, coupling it to a shared release calendar can cost more than the integrations it would save.
Regulatory separation is non-negotiable
A regulated brand's storefront and checkout may need to stay isolated regardless of how much catalog overlap exists elsewhere in the group.
The group is still deciding which brands it keeps
Consolidating platforms ahead of a portfolio decision means re-doing the consolidation when a brand is sold or shut down.
Three shapes, compared
Same goal, different risk curve.
| Dimension | Single platform, multi-storefront | Shared core, brand fronts | Leave separate |
|---|---|---|---|
| Time to single system of record | Fastest — one cutover per brand onto the same engine | Slower — services extracted incrementally, engines stay put | Never — by design |
| Per-brand release independence | Low — shared engine, shared release risk | High — each platform still ships on its own cadence | Full |
| Migration risk profile | Concentrated — each brand's cutover is a full replatform | Distributed — risk lands at the service boundary, not the whole stack | None from this program |
| Fit for divergent fulfilment models | Weak unless the target platform is chosen for the hardest case | Strong — fulfilment logic can stay platform-specific behind the layer | Full, by definition |
| Steady-state integration count | Lowest | Moderate — bounded by the services layer, not eliminated | Highest — grows with every new platform |
FAQ
Questions a CTO asks before committing budget.
How long before the second brand proves consolidation is working?
There's no universal number — it depends on the shared services built during brand one. The signal to watch is cost, not calendar time: the second brand's cutover should need materially less net-new integration work than the first. If it doesn't, the shared layer isn't actually shared yet.
Do we need to pick a single target commerce platform first?
No. Shared services behind an anti-corruption layer let each brand keep its existing engine while catalog, pricing, identity, and orders unify underneath. Picking one target platform is a separate, larger decision — see platform migration below.
What happens to brand-specific promotions during consolidation?
They stay brand-specific. Consolidation unifies the systems of record — catalog, pricing rules engine, orders, identity — not the merchandising decisions brands make on top of them. A shared pricing engine can still run brand-specific promotion sets.
Should the CMS consolidate along with commerce?
Only if the same overlap test applies — do the brands genuinely share content models and workflows, or does each brand's editorial team need independence more than the group needs one CMS. Content and commerce consolidation are separate decisions with separate criteria.
How do we handle a brand mid-way through its own replatform when the consolidation program starts?
Let it finish onto the target pattern rather than pausing it — a stalled replatform is worse than a slightly late-joining brand. Fold it into the shared services layer at its next planned release, not on the consolidation program's calendar.
What's the first deliverable, realistically?
A product-identity reconciliation across brands and a written inventory of every point-to-point integration touching each platform. Both are prerequisites for every pattern in this guide, and both surface the real scope before a commitment gets made.
Related
How an engagement starts
Three steps to a partnership
Intake call
30 minutes. We listen, you talk. No deck.
Diagnostic
We audit the surface, name the bottleneck, propose a path.
Kickoff
Senior engineer in your standup by week two.
Map the estate before you commit to a target
Tell us which platforms and brands are in scope. We'll come back with which pattern fits, which brand should go first, and what the shared services layer needs to hold.