Why open source B2B ecommerce for manufacturing needs its own plan
A self-hosted open-source B2B store can work for a manufacturer, but only when the ERP, PIM and pricing rules are designed in from the start rather than bolted on after launch. Consider a manufacturer whose dealers still place orders by phone, by spreadsheet and from PDF price lists that sales staff update by hand. The first architectural decision is between a monolith such as Magento Open Source, which keeps catalog, accounts, quotes and checkout in one application, and a headless API platform such as Saleor or Medusa, which separates commerce logic from the storefront. That choice depends on catalog size, how many account hierarchies and price lists dealers need, and whether your in-house team can run a separate front end.
Manufacturing also adds obligations that a storefront project does not usually carry. If the company builds connected machinery or equipment, product security is governed by standards such as the ISA/IEC 62443 series, which address industrial automation and control systems, and by the EU Cyber Resilience Act, whose Article 14 reporting duties for manufacturers have applied since 11 September 2026. NIS2 lists manufacturing as a critical sector, and the Machinery Regulation requires from 14 January 2027 that connecting another device or remote device does not lead to a hazardous situation. The B2B storefront is usually the lower-risk part of this program, because it does not normally sit on the control network. The plan should keep it separate from OT systems and assign each obligation to the team that owns the product.
In short, Magento Open Source fits large catalogs with complex B2B account structures and a team that can operate its PHP stack. Adobe lists 2.4.9 with regular support until May 31, 2029, and Adobe documents Varnish as the full-page cache for self-managed installations. Saleor and Medusa fit teams that want an API-first back end and will build a custom storefront, and Medusa is MIT licensed except materials under its Enterprise Edition license, so confirm that the features you need are covered. Sylius, also MIT licensed, suits teams with strong PHP and Symfony skills who need custom order and pricing logic. WooCommerce can serve smaller dealer networks with simpler pricing, and its multi-tier B2B capability should be checked against the extensions you plan to use.
Which requirements shape a manufacturer's B2B store
This table maps each requirement that touches a manufacturer's B2B store to its source and to what it means for the build. Some rows apply to every manufacturer selling to dealers, while regulatory rows apply only when the company's products, sector, plant connections or customers fall within scope. Confirm the applicability of each regulatory row with counsel and your compliance lead before it shapes scope.
| Requirement | Source | What it means for the build |
|---|---|---|
| Customer-specific catalogs and price lists per dealer account | Commercial requirement for distributor and dealer selling | Account-level price lists, visible assortments and tax rules must be modeled in the platform and checked against the ERP price master from day one. |
| Quotes and reorders | Commercial requirement for B2B buying | Quote approval, saved carts and reorder from past orders need workflow and permission design, and they usually require extension or custom work on the chosen platform. |
| ERP stock and order status sync | Commercial requirement tied to the ERP of record | Stock levels and order status must come from one system of record, with a defined sync frequency, error handling and reconciliation for every dealer-facing view. |
| PIM as the product data source | Commercial requirement for catalog accuracy | Product attributes, images and dealer-specific descriptions should be pulled from the PIM rather than edited in the store, so that the store is a consumer of product data. |
| NIS2 Annex II coverage of manufacturing (NACE divisions 26 to 30) | NIS2, Directive (EU) 2022/2555, Annex II and Article 23(4) | Manufacturers in these NACE divisions may be in scope as entities in a critical sector. Significant incidents then need an early warning within 24 hours, a notification within 72 hours and a final report within one month, so the store's logs and incident contacts must support that timeline. |
| CRA Article 14 reporting from 11 September 2026 and product application from 11 December 2027 | Cyber Resilience Act, Regulation (EU) 2024/2847, Article 71(2) | Applies where the company sells products with digital elements, such as connected machines or devices. Reporting of actively exploited vulnerabilities and severe incidents applies now, so the store should not become an unmanaged channel for those products' software or firmware. |
| Machinery Regulation 1.1.9 from 14 January 2027 | Regulation (EU) 2023/1230, Annex III, 1.1.9 | Applies only where the store links to machine data, such as remote ordering of parts or telemetry from installed equipment. Connections into machinery must be designed so that a connected device cannot create a hazardous situation. |
| ISA/IEC 62443 for plant and IACS separation | ISA/IEC 62443 series, including ANSI/ISA-62443-3-2-2020 and ISA-62443-3-3-2013 | Applies to manufacturers with operational technology. The commerce network, its integrations and its hosting zone should be separated from plant control networks, with only defined, monitored data paths between them. |
| 21 CFR Part 11 only where regulated records are involved | 21 CFR Part 11, electronic records and electronic signatures | Applies only where the store or its order workflow creates regulated records, for example in certain life sciences or medical device supply. Most industrial B2B stores do not fall under it, so confirm this before adding e-signature controls. |
| CMMC Level 2 only for defense supply chain | 32 CFR Part 170, Level 2 aligned to NIST SP 800-171 Rev. 2 | Applies only to defense contractors and subcontractors handling controlled unclassified information. The Department of War reported on 13 July 2026 that CMMC Phase II requirements were suspended, so confirm the current contract requirements with the prime contractor. |
Which open-source platform fits which B2B situation
Magento Open Source suits manufacturers with large catalogs, many customer-specific price lists and account structures, and quoting or reorder flows that need depth. It is licensed under OSL-3.0, and the 2.4.9 release is the latest stable tag in the magento2 repository. Adobe gives each 2.4.x release three years of standard support, so 2.4.9 has regular support until May 31, 2029. Adobe's system requirements for 2.4.9 list PHP 8.5, MySQL 8.4 or MariaDB 12.3 or 11.8, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3 and nginx 1.30 on Linux x86-64, and only those combinations are supported.
- Catalog and pricing depth: Account-level catalogs and price rules are built in, but the design must be tested against your real dealer structure.
- Support window: Confirm which 2.4.x line your upgrade plan targets and when its support ends.
- Runtime stack: Budget for PHP, search, cache and message queue services that must match Adobe's listed versions.
- Team model: Plan for an in-house or partner team that can own extensions, upgrades and security patches.
- Cache layer: Adobe documents Varnish for self-managed installations, which adds a component to operate.
Check whether your B2B features need Adobe Commerce rather than Open Source, and ask any partner to show which capabilities are core and which come from extensions.
Saleor and Medusa are API-first commerce engines, so a manufacturer that wants a custom dealer portal, its own front-end framework and integrations designed around the API may fit better. Saleor is a headless commerce API under BSD-3-Clause, with 3.23.42 published on October 16, 2026. Medusa is MIT licensed except for materials covered by its Enterprise Edition license, with v2.21.2 published on September 28, 2026. Both reduce the server-side template work but move the dealer experience into code your team or partner must build and maintain.
- Custom dealer portal: Account, quote and reorder screens are built in the front end against the API.
- License boundary: For Medusa, confirm which modules you use fall outside the Enterprise Edition license.
- Integration surface: ERP and PIM sync are typically written as services around the API, so define ownership early.
- Build cost: A headless build adds front-end, hosting and testing work that a monolith does not require.
- Content split: Decide whether product content lives in the commerce engine or a separate headless CMS.
Confirm the B2B account, price list and quote model in each candidate's current documentation against your dealer requirements before choosing.
Sylius is a good match when the team has strong PHP and Symfony skills and wants a bespoke B2B flow rather than a platform configured through extensions. Sylius is licensed under MIT, and v2.3.1 was published on October 14, 2026. Because the commerce logic is application code, dealer rules, approval steps and quote workflows can be modeled directly in the domain. The trade-off is that your team owns more of the product, so maintenance and upgrades depend on the skills you keep in-house.
- Domain modeling: Dealer hierarchies, approval chains and negotiated prices can be implemented as first-class domain logic.
- Skills requirement: Confirm your PHP and Symfony capacity covers both build and long-term upgrades.
- Upgrade path: Plan how custom code will follow major Sylius releases.
- Integration ownership: ERP and PIM connectors are code you write and test.
- Community ecosystem: Compare available plugins with what you would otherwise build yourself.
Ask the partner to show a working dealer quote and reorder flow built on your own data before committing to a bespoke path.
WooCommerce fits smaller manufacturers with a modest catalog, simple dealer pricing and an existing WordPress estate. WooCommerce is licensed under GPL version 2 or later, and version 11.2.1 was published on October 9, 2026. Its strength is that the site, content and shop share one administration model, which lowers the skills needed for routine changes. Complex contract pricing, multi-level account hierarchies and ERP-driven stock logic usually need additional plugins or custom code, so the case for WooCommerce weakens as those requirements grow.
- Simple dealer pricing: Group or role-based pricing can cover a limited set of dealer tiers.
- Shared operations: Content teams already working in WordPress can maintain the storefront.
- Plugin dependency: Each B2B feature adds a plugin you must track for compatibility and security.
- Catalog size: Test performance against your real product count and variant structure.
- ERP stock sync: Confirm the connector handles your stock and order status cadence.
Check which WordPress and WooCommerce versions your plugins support before selecting this option.
PrestaShop is worth evaluating as a lighter monolith for manufacturers whose B2B needs are moderate and whose team prefers a configured storefront. PrestaShop Core is licensed under OSL-3.0 and its modules under AFL-3.0, and PrestaShop 9.2.0 was published on September 30, 2026. It is a reasonable candidate to compare against the other options on your actual dealer, quote and ERP requirements, but it should be tested rather than assumed.
- Module review: Check that the B2B modules you need are maintained and compatible with the core version.
- Scale test: Measure catalog and dealer account performance with representative data.
- ERP connector: Confirm an existing integration exists or budget for building one.
- Support model: Identify who will apply security patches and upgrades.
- Exit path: Document how catalog and customer data would move if you change platform later.
Run a short proof of concept against your top three dealer workflows before adding PrestaShop to the shortlist.
Which platforms fit manufacturers and why
Manufacturers selling to distributors and dealers usually decide between a full-featured monolith and a headless API platform, then pair it with an ERP for stock and order status. The cards below set out when each option fits and what to confirm with the vendor before committing.
Magento Open Source for complex dealer catalogs
Magento Open Source is licensed under OSL-3.0 and 2.4.9 is the latest stable tag, so it is a common fit where dealer-specific price lists, quote handling and complex catalogs must run in one monolith. Self-hosting brings Varnish for full-page caching and OpenSearch for catalog search into your operating scope, and both need patching and capacity planning. Confirm the exact support window for your chosen 2.4.x line and which B2B extensions are maintained for that release before you commit.
Saleor for API-first B2B storefronts
Saleor is a headless commerce API licensed under BSD-3-Clause, which suits manufacturers that want a custom dealer portal and separate storefronts fed by one GraphQL commerce layer. The fit condition is a team able to build and run the front end, plus integration work for ERP stock and order status. Confirm how customer-specific price lists and company accounts are modeled in the release you plan to use, since B2B features may require custom development.
Medusa for modular headless commerce
Medusa is MIT licensed, except materials covered by its Enterprise Edition license, so the boundary between community and paid code must be checked against your feature list. It fits manufacturers that want a Node.js commerce backend with custom modules for quotes, reorders and dealer pricing. Confirm which B2B capabilities sit in the Enterprise materials and whether your planned features depend on them, since that changes both licensing and the build estimate.
Sylius for custom B2B logic
Sylius is licensed under MIT and v2.3.1 is its latest release in the supplied facts, so it suits manufacturers whose dealer rules are complex enough that custom domain code is the cleaner option. Your engineering team owns more of the business logic, including quote workflows and approval rules, and that code must be maintained through every upgrade. Confirm the Symfony and PHP versions it requires, and the release cadence your partner will support.
WooCommerce for smaller dealer networks
WooCommerce is licensed under GPL version 2 or later and runs on WordPress, which suits manufacturers with a modest catalog, a small number of dealers and an existing WordPress estate. Its limits appear as order volume, catalog size and B2B rules grow, and each plugin adds maintenance. Confirm which B2B plugins you need, their license terms and their support for the WooCommerce release you adopt, since plugin compatibility is the main upgrade risk.
ERPNext for stock and order status
ERPNext is licensed under GPL-3.0 and covers order, inventory and manufacturing management on the Frappe Framework, so it is often the system of record that the commerce platform reads from. Supported major versions are 16 and 15, and version 14 has reached end of life, so the version you deploy determines the support path. Confirm how the commerce platform will receive stock and order status, whether through API or middleware, and who handles version upgrades on both sides.
How a manufacturer's B2B rollout runs in phases
The sequence moves from agreeing who owns account, price and product data to a pilot with a small dealer group, then a segment-by-segment cutover and a support plan that covers upgrades. Each phase closes with a named document or working system that the next phase depends on.
Agree account types, price lists and data ownership
Workshops with sales operations, the ERP owner, the PIM owner and the dealer management team map each account type (distributor, dealer, direct key account), the price lists and discounts that apply to each, and which system is the source of truth for customers, prices, stock and product attributes. DeployOpen documents the result as a data ownership register and a signed scope. The step is done when every field used in pricing and ordering has one named owner and one named system of record.
Model catalog data and map PIM attributes
The team defines the product data model for the storefront: SKUs, variants, units of measure, pack sizes, technical attributes, documents and assets, and maps each attribute to its PIM or ERP source field. Customer-specific catalogs and restricted product visibility are modeled at this stage so that they are not retrofitted later. The output is a field mapping specification and a sample data set exported from the PIM, which the team uses to test imports before any live integration is built.
Decide platform and target architecture
The team compares a monolithic open-source commerce platform with a headless API platform against the requirements from the previous phases, including account-specific catalogs, quote and reorder flows, ERP connectivity and the internal skills available to run the stack. The decision is recorded in an architecture decision record covering hosting location, environments, caching, search, integration layer and backup approach. Ask each candidate partner to confirm the exact versions and support windows of the platform before the record is approved.
Build the stock and order status integration
The integration team builds the flows that move stock levels, customer-specific prices, order submissions and order status updates between the storefront and the ERP, through an integration layer that logs every message and retries failures. Test cases cover partial shipments, backorders, credit holds and price changes mid-cart. The phase closes when an end-to-end test order placed in the staging storefront appears in the ERP with the correct account, price and status feedback, and the error log is reviewed by the ERP owner.
Run a pilot with a small dealer group
A limited set of dealers in one region place real orders, request quotes and reorder through the new storefront while the existing channel remains available. The pilot team tracks order errors, support tickets, pricing disputes and the share of orders that needed manual correction in the ERP. Named business owners approve the exit criteria before the pilot starts. The pilot is complete when the exit criteria are met and the open defect list has an agreed owner and fix date for each item.
Cut over account segments in sequence
Migration moves accounts in groups, starting with the segments that the pilot validated and ending with the most complex key accounts, which often carry contract pricing and custom approval rules. Each wave includes a data reconciliation of accounts, price lists, open orders and open quotes against the ERP, plus a documented rollback path. The wave is closed when reconciliation reports show no unexplained differences and the account managers for that segment confirm that their customers can log in and order.
Stabilize in hypercare and set the upgrade plan
After the final wave, a hypercare period covers defect triage, monitoring of integration queues, performance review and user support, with a named escalation path to the platform and ERP teams. The team then writes an upgrade plan that lists the platform and extension versions in use, their support end dates, the test suite used for regression and the patch cadence the owner will follow. The phase closes with a signed handover pack: runbooks, monitoring dashboards, backup and restore records and the upgrade calendar.
How ERP and PIM data flow into dealer accounts
Before any integration is built, the team has to agree which system owns each record. For a manufacturer selling to dealers, the usual split is that the ERP is the source of truth for stock levels, base prices, customer master data and order status, while the PIM owns product descriptions, attributes, images and category structure. The storefront reads from both and stores almost nothing it can not regenerate. Write that split down per field, including who may change a dealer's negotiated price list and in which system. Ambiguity here produces the most expensive defects, such as a dealer seeing a price the ERP never approved.
ERP writes should go through a controlled integration layer, such as an API service with its own service account, validation rules, logging and retry handling, rather than direct inserts into the ERPNext database. Direct database access bypasses the document validation, permission checks and business logic that ERPNext applies on save, and it makes upgrades harder to test. ERPNext's Data Import tool suits batch loads and corrections, but its own documentation advises importing only a few thousand records at a time, so a full catalog or a large price list refresh needs a scheduled, chunked job with reconciliation reports, not a one-off spreadsheet upload. Confirm the batch size and run time with your ERPNext version before you plan the cutover window.
Custom order logic, such as minimum order quantities per dealer, credit holds or split shipments, is often written as Server Scripts. From version 15, Server Scripts are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. If your design depends on Server Scripts, confirm the hosting tier before you commit to Frappe Cloud, or plan to run ERPNext on your own infrastructure with a documented change process. Where the rules are complex, moving them into the integration service keeps them versioned, testable and independent of the hosting plan. Ask your implementation partner to name every custom rule, its owner and where it runs.
What auditors and regulators ask a manufacturer to show
This table maps each piece of evidence a manufacturer should be able to produce to the component that generates it and the requirement it supports. Read it as a checklist for the commerce integration and the plant-adjacent systems it touches, not as a list of certifications. DeployOpen prepares this evidence, but independent auditors and regulators decide whether it is sufficient.
| Evidence | Component that produces it | Requirement it supports |
|---|---|---|
| Asset inventory and network zone diagram for plant-adjacent systems | Configuration management database, network diagrams and the ERP and store integration points | ISA/IEC 62443 series: zoning and asset ownership for industrial automation and control systems |
| Risk assessment for the commerce integration | Documented threat model covering order, pricing and stock data flows between the store and ERP | ANSI/ISA-62443-3-2-2020 security risk assessment, where the integration touches IACS networks |
| Vulnerability and patch records for the store and ERP | Release tracking for Magento Open Source and ERPNext, with dated patch and upgrade tickets | Supported-version evidence for ERPNext and Magento Open Source, and NIS2 risk management expectations |
| Incident reporting timeline | Incident runbook with logged detection, early warning, notification and final report steps | NIS2 Article 23(4): early warning within 24 hours, notification within 72 hours, final report within one month |
| CRA vulnerability reporting process | Vulnerability intake, triage and disclosure records for any product with digital elements the manufacturer supplies | CRA Article 14 reporting of actively exploited vulnerabilities, applicable since 11 September 2026 |
| Access logs and change records for pricing and account changes | Admin audit logs, ERP change history and approval tickets for price lists and dealer account edits | Access control and change traceability expected by ISA/IEC 62443 and internal segregation of duties |
What manufacturers ask before hiring a B2B commerce partner
What drives the cost of a B2B commerce build for a manufacturer?
The biggest cost drivers are catalog size, the number of customer account types and price list rules, how complex the ERP integration is, the number of other integrations, how much payment and checkout work falls into PCI DSS scope, and how often the platform will be upgraded. Costs fall into two groups. One-time costs cover discovery, configuration, custom development, integration build, data migration and testing. Recurring costs cover hosting, third-party extensions and licenses, security patching, upgrades and support. Ask every partner for a fixed-scope quote that lists each integration, each account type and each price list rule as a separate line, and that states which costs recur and who pays for them.
How long does a B2B ecommerce rollout take?
The timeline depends on the scope you agree in writing, which is usually set by the ERP integration depth, the number of customer-specific price lists, the PIM data quality and the number of sales channels or regions. Plan for separate phases: discovery and requirements, integration and build, data migration, testing with real dealer accounts, and a controlled cutover. Ask the partner for a phase plan with dependencies on your ERP and PIM teams, and for the assumptions behind each duration. Ask what happens to the schedule if product data or price rules arrive late, because that is the most common source of delay.
What must our internal team provide before the project starts?
Three roles must be named before work begins. An ERP owner must confirm how stock, customer master data, order statuses and invoices are maintained and which system is the source of truth for each. A pricing owner must document the price lists, discount rules, minimum order values and contract prices for each dealer group. A product data owner must supply clean PIM data, including attributes, units of measure, images, documents and variant structures. Ask the partner to produce a data readiness checklist and to name which of these items it expects you to deliver, and by when, in the quote.
Can our team build a B2B store without an implementation partner?
A capable internal team can build a basic B2B storefront on an open-source platform, especially if it already runs the platform and has developers who know its framework. It gets hard in three places: securing and maintaining the payment and checkout pages, keeping customer-specific pricing and ERP synchronization correct under load, and running upgrades and security patches on a fixed schedule. Errors in price lists or stock sync show up as wrong quotes and disputed orders, which affects revenue directly. Assess your team against these three areas, and ask any partner to explain how it would hand over documentation and runbooks so that your team can operate the result.
How does choosing a monolith or a headless platform change run cost?
A monolith such as Magento Open Source keeps the storefront, catalog, cart and checkout in one application, which usually means fewer separately deployed services to host and patch, but a larger upgrade surface. A headless platform such as Saleor or Medusa exposes commerce through an API, so you add a separate storefront application, its hosting and its release pipeline, and you own more of the integration layer. The extra run cost comes from more components to monitor, more deployments and more front-end work to keep in step with commerce upgrades. Ask partners to price both options for the same scope, including hosting, upgrade effort and the people needed to run each component.
Do we have to replace our ERP or PIM to sell B2B online?
No. In most manufacturing cases the ERP stays the system of record for stock, pricing masters, customer accounts and invoices, and the commerce platform connects to it through an integration layer. The PIM usually stays the source of product content, and the store imports or syncs from it. Replacement becomes a question only when the existing systems cannot expose the data or events the store needs, or when they are already past their support window. Ask the partner to map each data object (products, prices, stock, customers, orders, quotes, invoices) to its source system and to state which integration pattern it proposes for each.
What does support look like after go-live?
After launch, you need an owner for platform patches, extension updates, integration monitoring, incident response and periodic upgrades. Open-source platforms publish releases on their own schedules, so the work of tracking supported versions and applying security fixes does not stop at launch. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask any partner what its response process covers, who is on call for ERP sync failures, how it handles platform version support windows and what is included in a retainer versus a separate project.
What to ask an implementation partner before signing
Ask first how the partner separates the commerce network from plant and OT networks. The relevant reference is the ISA/IEC 62443 series, which organizes requirements into general, policies and procedures, system and component groups, and ANSI/ISA-62443-3-2-2020 covers security risk assessment for system design. Ask for the zone and conduit diagram, the rule set on the firewall between the storefront, the ERP integration host and any plant-facing system, and who signs off on a change to it. A partner who answers only in terms of the web application has not scoped the risk that matters to a manufacturer. Ask also how the sync from ERP stock and order status is designed and who owns it: the ERP team, the commerce team or the partner. Get a written answer on which system is the master for item availability, price and order state, and what happens when a sync job fails overnight.
Next, ask how dealer-specific prices, quote approvals and reorders are tested. A credible answer names the test data set (customer groups, price lists, contract prices, tiered discounts and currencies), the test cases for each, and who from your side approves the results. Ask how Magento Open Source extensions and custom modules are kept upgradable, including whether the partner keeps a written list of core overrides and how it tests them against each patch. For the upgrade plan, ask which Magento Open Source line the partner proposes and check it against the published end of regular support dates for 2.4.7, 2.4.8 and 2.4.9 in Adobe's lifecycle policy. Ask who runs each upgrade, how long a staging cycle takes, and who pays for it.
Finally, ask what the partner will hand over at the end, and how it supports NIS2 and CRA reporting. NIS2 Annex II includes manufacturing, and in-scope entities must report significant incidents with an early warning within 24 hours. The Cyber Resilience Act's Article 14 reporting for manufacturers has applied since 11 September 2026. The partner does not issue compliance reports, so ask for the inputs instead: an asset inventory, a log of security patches with dates, a software bill of materials for custom components, and a tested runbook that shows who is notified and when. Request a written handover list before the contract starts, so the evidence is defined in scope rather than assembled after go-live.
