The conversation about integrating Adobe Commerce with ERP and CRM systems usually goes well in the first meeting. Everyone agrees integration is necessary. Everyone agrees the manufacturer is losing time and revenue to manual workflows. Then the second meeting happens, the implementation team brings a proposal, and the objections start. These objections aren’t unreasonable, and they aren’t the same objections retail-focused commerce teams raise. Manufacturers operate with constraints that don’t appear in product catalog implementations.
This is the honest version of how those objections play out in B2B manufacturer engagements, and how the better implementations address them substantively rather than dismissing them.
“Our ERP Was Customized Over Two Decades, Standard Integrations Won’t Work”
This objection comes up in essentially every manufacturer engagement because it’s essentially always true. The ERP system, whether it’s SAP, NetSuite, Microsoft Dynamics, Oracle, Infor, or one of the dozens of industry-specific ERPs, has been customized over years or decades to fit how the manufacturer actually operates. The customizations aren’t incidental. They encode the way the business reconciles inventory, calculates pricing, processes returns, handles credit, and manages compliance. The standard integration patterns shipped with Adobe Commerce assume a standard ERP, which doesn’t exist.
The unproductive response is to argue that the manufacturer should standardize their ERP processes to fit the integration. That argument doesn’t go anywhere because the ERP customizations exist for documented business reasons and changing them would cost more than the integration project itself.
The productive response acknowledges that the integration architecture has to wrap the customized ERP rather than ignore it. Modern integration approaches use middleware (MuleSoft, Boomi, Workato, or custom node services) to translate between Adobe Commerce’s standard data model and the manufacturer’s specific ERP customizations. The middleware layer documents the translation rules, isolates the changes from both sides, and makes the integration maintainable as either system evolves.
The implementation partner needs the experience to read the ERP customizations, understand what they’re doing, and design the middleware to preserve that logic. This is where many integration projects fail, the partner has commerce experience but limited ERP depth, so the middleware ends up implementing only the standard path and breaking on the manufacturer’s specific scenarios.
“Real-Time Sync Will Overload Our ERP”
This objection is technically correct in many manufacturer environments. The legacy ERP can’t handle the request volume that a real-time commerce sync would generate, especially during peak periods. Forcing real-time sync over a constrained ERP creates outages that affect the entire business, not just the commerce channel.
The productive response is to design the sync architecture around the actual ERP capacity rather than assuming real-time is the right pattern. Most manufacturer commerce data doesn’t need to be real-time. Pricing changes can sync on a defined schedule. Inventory updates can be event-driven from ERP outbound rather than queried from commerce inbound. Order data can flow asynchronously through queues rather than synchronously through API calls.
The architecture that works in constrained-ERP environments uses queue-based asynchronous sync (RabbitMQ, AWS SQS, Azure Service Bus) for most data flows, with strict real-time reserved for the small set of data that actually requires it. Customers shopping the catalog see prices and inventory updated within minutes, which is fast enough for the buying patterns. The ERP doesn’t get hammered with synchronous requests during business hours.
“Our CRM Has Different Customer Records Than Our ERP, Which One Is the Source of Truth?”
This is the question that surfaces master data management as an unavoidable concern. Manufacturers often have customer records in the ERP (for billing and order history) and in the CRM (for sales activity and pipeline) that don’t match. The same company might be “ACME Industries Inc.” in the ERP and “ACME Industrial” in the CRM. Integrating with Adobe Commerce surfaces these mismatches because the commerce platform needs a single customer identity.
The productive response is to define a master data strategy as part of the integration project rather than discovering the mismatch after launch. The strategy needs to designate a system of record for customer data, define how that system reconciles with the others, and implement the reconciliation in the integration layer.
Common patterns: the ERP is the source of truth for billing-relevant customer data (legal name, tax ID, payment terms, credit limits), the CRM is the source of truth for sales-relevant data (decision makers, opportunities, account notes), and the commerce platform draws from both via the middleware layer.
Bemeir’s B2B eCommerce practice handles the master data conversation explicitly in the discovery phase, because pretending it’ll sort itself out during implementation is the most common cause of integration project delays.
“Our Pricing Logic Is Too Complex to Sync”
Manufacturer pricing is genuinely complex. Customer-specific pricing, volume tier pricing, contract pricing, promotional pricing, channel-specific pricing, currency conversion, tax handling, and freight calculations interact in ways that the ERP has spent years getting right. The objection that commerce can’t replicate this logic is often correct.
The productive response is that commerce doesn’t need to replicate the pricing logic. The integration can call back to the ERP (or a pricing service that wraps ERP logic) for the authoritative price at the moment of quote or cart. The commerce frontend handles display and UX while the ERP handles the calculation.
This pattern requires careful design around caching, performance, and offline handling. A real-time pricing call on every cart interaction is too slow. A nightly pricing snapshot in the commerce platform is too stale. The architecture that works typically caches pricing at the customer-and-product level with short TTLs (5–15 minutes), refreshes asynchronously when underlying data changes, and falls back to last-known-good pricing when the ERP is unavailable.
The implementation team needs to understand the manufacturer’s pricing logic well enough to design the caching strategy correctly. Cached pricing that doesn’t account for active contracts produces incorrect quotes that the sales team has to clean up manually.
| Manufacturer Integration Objection | Productive Response |
|---|---|
| Custom ERP defeats standard integration | Middleware translates between commerce and customized ERP; partner needs ERP depth |
| Real-time sync overloads the ERP | Queue-based async architecture for most flows; real-time reserved for what truly needs it |
| Mismatched ERP and CRM customer records | Master data strategy defined in discovery, not discovered at launch |
| Pricing logic too complex to sync | Commerce calls back to ERP-backed pricing service rather than replicating logic |
| Inventory accuracy concerns | Event-driven inventory sync from ERP, with reserved stock for commerce channel |
| Security review will take six months | Engage InfoSec early, provide architecture documentation in their format |
“Inventory Accuracy Will Be a Disaster”
Manufacturers know what happens when the commerce site shows products as available that the warehouse can’t fulfill. The objection that integration will produce inventory mismatches comes from real experience with bad implementations.
The productive response is to architect inventory sync around how inventory actually moves in the warehouse. Inventory changes are events (receipt, allocation, pick, ship, return), and event-driven sync is dramatically more reliable than periodic polling. When the ERP records an inventory event, it publishes to a queue, the middleware processes the event, and the commerce platform updates its view.
Reserved stock for the commerce channel is often the difference between an integration that works and one that produces oversells. Allocating a defined inventory pool to the commerce channel rather than letting commerce share the same pool as field sales, distributor allocations, and other channels reduces the surface area where allocation conflicts can occur.
The implementation team needs warehouse operations experience to design this correctly. The pattern that works depends on the manufacturer’s specific warehouse management approach, lot tracking requirements, and channel allocation policies.
“Our InfoSec Review Will Take Six Months”
Enterprise InfoSec teams are conservative about new integrations because they have responsibility for what happens when an integration creates exposure. The objection that the InfoSec review will delay the project is often correct.
The productive response is to engage InfoSec from the discovery phase with documentation in the format they expect. Architecture diagrams, data flow diagrams, authentication and authorization design, audit logging approach, and incident response plan are all artifacts the InfoSec team will want. Providing them up front rather than in response to requests dramatically shortens the review timeline.
Bemeir’s enterprise engagements include a security documentation package built from prior implementations across regulated industries. The package isn’t generic, it’s tailored to the specific integration architecture, but the structure and depth of documentation reflects experience with the InfoSec review process at enterprise manufacturers.
“We Don’t Want to Be Locked Into a Specific Integration Vendor”
This objection reflects legitimate concern about vendor lock-in across integration platforms (MuleSoft, Boomi, Workato, etc.). Manufacturers have seen what happens when an integration platform becomes essential infrastructure that’s painful to replace.
The productive response is to architect the integration in a way that minimizes platform-specific dependencies. The business logic of the integration (the translation rules, the orchestration patterns, the data mapping) should be expressed in a way that’s portable across platforms. The platform-specific code should be a thin layer that calls into the portable business logic.
This discipline costs a bit more during implementation but pays substantial dividends if the integration platform needs to change. It also makes the integration easier to test, easier to maintain, and easier to extend.
Working With a Partner Who Has Been Here Before
The pattern that produces successful manufacturer integrations is partnering with a team that has handled these objections substantively across multiple engagements. The objections themselves aren’t surprising. The right responses aren’t either. What separates successful integrations from troubled ones is whether the implementation team has the depth to address each objection with a real architectural answer rather than a hand-wave.
Bemeir’s Adobe Commerce team operates in this space, building integrations between Adobe Commerce and complex ERP/CRM environments for manufacturers with the kinds of constraints described above. The team has built integrations against SAP, NetSuite, Microsoft Dynamics, Oracle, and several industry-specific ERPs, which means the objections raised in discovery aren’t novel, they’re expected, and the responses are practiced.
Manufacturers evaluating integration projects should ask candidate partners to walk through specifically how they’ve handled each objection above in prior engagements. The answers reveal whether the partner has the operational depth to deliver or whether they’ll discover the constraints during implementation. The standard references for Adobe Commerce’s integration capabilities are the Adobe Commerce developer documentation and the Adobe Commerce GraphQL reference, and any partner candidate should be conversant in both.
