This case study composites the patterns from manufacturer-focused integration engagements where Adobe Commerce was integrated with both an ERP (SAP, NetSuite, Microsoft Dynamics, Oracle, or Infor depending on the specific client) and a CRM (Salesforce, Microsoft Dynamics 365, HubSpot, or industry-specific tools). The specific details have been adjusted to maintain confidentiality, but the architectural choices and operational outcomes reflect actual engagements where the integration produced sustained value.
The case matters because manufacturer Adobe Commerce integrations are categorically different from retail integrations. The complexity comes from the manufacturer’s existing ERP customization, the B2B workflows that need to span systems, the customer data reconciliation between ERP and CRM, and the operational maturity that manufacturers expect from their integrated systems. Patterns that work for retail integrations often don’t work for manufacturer integrations, and patterns that work for manufacturer integrations bring different considerations.
The Starting State
The manufacturer was a $180M industrial products company selling primarily through distributors and direct B2B channels. The product catalog had 12,000 SKUs across complex configurations. The ERP was a heavily customized SAP environment that had been operating for over a decade. The CRM was Salesforce with substantial customization to support the sales team’s workflow. The eCommerce capability was limited — a static catalog site that took orders by form submission and required substantial back-office work to convert orders into ERP transactions.
The strategic objective was upgrading from form-based ordering to full eCommerce capability, with proper integration to both ERP and CRM so that the customer experience felt unified and the operational handling was automated. The implementation question was how to do this without disrupting the existing operations that the existing systems supported.
The Integration Architecture
The architecture that resulted from discovery had several specific characteristics matched to manufacturer constraints.
The middleware layer was MuleSoft Anypoint Platform, selected because the company already used it for other integration work. The architecture didn’t require introducing new integration infrastructure, which reduced vendor risk and operational overhead.
The data flow architecture used event-driven patterns for most flows. SAP published events when relevant data changed (inventory updates, customer record changes, order status updates, pricing updates), and MuleSoft consumed the events and propagated them to Adobe Commerce or Salesforce as appropriate. The pattern decoupled SAP from the consuming systems, which protected SAP from request volume that might have affected other operations.
For pricing, the architecture used real-time callback rather than synchronization. The company’s pricing logic was complex — customer-specific contract pricing, volume tier pricing, promotional pricing, and configurable product pricing — and replicating that logic in Adobe Commerce would have introduced unacceptable risk of pricing errors. The integration called back to a pricing service that wrapped SAP’s pricing logic, with appropriate caching to handle the request volume.
For customer data, the architecture established SAP as the source of truth for billing-relevant customer data (legal name, tax ID, payment terms, credit limits) and Salesforce as the source of truth for sales-relevant data (decision makers, opportunity context, account notes). Adobe Commerce drew from both systems via the middleware to present a unified customer view to the customer.
For inventory, the architecture used event-driven updates from SAP’s inventory module to Adobe Commerce. The events captured inventory changes at the warehouse level, and the middleware translated them to the SKU-level availability that Adobe Commerce needed. The system supported reserved channel allocation so that the commerce channel had defined inventory access rather than competing with other channels.
For orders, the architecture flowed commerce-originated orders through Salesforce (creating opportunity and account activity records) and then to SAP (creating sales order records for fulfillment). The flow handled the multi-system coordination through MuleSoft orchestration rather than direct integration between systems.
Bemeir’s manufacturer Adobe Commerce practice led the implementation, working closely with the company’s SAP team, Salesforce administrators, and MuleSoft architects to coordinate across the multiple systems and teams involved.
The Discovery Findings That Shaped Implementation
The discovery phase surfaced several findings that shaped the implementation approach.
The SAP customizations were more extensive than initially documented. Discovery revealed customizations to pricing logic, customer hierarchy management, product structure (including configurable products with complex BOMs), inventory allocation rules, and order processing workflows. The middleware design had to accommodate these customizations rather than assuming standard SAP behavior.
The Salesforce data had significant inconsistencies with SAP. Customer records that should have matched between systems didn’t always match. Some Salesforce accounts didn’t have corresponding SAP customers (because they were prospects rather than customers). Some SAP customers didn’t have Salesforce records (because they were billing-only relationships that the sales team didn’t manage actively). The master data reconciliation became a substantial workstream.
The configurable products required substantial design work. The company’s products included configurable items where customers chose options that affected product specifications, pricing, and lead times. Adobe Commerce’s standard configurable product handling didn’t cover the complexity; the implementation needed custom configurator capability with integration to SAP’s configuration logic.
The B2B workflow requirements were extensive. Account hierarchies (parent companies with multiple subsidiaries that needed unified or separate views), approval workflows (purchases above thresholds needed designated approvers), customer-specific catalogs (different products visible to different customer types), and procurement system integration (punchout for larger customers) all needed implementation alongside the basic eCommerce capability.
The performance requirements were stricter than initially anticipated. The B2B customer base included high-volume buyers who would generate substantial request volume during peak ordering periods. The architecture had to support 10x the steady-state request volume during quarterly ordering surges without degradation.
The Implementation Phases
The implementation ran across 14 months in distinct phases, each producing operational capability before the next phase started.
The first phase (4 months) established the foundational integration. Adobe Commerce was deployed in a base configuration. The MuleSoft middleware was implemented for catalog sync (SAP to Adobe Commerce), customer sync (SAP and Salesforce to Adobe Commerce), and inventory sync (SAP to Adobe Commerce). A basic checkout flow created orders in Adobe Commerce that flowed through to SAP via the middleware. The phase produced a working eCommerce capability for a subset of products and a subset of customers, validating the foundational architecture.
The second phase (3 months) added the configurable product capability. The custom configurator was built into Adobe Commerce with integration to SAP’s configuration logic. The configurator produced configured product specifications that flowed through the order process to SAP fulfillment. The phase extended the eCommerce capability to include the company’s configurable product lines.
The third phase (3 months) added B2B workflow capability. Account hierarchies, approval workflows, customer-specific catalogs, quote management, and punchout integration were all implemented. The phase made the platform fully capable for the company’s B2B customer base.
The fourth phase (2 months) addressed performance and reliability. Load testing simulated peak conditions, performance tuning addressed the bottlenecks that surfaced, monitoring and alerting were implemented at appropriate detail, and the operational handoff to the company’s internal team was completed.
The fifth phase (2 months) was post-launch stabilization. The platform was live with customer traffic, the team monitored operational health closely, issues that surfaced from real customer usage were addressed, and the operational team developed confidence in routine maintenance.
The Operational Outcomes
The integration produced operational outcomes that justified the substantial investment.
The eCommerce channel grew from essentially zero to $20M in the first year of operation, representing 11% of the company’s total revenue. The growth came from customers who preferred eCommerce convenience over form-based ordering and from new customers who entered the company through the digital channel.
Order processing efficiency improved substantially. The integration eliminated the manual order entry work that had previously been needed for form-submitted orders. The operational team that had handled order entry was reassigned to higher-value work.
Customer service quality improved through unified customer visibility. Customer service representatives could see the customer’s full context (CRM relationship data, ERP transaction history, current commerce activity) without switching between systems. Average handle time decreased, first-contact resolution rate improved, and customer satisfaction metrics rose measurably.
Inventory accuracy reached levels that the previous architecture couldn’t support. The event-driven inventory updates kept commerce visibility aligned with warehouse reality, eliminating the overselling incidents that had occurred under the previous batch-update architecture.
Pricing accuracy was maintained through the real-time callback to SAP. The complex customer-specific pricing flowed correctly to the customer at quote and cart time, with no instances of pricing errors that customer service had to resolve manually.
Operational visibility improved through monitoring and dashboards that the integration produced. The operations team could see integration health, order flow status, inventory accuracy, and other operational metrics in real time rather than discovering issues through customer complaints.
| Phase | Duration | Outcome |
|---|---|---|
| Foundation | 4 months | Working eCommerce for subset of products and customers |
| Configurable products | 3 months | Full product catalog including configurables on platform |
| B2B workflows | 3 months | Account hierarchy, approval, quote, punchout capabilities |
| Performance and reliability | 2 months | Peak-tested platform with monitoring and ops handoff |
| Post-launch stabilization | 2 months | Operational team self-sufficient, real customer traffic |
What Made This Implementation Work
Several patterns made this implementation work where similar implementations have struggled.
The discovery phase did the work. The 8-week discovery surfaced the SAP customizations, master data inconsistencies, configurable product complexity, B2B workflow requirements, and performance constraints before implementation started. The discovery findings shaped the implementation architecture rather than being discovered during implementation as expensive surprises.
The middleware platform was familiar. The company’s MuleSoft expertise meant the architecture could be implemented and operated by the company’s existing team rather than requiring new integration platform learning. The vendor risk assessment was already complete.
The implementation partner had manufacturer Adobe Commerce experience. The configurable products, B2B workflows, and ERP integration patterns were familiar from prior engagements. The implementation team wasn’t learning these on this engagement; they were applying patterns refined over many comparable engagements.
The phased approach produced incremental value. Each phase delivered operational capability before the next phase started. The phased structure protected against the risk of late delivery — even if later phases ran into issues, the earlier phases would still have produced value.
The operational handoff was thorough. The company’s team received the documentation, monitoring, runbooks, and operational knowledge to maintain the integration after the implementation team’s involvement ended. The handoff included shadowing periods where the operational team handled real issues with the implementation team available for support.
Bemeir’s manufacturer practice operates with this kind of structured discipline as standard practice. The team’s pattern is matched to the operational maturity that manufacturers expect from their integrated systems, which differs substantially from the patterns that work for consumer retail engagements.
Implications for Other Manufacturers
The patterns from this engagement apply broadly to manufacturers facing Adobe Commerce integration projects. The implications worth noting:
Discovery work pays back substantially. Manufacturers who skimp on discovery typically discover the surprises during implementation, which is dramatically more expensive than discovering them during discovery. The investment in thorough discovery produces predictable implementation; the alternative produces implementation that ends up over budget and behind schedule.
Middleware platform familiarity matters. Selecting an integration platform the team already knows and has assessed produces faster implementation and lower operational risk than introducing a new platform. Vendor selection should account for organizational fit, not just technical capability.
The implementation partner’s manufacturer experience determines outcomes substantially. Adobe Commerce integration with manufacturer ERPs and CRMs has specific patterns that don’t transfer from retail engagements. Partners without manufacturer experience often discover this during the engagement, which is exactly when discovery is most expensive.
Phased implementation produces better outcomes than monolithic implementation. The manufacturer’s operational risk appetite for major changes is typically limited. Phasing the implementation into discrete capabilities each producing operational value lets the manufacturer adopt the new capability incrementally with appropriate validation at each phase.
Operational handoff is part of the implementation, not an afterthought. The manufacturer’s team will be running the integration for years after the implementation; the handoff determines whether they can do that confidently or with ongoing dependence on the implementation partner. The handoff should be planned and executed deliberately.
The manufacturers who develop the operational pattern around Adobe Commerce integration build capabilities that compound over time. The eCommerce channel grows, the operational efficiency improves, the customer experience deepens, and the data foundation supports broader business intelligence work. The manufacturers who struggle with integration tend to limit their channel growth to what the friction allows, which constrains strategic capability. The integration investment, done well, produces durable competitive advantage. For broader context on manufacturer eCommerce practice, the Adobe Commerce documentation, the B2B Online research, and the Digital Commerce 360 B2B coverage are starting points worth bookmarking.
