Magento Open Source for manufacturers: why the catalog and ERP shape the build
For a manufacturer selling spare parts or finished products direct to customers, the catalog data, stock sources and ERP sync decide the build more than the theme does. The storefront is the visible part, but most of the cost and risk sits in how configurable products, bundles, warehouses, prices and stock are modeled, and how those records move between the store and the ERP. Before any design work begins, ask your team which system is the master for each product attribute, price and stock quantity. That map determines which modules, import paths and API calls you will need to build and maintain.
Configurable products with several options, bundle products for kits, and parts that fit many machine models each need a clear attribute set and a naming rule that the ERP can follow as well. Multi-warehouse stock uses sources and source selection, so the build must settle which warehouse ships an order, whether stock is reserved at checkout, and how a partially fulfilled order is split. Confirm with your fulfillment team which rules already run in the ERP and whether the store should replicate them or call them. Mismatched rules often show up to customers as oversold parts or cancelled orders.
Prices and inventory usually originate in the ERP and change many times a day, so the integration should batch updates through the asynchronous and bulk APIs that Open Source provides. Decide the sync direction for each entity, the update frequency, how failed records are retried, and who receives an alert when a batch is rejected. Catalog imports from a product information system need the same discipline. Agree on the source file format, the attribute mapping and a rollback path before the first full load, and test the import on a copy of production data with the same product volume.
The store is an IT system and should stay outside plant control networks. Industrial automation guidance, including the ISA/IEC 62443 series, separates business systems from industrial control zones, and the ERP connection is the point where the two meet. Place the storefront, its database, search service and cache in the corporate or cloud zone, and expose only the ERP interface the integration needs through a controlled path. Ask your OT security lead to review the zone and conduit definitions before the integration design is final, and keep any service account the sync uses limited to the records it touches.
Magento Open Source source files are licensed under OSL-3.0, and the distribution also includes AFL 3.0, so have your legal team confirm that those terms suit the custom modules and themes you plan to write. The 2.4.9 release line, released in May 2026, is the current line. Build against the platform versions Adobe lists for 2.4.9, and confirm that each dependency in your stack, including PHP, the database, search, cache and message queue, appears in that list. Do not assume that a capability from Adobe Commerce is present; check the Open Source release notes for every feature your catalog and ERP design depends on.
What industrial standards and EU rules mean for a Magento build
This table sets the industrial standards and EU rules that touch manufacturer ordering, pricing and parts data against what each one means for a Magento Open Source store. Read the first two rows to decide whether any store connection reaches an industrial control boundary, then use the remaining rows to check reporting, product and contract obligations. Most stores sit outside that boundary, but each link to ERP and plant systems must be confirmed.
| Requirement | Source | What it means for the store |
|---|---|---|
| ISA/IEC 62443 series | Four groups: general, policies and procedures, system, component. Asset owner program in ANSI/ISA-62443-2-1-2024 | The store is usually not an IACS component. Confirm with plant security which systems fall in scope. |
| Zones and security levels | ISA-62443-3-2-2020 (risk assessment) and ISA-62443-3-3-2013 (system requirements and security levels) | Confirm where the ERP connector, price feed and order export sit, and which zone boundary each crosses. |
| NIST SP 800-82 Rev. 3 | Guide to Operational Technology (OT) Security, September 2023, superseding Rev. 2 | Written for OT networks such as SCADA, DCS and PLCs. Use it as a reference when the plant OT team reviews ERP links. |
| NIS2 Annex II, manufacturing | Directive (EU) 2022/2555, NACE Rev. 2 divisions 26 to 30 and medical devices | If in scope: early warning within 24 hours, notification within 72 hours, final report within one month (Article 23(4)). |
| Cyber Resilience Act | Regulation (EU) 2024/2847, Article 14 from 11 September 2026, general application from 11 December 2027 | Manufacturers report actively exploited vulnerabilities and severe incidents. Confirm with counsel whether the store or any connected product is covered. |
| Machinery Regulation | Regulation (EU) 2023/1230, applies from 14 January 2027, Annex III, 1.1.9 | Connecting another or remote device must not create a hazard. Relevant if the store triggers configurators or commands tied to machines. |
| CMMC levels for defense suppliers | 32 CFR Part 170: Level 1 (15 FAR 52.204-21), Level 2 (110 NIST SP 800-171 Rev. 2), Level 3 (24 NIST SP 800-172 requirements) | Federal contract information or CUI in store or order systems sets the level. Phase II was suspended on 13 July 2026, so confirm current status with the contracting officer. |
Which Magento modules and settings shape a manufacturer's store
A manufacturer's store depends on a small set of Magento modules and settings that decide how products, stock and data move between the catalog and the systems behind it. Each card names one of these components, what it controls and what to confirm for the release you plan to run.
Configurable products for variants
Configurable products group child SKUs under one parent, with variant attributes such as size, voltage or finish. The attribute set design decides how many child SKUs exist, which options shoppers can select and how the ERP's part numbers map to each variant. Before the build starts, confirm that the release you choose supports the attribute types, swatches and child-product rules you need, and test a sample family of variants with your real option combinations. Illustrative example: a motor offered in three voltages and two finishes produces six child SKUs that must each carry their own stock and price.
Bundle products for kits and accessory sets
Bundle products sell a set of components together, such as a starter pack or a machine with its accessory kit. The bundle type, whether price is fixed or built from the selected options, and whether stock is derived from component stock control how the kit behaves at checkout and in inventory. Confirm which bundle options and price rules ship in the open source edition for your release, and agree with the ERP team how kits are represented, because a kit that the ERP treats as one item can behave differently from one it explodes into components.
Multi-source inventory and source selection
Multi-source inventory lets one catalog draw stock from plants, distributors and third-party warehouses. Each source has its own stock quantities, and source selection rules decide which location fulfills an order when several can ship it. Plan the mapping between Magento sources and ERP locations first, including which sources are visible to customers and which are reserved for internal orders. Confirm in the release notes which inventory modules and source selection algorithms ship in Open Source, and test how a split order is handled when one warehouse cannot ship the full line.
Asynchronous and bulk APIs for ERP sync
Price and stock sync between the ERP and the storefront usually runs through the asynchronous and bulk API operations, which queue requests instead of blocking on each update. Message queues carry these requests, so the queue service, its consumers and its failure handling are part of the design. Confirm which REST, SOAP and GraphQL endpoints and which asynchronous or bulk operations ship in Open Source for the release you select, since some operations previously limited to Adobe Commerce have moved into the open source edition. Then load-test the sync volume your ERP will generate.
Catalog imports from PIM and PLM exports
Catalog imports bring product information, attributes, images and specifications from product information management or PLM exports into the store. The import options, file formats, field mapping and image handling decide how much manual cleanup follows each load. Confirm which import types and options the open source edition provides for your release, the file size and row limits you can run safely, and how the import treats existing SKUs. Run a full import of a representative export into a staging copy, and check configurable parents, bundle components and attribute values before any production run.
Custom modules for fitment and compatibility data
Parts stores often need fitment data, such as which machine models a part fits, and that data rarely fits the standard catalog structure. A custom module can hold compatibility tables, expose them in the admin and on product pages, and feed search and filters. Build it as a PSR-4 compliant module that follows Adobe's extension structure, and keep the source of truth in the ERP or product data system. Confirm that the module's indexers, schema changes and dependencies survive each patch and minor upgrade, and that the chosen release still exposes the hooks it relies on.
How ERP price and stock sync should run without reaching into the plant
The first decision is who owns each master record. In most manufacturers the ERP holds the authoritative prices, stock quantities and product records, because it already carries cost, costing rules, production postings and accounting. Magento Open Source should treat those fields as received data and keep only what the storefront needs to sell: catalog content, customer accounts, carts and orders. Write the ownership down field by field before the build starts, including who may change a price in an emergency and which system wins when two sources disagree. Ask the ERP owner to confirm which stock figure is available to sell, since reserved, quarantined and in-production quantities often differ.
Prices and stock should usually flow one way, from the ERP into Magento. Two-way sync for these fields invites conflicts: a web order reduces stock in one system while a warehouse adjustment changes it in the other, and the platform has no business rule to decide which change stands. Order and shipment status typically flow back from Magento to the ERP, but that is a separate, narrowly defined interface with its own field list and owner. Document each direction as its own contract covering fields, frequency and the system that resolves conflicts. Review the contract with the finance and warehouse leads, not only the developers, because most later disputes start with an unclear field definition.
Choose the transport per data type. Full price lists and catalog-wide stock refreshes suit bulk batches that run on a schedule and can be re-run safely. Frequent stock changes for a limited set of SKUs suit asynchronous messages carried through a message queue. Adobe lists RabbitMQ 4.3 and Redis or Valkey 9 in the supported stack for Magento Open Source 2.4.9, so confirm those versions against the release you select. Every message needs a stable identifier from the ERP so a retry after a timeout updates the same record instead of creating a duplicate. Also define what happens to a message that keeps failing: where it is parked, who receives the alert, and when a person resyncs that SKU by hand.
Reconciliation is what proves the sync worked. Schedule a report that compares ERP and storefront values for price and available quantity per SKU and per stock source, and list mismatches by age. Set a threshold that opens an incident, and name the person who reviews the report each working day. Test it on purpose: change a price in a staging ERP, break a message on the queue, and confirm that the report flags the gap and that the retry corrects it. Ask the implementer to show how replays and manual corrections are logged, so a finance lead or auditor can trace a changed price back to its source.
Connect the ERP to Magento through a defined boundary: an integration service or API gateway in the business network, with named endpoints, credentials scoped to these flows and logs kept on both sides. Magento should not reach into PLCs, manufacturing execution systems or machine networks to read production data. Stock figures should come from ERP inventory, which already reflects production postings. Review the boundary against the ISA/IEC 62443 series with your OT security owner, and confirm which network segments may reach the integration host and in which direction traffic may flow.
Compliance obligations manufacturers should map to the store
Manufacturers rarely face one rule. A store that takes payments, links to connected equipment or serves defense buyers can fall under several regimes at once. The cards below list the obligations to map to the store and the products behind it. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors and certification bodies issue audit reports and certifications.
PCI DSS scope on payment pages
Payment pages decide how much of the store falls into PCI DSS scope. Map every script, tag and payment frame that touches checkout, and decide whether card data ever reaches your servers or stays with a hosted payment provider. Magento Open Source supports Content Security Policy headers from 2.3.5, and from 2.4.7 CSP runs in restrict mode by default on storefront and admin payment pages. After restrict mode is on, check that your theme and extensions still load, and document each allowed source.
Patch on every release cycle
Adobe's upgrade guide recommends upgrading every patch cycle to stay secure and PCI compliant. Treat that recommendation as a standing change process with a fixed calendar. Custom modules, third-party extensions and integrations set how long each upgrade takes, so keep an inventory of them and test each release on a staging copy. Track end of regular support dates, including May 31, 2027 for 2.4.7 and May 31, 2028 for 2.4.8, and ask any partner for a written patch calendar tied to them.
NIS2 reporting clocks for in-scope entities
NIS2 Annex II lists manufacturing as a critical sector, covering NACE Rev. 2 divisions 26 to 30, which include electronics, electrical equipment, machinery and motor vehicles. In-scope entities must send an early warning within 24 hours of a significant incident, a notification within 72 hours and a final report within one month. Your logging, alerting and escalation procedures for the store need to produce those facts on time. Confirm with counsel whether your entity is essential or important, because the obligations and fine levels differ.
Cyber Resilience Act product scope
The Cyber Resilience Act applies to products with digital elements from 11 December 2027. Manufacturers' Article 14 duties to report actively exploited vulnerabilities and severe incidents have applied since 11 September 2026. Whether the CRA reaches you depends on the software and connected products you sell, such as firmware or companion apps. The store itself is probably not such a product, but it may host downloads or update channels for one. Confirm that classification with legal counsel and list each product with digital elements.
Machinery Regulation and remote connections
Regulation (EU) 2023/1230 applies from 14 January 2027. Its essential requirement in Annex III, 1.1.9, calls for machinery protected so that connecting another device or a remote device does not lead to a hazardous situation. If the parts store links to machine data, remote diagnostics or equipment-driven ordering, that link belongs in the machine's risk assessment. Map which machine functions the store can reach, who can send commands, and how those paths are authenticated and logged. ISA/IEC 62443 gives a useful structure for that design.
CMMC levels for federal contract information
CMMC under 32 CFR Part 170 sets three levels for defense contractors. Level 1 covers the 15 safeguarding requirements of FAR 52.204-21 for federal contract information, Level 2 covers the 110 requirements of NIST SP 800-171 Rev. 2 for controlled unclassified information, and Level 3 adds 24 selected NIST SP 800-172 requirements. The Department of War suspended CMMC Phase II requirements on 13 July 2026, so confirm the clause in each contract before you scope the store. Ask the contracting officer which level, if any, each contract requires.
Which Magento release line to build on and when it stops getting support
Build a new manufacturer store on Magento Open Source 2.4.9 unless a required extension or integration blocks it. Adobe gives each 2.4.x release three years of standard support from general availability. Regular support for 2.4.9 ends on May 31, 2029, for 2.4.8 on May 31, 2028, and for 2.4.7 on May 31, 2027. The 2.4.6 line reached its end of regular support on August 11, 2026, so it should not be the base for a store that goes live now. Adobe ships a full patch for the LTS line each May and releases security patches at least once a year for every supported line. Before you choose a line, set your go-live date and the period you expect to run the store without a major upgrade, then confirm that the end-of-support date falls after that period.
The 2.4.9 system requirements list PHP 8.5, MySQL 8.4 or MariaDB 12.3 (recommended, with MariaDB 11.8 also listed), OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3, Composer 2.10, and nginx 1.30 on Linux x86-64. Adobe supports only the listed combinations, so a newer database build, a different PHP package from your operating system, or an older search engine falls outside support even if the store starts. Check the matrix against your hosting image, your build pipeline, and every extension that pins a PHP or database version. Ask your hosting or platform team to confirm where each component comes from and who patches it, because the matrix changes with each release line.
Self-managed installations use Varnish as the full-page cache accelerator, and the 2.4.8 patch requirements list Varnish 8. Confirm the Varnish version in the 2.4.9 requirements before you write the cache configuration, since the cache rules for category pages, configurable product views, and parts lookups depend on it. Manufacturers also need to decide how price and stock changes pushed from the ERP reach cached pages. Test a stock change on a configurable product and check that the storefront shows the update within the window your sales team expects. Record the Varnish version alongside the Magento release in your change log so that an upgrade does not silently change cache behavior.
Mage-OS is a community-owned distribution built on Magento Open Source and run by the Mage-OS Association. Its project describes it as upstream compatible with Magento 2 extensions and lists releases that port Adobe security patches. Evaluate it as a real option, not a formality: compare the release it tracks with Adobe's 2.4.x line, check how quickly it ports Adobe security patches, and install your full extension list on it in a test environment. The support route changes with a distribution, so confirm in writing who builds, tests, and ships security patches, and who answers when an extension breaks after a patch.
Turn this section into three decisions before scoping work. First, record the chosen release line, its end-of-support date, and the date of the next planned upgrade window, which should fall in May when Adobe ships its annual LTS patch. Second, run the compatibility check against your extension list, custom modules, and ERP middleware on the target line, using the Upgrade Compatibility Tool that Adobe references in its upgrade guide. Third, ask your implementation partner to estimate upgrade effort in the quote, because customizations, extension count, third-party integrations, and coding practices drive that effort more than the version number does. Keep these three records in the platform runbook so the next upgrade starts from known facts.
How a manufacturer's Magento rollout runs in phases
The sequence moves a manufacturer from scattered product data to a live store that prices, stocks and sells parts from agreed sources, with each phase closing on a signed-off output. This section gives no durations; the written scope sets the timeline for your rollout.
Audit product data, fitment and stock sources
The rollout starts with an inventory of where product information lives: PIM tools or spreadsheets, ERP item masters, fitment tables for parts, and the warehouses or plants that hold stock. DeployOpen's team works with your product data owners to name the system of record for each attribute, price and quantity, and logs gaps such as missing fitment data, duplicate SKUs and conflicting units. The step is complete when your team approves a data source register with a named owner for every field and a list of audit findings with decisions attached. Ask that this register be written into the scope so later phases build on it.
Design architecture and define the plant boundary
The team maps the storefront, Magento application, database, search, cache, message queue, ERP connector and any link to plant or operational technology networks. The plant boundary is drawn explicitly so that no production control network connects directly to the storefront, and each connection that crosses a zone is listed with its purpose, direction and allowed protocols. Security zoning concepts from the ISA/IEC 62443 series inform the design, and the chosen Magento release is checked against Adobe's published system requirements for the operating system, PHP, database and search services. The step closes when architecture diagrams, the zone list and firewall rules are approved by security and operations leads.
Model the catalog and cleanse product data
Product types, attribute sets and categories are designed for the catalog as it will be sold. Configurable products handle variants such as finish or voltage, bundle products handle kits sold as one line, and fitment attributes connect parts to vehicles, machines or models. The team writes import mappings from each source system and runs cleansing rules for units, duplicates, missing images and inconsistent naming. The step closes when the catalog model document is approved and a test import of the cleansed data completes with an error report that your data owners have reviewed and accepted.
Build the ERP and product data integration
The integration carries prices, inventory and product records between the ERP and Magento through asynchronous and bulk APIs. Stock is allocated by source selection across warehouses, and failed messages go to an error queue with retry rules and an owner for each failure type. Reconciliation reports compare Magento stock and prices with ERP totals on a schedule your operations team sets. The step closes when a full sync and an incremental sync both run in the test environment, and the reconciliation report matches the ERP within the tolerances agreed at the start of the build.
Test parts, bundles and payments with security checks
Testing covers the paths buyers and staff use: fitment search and filtering, configurable selection, bundle pricing, stock reservation at checkout, payment authorization and refunds, and order export to the ERP. Security checks run alongside, including review of Content Security Policy settings, admin two-factor authentication, role permissions, and the patch level of every component. Payment flows are tested against your payment provider's sandbox, and the card data scope is confirmed with your acquirer and assessor before go-live. The step closes when test evidence is logged, defects are remediated or formally accepted, and the security findings list is signed off.
Run a pilot with one market or warehouse
The pilot releases the store to one market, store view or warehouse so the team can observe real orders, stock movements and returns without exposing the full catalog. Operations staff watch the sync reports and error queues daily, and customer service records every issue with its root cause. Exit criteria are agreed before the pilot begins, covering order accuracy, stock accuracy and open defects by severity. The step closes when the pilot meets those criteria, every open defect is triaged with a decision, and the steering group records a go decision for full cutover.
Cut over the store to production
Cutover moves the remaining catalog, customers, orders and integrations into production during a freeze window agreed with operations. The team runs a final data load, reconciles counts against the source systems, switches traffic and rehearses the rollback procedure before the window opens. Smoke tests cover search, cart, checkout, payment and ERP order export on the live environment. The step closes when production smoke tests pass, the rollback plan has been rehearsed and documented, and the hypercare period begins with named contacts on both the DeployOpen and client side.
Support the store through the patch cycle
After go-live, the store moves into a routine of applying patch releases, monitoring ERP sync health and reviewing security alerts. Adobe's upgrade guidance recommends upgrading at each patch cycle to stay secure and PCI compliant, and the effort for each cycle grows with custom modules, extensions and third-party integrations, so the team tracks those counts in a maintenance register. The team keeps runbooks current, tests each patch in staging before production, and records each change. The ongoing phase is complete when a patch calendar, a runbook set and a support model covering retainer or internal ownership are accepted in writing.
What manufacturers ask before hiring a Magento partner
What drives the cost of a Magento Open Source build for manufacturers?
The biggest cost drivers are the number of custom modules and themes, the number of extensions you run and how far they change core behavior, the count of ERP and third-party integrations, and the complexity of the catalog. Configurable and bundle products, multi-warehouse stock with source selection, and the volume of product data to import all add design and testing work. Costs usually fall into discovery, catalog design, custom development, integration build, data migration, testing, cutover and hardening. Most of this is one-time project work. Hosting, monitoring, paid extensions and patch work recur after launch. Ask any quote to itemize these components, name who does each piece and state the assumptions behind it.
How long does a Magento manufacturer store build take?
Duration follows the scope agreed in writing, so the main factors are the number of product types, warehouses, ERP fields to sync and sales channels. A store that replaces an existing platform also needs data migration and a cutover plan, which adds time. Dependencies often set the pace more than development does: ERP API access, the readiness of product data, and the number of approval cycles on the business side. The project normally moves through discovery, catalog and integration design, build, data loads, testing and go-live support. No standard duration applies to every manufacturer. Ask the partner to show the phases, the decisions needed from your side and the points where work waits on your team.
What does our team need to provide for a Magento build?
Three groups carry most of the load. Product data owners define attributes, SKU rules, variant and bundle logic, and approve catalog imports from your product data system. ERP staff confirm price and inventory fields, API access, sync frequency and how errors are handled. Network and security owners approve hosting placement, firewall rules, certificates, admin access, and how payment and integration traffic is routed. A single project owner with decision authority should coordinate all three. Before signing, ask the partner to name the people and the time each group must commit, and to list those dependencies in the written scope so delays can be traced to a cause.
Can an internal team build a Magento Open Source store alone?
An internal team can build a store alone if it has experienced Magento and PHP engineers, the capacity to run the project, and clear ownership of the ERP integration and security controls. The areas most often underestimated are bulk and asynchronous API sync design, performance testing under catalog load, PCI DSS scoping, and the patch cycle that continues after launch. Many manufacturers split the work instead. Their own staff own product data, business rules and approvals, while an outside partner handles architecture, custom modules and integration build. Whichever path you choose, confirm that someone internal can operate the store after go-live, including patching, incident response and the upgrade calendar.
Does ISA/IEC 62443 apply to a Magento store for manufacturers?
Generally, the web store is not an industrial automation and control system, so the ISA/IEC 62443 series does not apply to it directly. It becomes relevant where the store's connections reach operational technology, for example if order, stock or pricing data flows into plant systems or shares network segments with them. In that case, your OT security team can use ANSI/ISA-62443-2-1-2024 to define the security program for asset owners and ANSI/ISA-62443-3-2-2020 to run a risk assessment that sets zones and conduits between IT and OT. Confirm the boundary with that team and document it before the integration is designed.
Does the EU Cyber Resilience Act apply to our online store?
The Cyber Resilience Act applies to products with digital elements placed on the EU market, and a store you operate is a hosted service rather than a product in that sense, so the first question is whether you sell software or connected products. Regulation (EU) 2024/2847 applies to such products from 11 December 2027, while manufacturers' Article 14 reporting duties for actively exploited vulnerabilities and severe incidents have applied since 11 September 2026. Breaches of the essential requirements can draw fines of up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher. Manufacturing is also a critical sector under NIS2. Have legal counsel confirm your obligations and map them to your product lines.
How does Magento Open Source differ from Adobe Commerce for manufacturers?
Magento Open Source is licensed under the Open Software License 3.0, with the Academic Free License 3.0 also included in the distribution, and provides the core ecommerce capabilities for building an online store. Adobe Commerce is Adobe's commercial edition, and Adobe documents both editions together. The differences that matter for a manufacturer are the features included in each edition, the support contract, and the hosting model. Self-managed installations use Varnish as the full-page cache, while cloud-hosted Adobe Commerce uses Fastly. Open Source gained the clearCart GraphQL mutation in 2.4.9, which had been Adobe Commerce only. Mage-OS is a community-owned alternative built on Magento Open Source. Compare each edition against your written requirements, because this page does not list every feature gap.
How do Magento upgrades affect our build and running effort?
Adobe recommends upgrading every patch cycle to stay secure and PCI compliant, so upgrades are an ongoing cost rather than a one-time event. Effort rises with customizations, extension count, third-party integrations and the coding practices in your modules, and Adobe points buyers to the Upgrade Compatibility Tool to check readiness. Lifecycle dates matter for planning. Adobe gives each 2.4.x release three years of standard support, with end of regular support on August 11, 2026 for 2.4.6, May 31, 2027 for 2.4.7, May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9. The 2.4.9 requirements list PHP 8.5, OpenSearch 3 and RabbitMQ 4.3. Build the upgrade path into the initial design, and ask whether upgrades are priced as a fixed-scope project or a retainer.
How DeployOpen scopes and supports manufacturer Magento projects
DeployOpen plans, builds, documents and supports Magento Open Source stores inside infrastructure you control, including manufacturer catalogs with configurable and bundle products, multi-warehouse stock and ERP synchronization. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support available as a retainer.
How we scope
- The written scope lists catalog structures, such as configurable and bundle products, and which product data systems feed them.
- Stock design covers warehouses, sources and the rules for source selection, agreed with your fulfillment team before build.
- Integration scope names each ERP price and inventory flow, the API style used, and who owns data mapping and error handling.
How we build
- Custom modules and themes follow the component structure Adobe documents, with PSR-4 compliant module layout.
- Catalog imports from product information systems are built and tested against representative sample data before production loads.
- Staging environments match the planned production stack, including the PHP, database, search and cache versions Adobe lists for the chosen release.
How we hand over
- Deliverables include the code repository, deployment runbooks, configuration records and integration mapping documentation.
- Test evidence covers catalog import results, stock and price sync checks, and checkout flows agreed in the scope.
- Handover sessions cover upgrade steps, patching routines and the Upgrade Compatibility Tool workflow for your team.
How we support
- Ongoing support, patching and upgrades across Adobe's 2.4.x release lines are available as a retainer.
- Support scope is agreed in writing and can include monitoring of integration queues and bulk API job results.
- Patch cycles follow Adobe's published schedule, and your team confirms the supported version combinations before each change.
