The manufacturer in this anonymized case study had been in business since the early 1990s, sold mechanical components into industrial OEM channels, and was running a Magento 1 storefront that had been launched in 2014 and patched ever since. Three decades of part numbers, complex multi-level bills of materials, and customer-specific pricing all lived in a stack that vendors had stopped supporting. The replatforming question was not whether to move, but how to move in a way that would not put them in the same position again in eight years. This is the story of how the architecture decision was made, and which design choices preserved the most future optionality.
The Starting Position
The manufacturer’s existing stack had accumulated in layers. The product master was effectively split between an older ERP that handled production and an Excel-driven catalog the marketing team maintained for the website. Customer-specific pricing was managed in a homegrown middleware that synced from the ERP into Magento 1 nightly, with weekly full reloads when the deltas drifted. The site itself had a custom theme that no remaining team member fully understood, around 47 third-party Magento 1 extensions, and a checkout that had been heavily customized for net-terms billing, freight quoting at line level, and a quote-to-order workflow.
What worked: the dealer base used the site, ordering volume was substantial, and the company had a deep catalog (around 38,000 active SKUs, with another 60,000 in legacy/discontinued status). What did not work: every change took weeks, security patching was overdue, and Magento 1 had been past end-of-life for years. The risk profile was no longer acceptable to the board.
Assessment of Legacy Data
Before evaluating any new platform, Bemeir ran a six-week legacy data assessment. This was the most important early phase because the platform decision could not be made without knowing what data shape the new platform had to support. Three findings shaped everything that followed.
The product catalog had multi-level engineered BOMs going eight levels deep for some configured products. A single finished assembly might explode into 40 child components, some of which were also separately purchasable. The new architecture had to handle this without flattening it.
The customer pricing structure had roughly 4,200 distinct contract pricing agreements, ranging from simple volume discounts to per-SKU negotiated prices for 22 of the largest OEM accounts. Some contracts were renegotiated annually, others ran multi-year. The pricing engine had to handle this with full audit history.
The legacy part numbering had decades of accumulated cross-references, including superseded parts, regional alternates, and OEM-specific equivalents. Roughly 11 percent of incoming orders referenced legacy part numbers that mapped to current parts. The new system had to honor these references without polluting the active catalog.
Platform Options Analysis
Three platforms made the shortlist after the assessment: Adobe Commerce (the natural Magento upgrade path), BigCommerce B2B, and Shopware. Each was evaluated against the actual data model and business logic the manufacturer needed, not against feature-list demos.
Adobe Commerce had the deepest B2B feature set (company accounts, requisition lists, quote workflow, shared catalogs, negotiable quotes) and the most extensible pricing model. The downside was operational weight: the platform demands serious infrastructure and engineering discipline to run well, which favored a partner who specialized in it.
BigCommerce B2B offered faster initial deployment and lower platform overhead but the contract pricing complexity and BOM depth the manufacturer needed pushed beyond the platform’s native capabilities. Building custom logic on top would have moved a significant portion of the platform value out of the platform itself.
Shopware was strong on flexibility and had improved its B2B story, but the partner ecosystem in the US for the depth of integration this manufacturer needed was thinner than for Adobe Commerce, and the product team’s North American roadmap had less weight behind it for the specific B2B features required.
The decision was Adobe Commerce, with Hyvä as the storefront theme layer to address the performance and developer-experience concerns that had become structural problems in classic Luma-themed Magento builds.
Why Hyvä, Specifically
The Hyvä choice was not aesthetic. It was about preserving future optionality. Classic Magento frontends carry years of accumulated complexity (Knockout, RequireJS, multi-megabyte JavaScript bundles, fragile dependency chains) that make every change expensive. Hyvä replaces that with a leaner Tailwind plus Alpine stack that loads faster and is dramatically easier for engineers to work in. The Hyvä documentation covers the architectural rationale.
Practically, this meant that storefront performance, which had been a recurring issue on the legacy site, became a non-issue. Lighthouse scores moved from the low 30s on the legacy Magento 1 storefront to consistent high-80s/low-90s on the new Hyvä build, in line with the Web Almanac benchmarks for top-decile commerce sites. More importantly, future frontend changes (a new product configurator, a custom dealer dashboard widget) would no longer require an archeology dig through a tangled JavaScript stack.
Modular Architecture: Designing for Future Swap-Out
The most important architectural decision was not the platform choice. It was the deliberate decoupling of subsystems so that future replacement of any one of them would not force replacement of all of them.
The PIM became the canonical product source. The manufacturer adopted a dedicated PIM rather than letting product master data live in Adobe Commerce. The PIM owned the catalog, attribute taxonomy, BOM relationships, asset library, and translation data. Adobe Commerce subscribed to the PIM and rendered the storefront. This means that if Adobe Commerce is ever replaced, the catalog is portable. The Forrester commentary on PIM-led B2B architectures supports this pattern.
The OMS was abstracted behind a service layer. Order routing, inventory check, fulfillment selection, and shipment tracking were not coded directly into Adobe Commerce. They were exposed as services that Adobe Commerce called. Today those services are largely backed by NetSuite. Tomorrow they could be backed by a dedicated OMS without the storefront knowing the difference.
The pricing engine was built as a swappable module rather than entrenched in the platform’s native pricing tables. Contract pricing, volume tiers, and negotiated overrides ran through a custom Magento module that read from a denormalized rules store. The store could be replaced or migrated independently.
Hosting infrastructure was AWS-native and cleanly templated. Bemeir’s AWS practice built the hosting environment with infrastructure-as-code, auto-scaling, and a CI/CD pipeline that could be retargeted at a different platform if needed. This is the kind of foundation that AWS reference architectures describe for resilient B2B commerce workloads.
The Five-Year Horizon Decisions
Some decisions are made knowing that the answer will be different in three years. Designing for that explicitly is the difference between future-readiness and future-paralysis.
| Design Choice Now | Future Option Preserved |
|---|---|
| PIM as canonical product source | Replatform storefront without rebuilding catalog |
| OMS abstracted behind service layer | Swap NetSuite-backed services for dedicated OMS |
| Pricing engine as standalone module | Migrate pricing logic without storefront rewrite |
| Hyvä storefront theme | Storefront refresh without core platform replatform |
| AWS infrastructure-as-code | Move hosting providers or add multi-region without lift-and-shift |
| Adobe Commerce on supported version with patch discipline | Stay current on platform without falling into another EOL trap |
| Headless API surface published from day one | Add a separate native mobile app or B2B portal layer later |
| Identity managed in dedicated IdP, not platform-native | Replace platform without breaking dealer SSO |
| Documented integration contracts (PIM, OMS, pricing) | Each system replaceable independently |
The pattern is consistent: separate the parts of the architecture that change at different rates. Storefront frameworks change every few years. Core commerce platforms change every five to ten. ERPs and PIMs change every ten to fifteen. Designing the system so each layer can move on its own clock is the practical definition of future-readiness.
What the Manufacturer Got
Eighteen months after go-live, the manufacturer was running a stack that was meaningfully simpler to change than what it replaced, despite handling more SKUs and more complex pricing. Storefront performance had moved from a recurring complaint to a non-issue. Contract pricing changes that had taken three weeks on the legacy platform were taking under a day. The patch and security cadence was current.
More importantly, when the marketing team asked, in year two, about adding a customer-facing configurator for a new product line, the answer was not “we will need to rebuild a chunk of the storefront.” It was “we will add a new module against the PIM and the pricing engine, and the storefront will pick it up.” That is what future-readiness actually buys: the ability to say yes to the next thing without unbuilding the last thing.
The Underlying Lesson
Replatforming a 30-year-old manufacturer is not really a platform decision. It is an architecture decision dressed up as a platform decision. The manufacturers who get stuck again in eight years are the ones who picked a platform and let everything default into it. The ones who do not get stuck again are the ones who decided, deliberately, which subsystems were going to live where, and who built the contracts between them clearly enough that any one of them could be replaced without blowing up the rest. Bemeir’s experience across decades-old manufacturer replatforms is that the underlying lesson is always this one, and the platform name on the box is almost incidental compared to the discipline of the architecture beneath it.
