A mid-market US manufacturer of industrial components, roughly 380 employees, three production facilities, around 220 active dealers across the lower 48, came to Bemeir with a problem that is unfortunately typical. Their previous agency had pitched a six-month B2B portal build on Adobe Commerce. Twelve months in, the project was halfway done, the ERP integration was rewriting itself every sprint, and the dealer network was losing patience. This is the anonymized case study of how the project was reset and delivered, on a revised schedule, without descoping the integration. The names are changed, the numbers are real ranges from a representative engagement.
The Inherited Situation
When Bemeir was brought in for a discovery reset, three issues were obvious within the first week of code review and stakeholder interviews.
The first was that the ERP topology had never been fully mapped. The manufacturer ran NetSuite for finance and primary order management, a separate legacy MRP for production planning, and a third regional warehouse system at one of the three plants that had never been retired after an acquisition. The previous agency had treated NetSuite as the single ERP and built integrations against it. Half the inventory data the dealers needed was actually living in the legacy MRP and the regional WMS.
The second was that dealer-specific contract pricing was being calculated client-side. Each dealer had a tier (silver, gold, platinum), an annual volume override, a contract pricing schedule for around 18 percent of the catalog, and category-level minimum advertised price (MAP) rules that varied by sales channel. The previous build was attempting to replicate this logic in JavaScript on the storefront, recomputing on every page load, against a flat product feed.
The third was that there was no test data discipline. Sprint demos were running against production-cloned data that included real dealer pricing and personally identifiable contact information. There was no staging dataset that mirrored the edge cases (dealer with three ship-to addresses on different tax jurisdictions, dealer with paused account but pending order, etc.) that were causing intermittent failures.
Discovery Findings That Reset the Project
The reset discovery, run over five weeks with both Bemeir’s Magento engineering team and the manufacturer’s IT and dealer operations leads, produced a different scope.
There were not one but three ERP-class entities that needed to be integrated: NetSuite (orders, customers, invoicing, GL), the legacy MRP (production schedule, lead times by SKU, true available-to-promise), and the regional WMS (one-plant inventory and shipping logic). NetSuite was confirmed as the system of record for customer master and order, the MRP held authoritative ATP, and the WMS owned shipping for one-third of orders.
Contract pricing logic moved server-side, into a Magento custom module that ran the price calculation against a denormalized rules table refreshed nightly from NetSuite plus an event-driven update path for mid-day contract changes. MAP rules became a separate validation layer applied at cart and at quote.
Staged rollout replaced big-bang launch. The plan moved to three waves: pilot dealers (15 dealers, regional cluster, low-complexity contracts), regional rollout (about 90 dealers, full geographic spread), and full launch (remaining dealers including the highest-complexity national accounts).
Integration Architecture: The Foundation
The integration architecture document was the first deliverable, written before any further frontend work. It specified, for each data type, the system of record, the sync mechanism, the sync frequency, and the conflict resolution rule.
Customer master flowed one-way from NetSuite to Magento on an event-driven basis (NetSuite saved-search webhook to a middleware queue, Magento consumer pulled from the queue every minute). Inventory ATP was pulled fresh from the MRP on cart add and on checkout, with a five-minute cache for product list pages to avoid hammering the MRP under traffic. Orders flowed Magento to NetSuite synchronously at checkout submission, with a fallback queue if NetSuite was unavailable. Pricing was calculated in Magento against the denormalized contract rules. Shipping for the one plant on the regional WMS used a separate fulfillment routing that the OMS layer in NetSuite delegated to.
This kind of integration-first design is the practice Bemeir applies on every B2B Magento engagement, and it pays back the upfront discovery cost within the first two months of build because the data model stops changing under the team. The Adobe Commerce DevDocs on B2B integration patterns and the NetSuite SuiteTalk REST guidance informed the integration contract documents.
Test Data Discipline
A representative test dataset was constructed in the first sprint of the build phase: 25 synthetic dealers spanning every tier-and-contract combination, around 300 SKUs covering the active product taxonomy, eight tax jurisdictions, three shipping origins, and a defined set of negative-path edge cases (suspended dealer, expired contract, MAP violation attempt, partial backorder, etc.).
Every sprint demo ran against this dataset. Every automated test suite ran against this dataset. Production-cloned data was reserved for late-stage UAT and was anonymized for personally identifiable fields per NIST data handling guidance. The discipline cost about three weeks of dataset construction and saved an estimated eight to ten weeks of “phantom bug” debugging across the build.
Milestone Schedule: Plan vs. Actual
The reset project ran on a 32-week schedule from kickoff to full launch. Schedule discipline held within two weeks across the entire program.
| Milestone | Planned Week | Actual Week | Variance |
|---|---|---|---|
| Discovery and integration architecture sign-off | Week 5 | Week 5 | On time |
| Sprint 0 environments and CI/CD ready | Week 7 | Week 7 | On time |
| Customer and product data sync end-to-end | Week 12 | Week 13 | +1 week |
| Pricing engine with contract rules in staging | Week 16 | Week 16 | On time |
| Order placement to NetSuite end-to-end | Week 20 | Week 21 | +1 week |
| Pilot dealer go-live (15 dealers) | Week 24 | Week 24 | On time |
| Regional rollout (90 dealers) | Week 28 | Week 29 | +1 week |
| Full launch (220 dealers) | Week 32 | Week 33 | +1 week |
| Hypercare exit | Week 45 | Week 45 | On time |
Total program cost landed in a range typical for this scope, between $850K and $1.1M including discovery, build, integrations, hosting setup on AWS, and 12-week hypercare. That was modestly above the original (failed) project estimate the manufacturer had committed to, but it was the cost of the project that actually shipped, not the project that did not.
Staged Rollout in Practice
The pilot wave ran for four weeks before regional rollout opened. The pilot dealer cohort was selected for diversity (one each of tier silver, gold, platinum; mix of contract complexity; geographic spread covering all three shipping origins) rather than for being easy. The intent was to surface integration edge cases under real ordering behavior with dealers who had been briefed on the pilot status and who had a direct line to the manufacturer’s dealer ops team.
Five issues surfaced in pilot, all minor: a tax rule misconfiguration in one Texas county, a contract pricing rule that needed a second tier-break threshold, a UI defect on quote PDF generation, a quirk in NetSuite’s handling of partial-ship orders, and a CDN cache rule that was holding stale ATP for two minutes longer than intended. All were resolved before regional rollout opened.
Regional rollout opened to 90 dealers at week 29. One additional issue surfaced (a dealer with five ship-to addresses across three tax jurisdictions had been mishandled by the address selector logic), resolved in three days. Full launch followed at week 33. No critical incidents in the first 30 days post-launch.
Post-Launch Hypercare
The hypercare phase ran 12 weeks, with the same engineering team that built the platform staying engaged at reduced capacity. Tier 1 issues had a four-hour response SLA, Tier 2 issues had a same-day SLA, and the team ran a weekly issue review with the manufacturer’s dealer operations and IT teams. Forty-three issues were logged across the 12 weeks, all resolved within SLA, with a steady decline in volume from the second week onward.
The manufacturer’s portal-driven revenue grew from zero (no portal previously) to approximately 38 percent of total dealer revenue by month 6, which is in line with Forrester benchmarks for mid-market manufacturer B2B portal adoption. Dealer self-service order rate measured 71 percent at month 6, climbing toward 80 percent by month 12.
What Made the Schedule Hold
Three practices, more than any single technical decision, are what kept the program inside its window. First, the integration architecture was finished before the build started, so the data model was stable. Second, the test dataset was built early and was non-negotiable, so demos and automated tests caught regressions immediately. Third, the rollout was staged across three waves with explicit gates, so issues were absorbed by 15 dealers rather than 220.
ERP-integrated manufacturer portals are not unforgiving because Magento is hard or because NetSuite is hard. They are unforgiving because the failure modes compound when the integration topology, the pricing logic, and the test data discipline are figured out during the build instead of before it. A reliable delivery is the result of having those three things settled before the first storefront sprint opens.
