When a multi-brand retailer operating 80+ locations with six distinct brand identities decided to unify their digital commerce infrastructure, the initial project estimate from their previous agency was 18 months. They were 9 months in with virtually nothing in production when they brought in a new team to salvage the initiative.
The rescue engagement delivered a unified omnichannel platform across all six brands in 11 months — with 94% of milestone deliveries landing on or before their committed dates. This is the operational story of how that reliability was achieved despite the complexity of multi-brand, multi-location commerce unification.
The Starting Situation
The retailer operated six distinct consumer brands, each with its own eCommerce platform, point-of-sale system, inventory management approach, and fulfillment workflow. Customers couldn’t buy online and return in-store. Inventory wasn’t shared across channels. Loyalty programs were brand-siloed. The customer experience was fractured in ways that directly impacted revenue — an estimated $12M annually in lost cross-brand sales and preventable returns.
The previous development team had attempted a “big bang” migration: replace everything simultaneously with a unified Magento 2 multi-store deployment. Nine months in, they had an elaborate staging environment that worked in isolation but couldn’t survive integration testing with the retailer’s actual ERP, warehouse management system, or POS hardware.
Core problems with the failed approach included no phased delivery plan (everything depended on everything else being complete), no integration testing until the final phase, architecture decisions made without validating against actual production data volumes, and no mechanism for delivering business value incrementally during the build.
The Restructured Approach
The rescue team — a combined squad of Bemeir’s Magento performance specialists and the retailer’s internal IT team — restructured the entire initiative around one principle: every 4-week sprint delivers something to production that creates measurable business value.
This wasn’t just a feel-good agile mandate. It was a delivery architecture decision. The system had to be decomposable into independently deployable components, each of which improved some aspect of the omnichannel experience without requiring the entire platform to be complete.
Phase 1 (Months 1-3): Unified Inventory Layer — Built a real-time inventory aggregation service that consumed feeds from all 80+ locations and the central warehouse. This single service immediately enabled “check store availability” on all six brand websites — a feature generating revenue from day one without touching the existing eCommerce platforms.
Phase 2 (Months 3-5): Order Management Unification — Implemented Fluent Commerce as the unified OMS, initially handling only web orders with ship-from-store fulfillment. Each brand migrated onto the OMS independently over rolling 2-week windows, reducing risk and allowing the team to address integration issues brand-by-brand rather than simultaneously.
Phase 3 (Months 5-8): Commerce Platform Migration — Migrated all six brands onto a unified Magento multi-store deployment with Hyvä frontend, rolling one brand per month. The unified inventory and OMS layers were already proven in production, eliminating the integration risk that killed the previous attempt.
Phase 4 (Months 8-11): Advanced Omnichannel Capabilities — BOPIS (buy online, pick up in store), cross-brand returns, unified loyalty, and store-associate selling tools. These features were only possible because the foundational layers were already stable and proven.
What Enabled 94% On-Time Delivery
Four operational practices drove the delivery reliability:
Integration testing from sprint one. The team never wrote integration tests against mocked systems. From the first sprint, tests ran against actual ERP feeds, actual POS API endpoints, and actual warehouse management system responses. This surfaced integration surprises in week 2, not month 9.
Rolling deployments with automatic rollback. No “launch day” for any component. Everything deployed during business hours with traffic gradually shifted from old to new systems. If error rates spiked, traffic automatically reverted. This eliminated the deployment-day panic that cascades into timeline slippage when things go wrong.
| Delivery Metric | Previous Team | Rescue Team |
|---|---|---|
| Milestone on-time rate | ~40% | 94% |
| Integration defects per sprint | 15-20 (caught late) | 2-3 (caught immediately) |
| Time from code complete to production | 4-6 weeks | 2-3 days |
| Production incidents post-deploy | 8-12 per brand launch | 1-2 per brand launch |
| Business value delivered in first 90 days | $0 (nothing in production) | $2.1M (availability feature) |
Explicit dependency mapping and critical path management. Every task tracked its dependencies visually. When a dependency was at risk, the team had 2-3 weeks of lead time to adjust scope, sequence, or staffing rather than discovering blockers the day work was supposed to start.
Scope negotiation, not scope creep. When new requirements emerged (and they always do), the team presented explicit trade-offs: “We can add cross-brand gift cards to this sprint, but unified loyalty points moves to next sprint.” Stakeholders made informed priority decisions rather than the team silently absorbing scope expansion until timelines broke.
The Inventory Synchronization Challenge
The most technically complex component was real-time inventory synchronization across 80+ locations. Each location’s POS system published inventory change events at different frequencies, in different formats, with different reliability guarantees. Some locations had network outages lasting hours. The central ERP performed batch inventory reconciliation overnight, sometimes overwriting real-time updates.
The solution used an event-sourcing pattern with conflict resolution: every inventory change event from every source was stored with a timestamp and source priority. When conflicts occurred (POS says 3 units, ERP says 5 units), explicit resolution rules determined the authoritative count based on source, recency, and transaction type.
This architecture handled 12,000+ inventory change events per minute across all locations during peak trading periods without degradation. More importantly, it was observable — when a location’s POS stopped sending events (indicating a connectivity issue), automated alerts fired and the system gracefully degraded to using the last-known count plus a safety buffer rather than showing stale data.
Lessons for Enterprise Omnichannel Teams
The reliability achieved on this project wasn’t due to heroic effort or extraordinary talent — it was due to structural decisions that made reliable delivery the path of least resistance:
Decompose before you build. Any omnichannel initiative that can’t be broken into independently valuable phases is an architectural design failure, not a project management failure. If your platform requires everything to be complete before anything works, go back to the architecture whiteboard.
Test integrations immediately and continuously. The most expensive bugs in omnichannel projects are integration bugs discovered late. Invest in integration test environments that mirror production data volumes and run them on every code change.
Deploy continuously, launch deliberately. Separating deployment (code reaches production) from launch (customers experience the change) gives you a pressure valve that prevents deployment anxiety from accumulating into massive, high-risk release events.
Measure value delivery, not just feature completion. A feature that’s “done” but not creating business value is inventory, not progress. Structure your delivery plan so that every sprint moves a business metric, not just a Jira board.
The retailer now operates a unified omnichannel platform processing $180M annually across all six brands and 80+ locations. Returns processing time dropped from 12 minutes average to 90 seconds. Cross-brand discovery increased average order value by 23%. And the platform team ships new features weekly with confidence — because the delivery architecture supports reliability as a default, not an exception.
