Why Magento Open Source ERP integration fails in production and where the work sits
A Magento Open Source store has to agree with the ERP on stock, prices, orders and invoices, and the integration that keeps them in step is almost always work someone builds and then owns. Magento Open Source does not ship with a connector for most ERPs. The link between the two systems is therefore one of three things: custom modules inside the store, a middleware layer that sits between the systems, or a vendor connector purchased for a specific ERP. In each case, the client owns the result after handover, including its code, its credentials, its schedules and its failure handling. That ownership is the first thing to settle, because it determines who fixes the integration when it breaks at 2 a.m. during a promotion.
The data moves in two directions, and the failures differ by direction. Catalog content and prices usually flow from the ERP into the store, so the risk is that the store displays a product, price or stock level the ERP no longer supports. Orders and invoices flow the other way, from the store into the ERP, so the risk is that a paid order never reaches finance or that an invoice is created twice or not at all. Stock is the most sensitive field because it crosses both directions: a delayed inbound stock update produces overselling, and a failed outbound order update can leave the ERP believing stock is still available. Confirm with your ERP vendor which objects it accepts through its API, whether it supports incremental or full updates, and what its rate limits and batch sizes are.
Sync errors rarely stop the store. They surface later and in business terms. A failed message from the order queue can leave an order present in Magento but absent from the ERP, which shows up as a missing invoice at month end. A stock update that arrives out of order can show items as available after the warehouse has shipped them, which shows up as cancellations and refunds. Ask the team that will own the integration how failed messages are retried, where they are stored, who is alerted, and how a reconciliation report compares order and stock counts between the two systems. Message queue behavior and consumer configuration differ by Magento version, so confirm the queue and consumer details against the documentation for your exact release.
Upgrade effort is where the integration cost keeps accruing. Adobe's upgrade guidance names customizations, extension count, third-party integrations and coding practices as drivers of upgrade effort. An ERP integration is usually both a custom module and a third-party integration, so every Magento patch or minor upgrade can touch its code, its extensions or the libraries it depends on. Before committing to a design, ask for a written list of every module, extension and external dependency the integration uses, and plan a test run of the integration on each new patch of your supported line. The Upgrade Compatibility Tool referenced in Adobe's guide can help identify compatibility problems, but it does not test your business workflows, so budget for that verification separately.
Where the work sits, in practice, is in four places: the interface and data mapping with the ERP, the queue and retry design inside Magento, the reconciliation and alerting that catch silent failures, and the ongoing testing that keeps all three working through upgrades. Implementation effort is one-time, while monitoring, patch testing and fixes for ERP-side changes recur for as long as the integration runs. When you request a quote, ask the provider to separate these components, to state who maintains the middleware or connector license, and to explain what happens to the integration when the ERP itself is upgraded.
Which Magento components and extension points carry ERP data
An ERP link touches more of the store than the API alone. Product, stock, price, order and invoice data move through modules, web services, queues, indexers and cron jobs, and each one can fail in its own way. The cards below name the parts that matter so the integration design covers every path data takes.
Custom integration modules
ERP code lives in custom modules that follow the PSR-4 autoloading structure described in Adobe's developer documentation. Keeping the ERP connector in its own module, with its own service contracts and configuration, lets the team upgrade Magento without rewriting the integration. Confirm the module layout and dependency rules against the Magento version you will run, since the framework's extension points change between releases.
REST and GraphQL endpoints
Magento exposes REST and GraphQL endpoints that the ERP or middleware can call for reads and writes on products, stock, customers and orders. Decide which operations go through which interface, and which token type and permissions each integration user holds. Confirm which endpoints and mutations exist in your target version, because GraphQL coverage differs between releases. For example, the clearCart mutation is listed in the 2.4.9 release notes as now available in Open Source.
Asynchronous and bulk operations
Bulk API operations accept large batches of product, stock or order changes and process them outside the request cycle, so the ERP does not wait on each record. This suits nightly price loads and large catalog updates. Check how the target version reports bulk operation status and failed rows, because the ERP needs that feedback to retry the right records and avoid silent gaps.
Message queue consumers on RabbitMQ
Asynchronous messages wait in RabbitMQ queues until consumers pick them up. Adobe's 2.4.9 system requirements list RabbitMQ 4.3, but queues only process when consumer processes are running, so a stopped or unmanaged consumer leaves ERP updates waiting without an error on screen. Include consumer startup, supervision and queue monitoring in the design, and confirm the RabbitMQ version against the requirements for your release.
Indexers and cron
Indexers rebuild the storefront data that the ERP changes feed, such as product visibility, price and stock status. Cron runs scheduled jobs, including indexing and queue-related tasks, so a stalled cron can make correct ERP data look wrong on the storefront. Decide which indexers run on schedule and which update on save, and confirm the indexer modes and cron setup for your target version.
Inventory and price data stores
Stock and price data sit in their own tables and services, separate from the product record. Multi-source inventory and per-website or customer group pricing change how an ERP stock or price update must be targeted. Map each ERP field to the store structure it writes to, and confirm with the vendor and your own catalog setup which inventory and price features are enabled in your installation.
Choosing the integration pattern, middleware and sync model
This table compares four ways to connect Magento Open Source to an ERP and shows the sync choices that follow from each. Read each row against your catalog size, number of sales channels and how much custom code your team can maintain through upgrades. The main takeaway is that the operational cost of each option sits mostly after go-live, in monitoring, patching and upgrade work.
| Option | When it fits | Operational cost | Watch for |
|---|---|---|---|
| Direct point-to-point calls | One ERP, one store, a small catalog and a limited set of data flows such as orders and stock | Lowest added systems, but your team owns retry logic, mapping and error handling inside Magento code | Each new ERP or channel adds another custom connection that must be tested on every Magento patch |
| iPaaS or middleware layer | Several sales channels or ERPs, or teams that need transformation and routing outside the store | Recurring platform licence, another system to patch, monitor and secure, and vendor-specific connectors | Vendor lock-in on mappings and flows; confirm the connector supports your Magento and ERP versions |
| Packaged ERP connector extension | The ERP vendor or an established partner already ships a maintained Magento connector covering your data types | Extension licence or subscription, plus upgrade review each time Magento or the ERP changes | Extension code runs inside Magento, so every Magento patch and PHP change can break it; confirm the compatibility matrix |
| Custom module with a message queue | Complex rules, high order volume or peak-time decoupling, with in-house or contracted developers who will maintain it | Development and maintenance effort, plus RabbitMQ to run, patch and monitor alongside Magento | Consumer failures and dead letters need alerting; custom modules must follow PSR-4 structure and survive upgrades |
| Real-time push sync | Stock and price changes that must reach the storefront quickly, such as limited inventory or flash pricing | Higher load on both systems and more failure paths to handle during ERP outages | Needs idempotent handling so a retried message does not double-post an order or stock change |
| Scheduled batch sync | Product catalog, bulk price lists and nightly reconciliation where minutes of delay are acceptable | Simpler to monitor and replay, but stale data window must be stated to the business | Batch windows can collide with Magento indexers and cron jobs on the same server |
| Hybrid sync | Most mid-size stores: orders and stock pushed in near real time, catalog and prices in scheduled batches | Two sync paths to design, test and monitor, with reconciliation jobs to catch gaps | Confirm which direction wins on conflicts for each field before build starts |
| System of record by data type | Products and attributes often start in the ERP or PIM; orders originate in Magento; invoices and payments usually sit in the ERP | Clear ownership reduces duplicate edits and reconciliation effort | Agree the owner for each field, including customer records, tax and promotional prices, in writing before design |
Build sequence for an ERP sync that can be tested and replayed
This sequence takes an ERP sync from agreed data ownership to a staged cutover that can be measured and rolled back. Each step closes with a reconciliation or test, so the team can confirm correctness before the next step starts and replay failed messages without creating duplicates.
Fix the data ownership map and field mapping
Decide which system owns each field for SKUs, price lists, stock locations and order statuses, then write a field-by-field mapping that names the Magento attribute or field, the ERP field, the transformation and the direction of each flow. Confirm with the ERP team who may change a status value and how conflicts are resolved when both systems edit the same record. The business owner signs off the mapping. The step closes when sample records from each category are traced end to end through both systems and every field in the mapping is either populated or explicitly marked as not synced.
Set up a non-production environment matching live versions
Provision a staging environment with the same Magento Open Source patch level and the same PHP, database, search, cache, queue and nginx versions as production. For 2.4.9, Adobe's system requirements 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, and Adobe supports only the listed combinations. Confirm the versions of the ERP connector or middleware as well. The step closes with a version inventory compared against production, showing no differences in the listed components, and an anonymized data set loaded into staging.
Build the outbound order and invoice flow
Assign each order and invoice a stable external key built from the Magento entity identifier and the event type, store it in the integration tables and require the ERP to reject any record whose key already exists. Retries reuse the original key, and status changes carry a sequence number so out-of-order messages can be detected. During testing, force timeouts on the ERP endpoint, let the retry logic run, and confirm that each order and invoice appears once. The step closes when the count of ERP records equals the count of Magento orders and invoices in the test window, with totals matching to the cent.
Build the inbound catalog, price and stock flow
Run product, price and stock messages on separate queues so a large price file cannot block stock updates. Group messages into batches sized through load testing and process them with queue consumers that upsert by SKU, price list or stock location, which keeps repeated deliveries safe. Consumer processes should be monitored for backlog and restarted automatically. The step closes when a full day's file set is replayed and the SKU count, the price per price list and the quantity per stock location match the ERP extract with no unexplained differences.
Add logging, an error queue and a replay tool
Log each message with its key, direction, status, attempt count and timestamp. Route messages that fail after the retry limit to a dead-letter or error queue that keeps the original payload and the error reason. Build a replay tool that resends selected messages by key or time range and skips keys already applied. Test by injecting a malformed message and a failing endpoint, then confirm the message lands in the error queue with its reason logged. After the fault is fixed, replay the messages and confirm that already-applied keys produce no new records. The operations team should own this tool after handover.
Run a controlled data load and reconcile
Load a bounded set of catalog, price, stock and historical order data into staging through the same flows used in production. Compare counts and totals per entity between Magento and the ERP: SKU counts, quantities per stock location, order counts, grand totals, invoice totals and tax. Classify every difference as a mapping issue, a timing issue or a defect, and fix each one before rerunning. The step closes when the reconciliation report shows no unexplained differences and a second run of the same load produces identical results.
Cut over in stages with a rollback plan
Move flows to production one at a time, such as catalog and prices first, then stock, then orders, and keep the ERP as the source of truth for each flow until the next stage passes its checks. Before cutover, write the rollback plan: which queues to pause, how each write is reversed, who makes the decision and how messages received during the switch are replayed. Rehearse the rollback on staging and confirm it restores the pre-cutover counts and totals exactly. The production cutover closes when its reconciliation report matches the same counts used in the rehearsal.
How to test the ERP link and confirm it fails safely
The purpose of testing the Magento Open Source to ERP link is to prove two things: that the numbers agree after normal and abnormal traffic, and that when something breaks, the store holds the work instead of corrupting it. Start with reconciliation, because a link that looks healthy in logs can still drift. After a full load of products, stock and prices, compare SKU counts, stock quantities, price rules and order totals between Magento and the ERP for a defined sample and for the full population where the tooling allows it. Record the comparison method, the date, the data set and every exception. Then place a set of deliberate test orders covering simple products, configurable products, discounts, tax, shipping and partial shipments, and reconcile each order's totals and status across both systems.
Next, run the failure tests against a staging environment that mirrors production queue and consumer settings. The first test takes the ERP offline while customers place orders on the storefront. The expected safe behavior is that orders are accepted, held in a queue or pending state, retried on a schedule, and released to the ERP once it returns, with no order lost and no order sent twice. The second test delivers the same order or stock message more than once. Confirm that the consumer treats the duplicate as already processed and that no second invoice, shipment or stock adjustment is created. The third test sends a message containing a SKU that does not exist in Magento. The expected behavior is that the message is rejected or parked with a clear error, the rest of the batch continues where the design allows, and an operator sees the failure in the admin, the message queue tooling or a monitored log.
The fourth test delivers a stock update out of order, for example an older quantity arriving after a newer one. Confirm that the design uses a sequence number, timestamp or ERP version field to ignore stale updates, and that the final stock figure matches the ERP after reconciliation. The fifth test stops the consumer process while a batch is in progress, then restarts it. Expected behavior is that no message is lost or half-applied, unacknowledged messages are redelivered, and the reconciliation after restart matches the ERP. Confirm with your integration partner or middleware vendor exactly how acknowledgment, retry limits and dead-letter handling are configured in your version of RabbitMQ and your connector, since these settings decide the outcome.
Record evidence for every test. Keep the test plan, the environment and software versions, the input data, timestamps, queue and log excerpts, screenshots of operator alerts, the reconciliation reports and the sign-off by the person responsible for each result. Auditors, internal reviewers and, where payments are involved, PCI DSS assessors ask for this kind of material later, and it is far harder to reconstruct after go-live. Retain the evidence under your normal change records, and repeat the failure tests after any ERP connector, middleware or Magento upgrade. Where a test fails, log the defect, fix it, and rerun the test rather than accepting a partial pass.
What drives the effort and how to keep it down
This table lists the factors that most change the effort of a Magento Open Source ERP integration, how each one raises the work, and the practical lever that keeps it under control. Read each row as a question to settle before the scope is written, because most of these drivers are set in the first design decisions rather than during build. The main takeaway is that a narrow first release with agreed data ownership usually does more to control effort than any single technical choice.
| Driver | Why it raises effort | How to keep it down |
|---|---|---|
| ERP entities and fields mapped | Each entity (products, prices, stock, customers, orders, invoices) and each field needs a mapping, validation rule and test case. Custom ERP fields add mapping work on both sides. | Limit the first release to core flows and the fields the storefront and finance actually need. Add optional fields in later phases. |
| Data ownership between ERP and store | When it is unclear whether the ERP or Magento owns a price, stock level or customer record, teams rebuild the sync logic during testing. | Agree a written data ownership map for every entity before design starts, and name one owner per field. |
| Order volume and peak load | Higher order and sync volume means more queue workers, retry handling, batching and monitoring. Peak events such as promotions raise the load on both systems at once. | Confirm expected peak order rates with the business, then size queues and batching around that figure. Use asynchronous message queues for order and stock updates rather than synchronous calls on every page request. |
| Number of channels or storefronts | Each storefront, marketplace or store view can need its own price lists, stock locations, tax settings and order routing. | Start with one storefront and one stock model. Add channels as separate phases with their own test cycles. |
| Existing integrations already in place | Extensions, middleware or point-to-point connections that already touch orders or stock create conflicts, duplicate events and extra regression testing. | Inventory every existing connection during discovery. Retire or consolidate overlapping ones before the new integration goes live. |
| Custom logic in pricing and tax | Customer group pricing, tiered rules, or tax calculated partly in the ERP means the store and ERP must agree on the same result, which needs extra tests and reconciliation reports. | Decide which system calculates each price and tax component. Keep the calculation in one place and send the result to the other system. |
| Test environments needed | Testing a two-system sync needs a Magento environment, an ERP sandbox or test company, and a message broker that match production versions. Missing environments push testing into production. | Ask the ERP vendor whether a sandbox or test tenant is included. Budget for at least one environment that mirrors the production Magento and queue versions. |
| Quality of the ERP's own APIs and data | Slow, rate-limited or inconsistent ERP APIs, missing change timestamps, and poor master data quality require workarounds such as polling, retries and data cleansing before the sync can be trusted. | Review the ERP's API documentation, rate limits, change notification options and support for bulk operations early. Clean key master data such as SKUs and customer IDs before the first load. |
| Connector choice and upgrade path | A connector with no supported upgrade path must be re-tested and sometimes rewritten at each Magento patch cycle, which repeats effort over the life of the store. | Ask the connector vendor which Magento 2.4.x versions it supports and how upgrades are delivered. Confirm the versions against the Magento system requirements for the release you plan to run. |
How the integration changes for single node, high availability and air-gapped stores
On a single node, the web server, database, search, cache, queue consumers and cron all run on one host. The integration has one place to fail and one place to inspect when a sync stops, which keeps the design simple. The main risk is resource contention, because consumers and cron jobs compete with storefront and admin requests for CPU and memory during order peaks.
- Queue placement: The broker and consumer processes usually share the host, so one process manager can start, stop and restart them together.
- Credentials: One set of service accounts often covers the ERP connector, the broker and the database. This is quick to set up, but a leaked secret exposes every integration point.
- Network paths: All calls to the ERP or middleware leave the same host, so a single set of outbound firewall rules governs the integration.
- Logging: Web, consumer and cron logs share one disk. This helps tracing but fills storage faster, so set log rotation and copy logs off the host.
- Failover: The host itself has no failover. Plan a tested restore procedure and confirm how queued messages behave if the host reboots during a sync.
Confirm that the consumer runner, cron configuration and broker version match the combinations listed in Adobe's system requirements for your chosen 2.4.x release.
With several web nodes behind a load balancer, every node can serve storefront and admin traffic, but background work must run once, not once per node. The integration needs deliberate consumer placement and a broker that every web node can reach. Without this design, the same ERP update can be posted several times.
- Queue placement: Run the broker on a shared tier that all web and worker nodes can reach, and confirm how the broker cluster handles the loss of one member.
- Consumers: Decide which nodes run each consumer and the cron jobs that trigger them. Running the same consumer on every node can duplicate stock updates, price changes or invoice postings, so assign consumers to a dedicated worker tier or a designated node.
- Credentials: Where the ERP and broker support it, give each node or worker group its own service identity. A revoked credential then affects one node, and audit logs show which node made each call.
- Network paths: Open the broker and ERP ports from every web and worker node, and keep the middleware endpoint reachable from the worker tier without exposing it to the public internet.
- Logging and failover: Aggregate logs from all nodes with the node name on each entry. Test what happens when the node running a consumer fails, and confirm whether another node picks up unacknowledged messages.
Confirm with Adobe's system requirements and your broker vendor that your RabbitMQ version and clustering method are supported for your release before you design the topology.
In an air-gapped or restricted network, the ERP and middleware sit on a separate segment, and the store cannot download packages or reach external services during installation or patching. Every dependency must be mirrored into the restricted zone, and every crossing between zones becomes a control that must be documented and tested.
- Queue placement: Keep the broker and consumers on a defined side of the boundary, and make sure the data flow diagram matches where each queue actually runs.
- Credentials: Use separate credentials for each zone crossing, store them in the vault approved for that zone, and rotate them through a procedure that works without internet access.
- Network paths: Allow only the named ports and endpoints through the gateway or brokered connection. Confirm with the network team that the gateway supports the protocols the ERP connector uses.
- Packages: Mirror the Magento codebase, PHP extensions, Composer packages, OS packages and the broker, search and cache packages into an internal repository. Confirm the exact package set with Adobe's documentation for your release, because a missing dependency often appears only at patch time.
- Logging and failover: Forward logs through the approved collector across the boundary, and agree a failover path that does not depend on reaching a public update or package service during an incident.
Confirm the mirror contents and supported versions against Adobe's system requirements for your chosen release before the mirror is built.
Securing ERP credentials, API access and message content
The ERP connection is one of the few places where Magento holds credentials for a system of record and passes customer data out of the store. The controls below cover who and what can reach the ERP, where secrets live, how traffic is protected, and who can read the queued messages that carry order and customer details.
Dedicated integration user with minimum rights
Create a separate integration identity on the ERP side for Magento, rather than reusing a person's account or an administrator login. Grant only the object permissions the sync needs, such as reading products and stock, writing orders and reading invoice status. Review the permission set against each flow in the integration design, because ERP roles tend to grow over time. Ask the ERP team which permissions are required for each direction of sync and document the answer.
Separate credentials for each environment
Development, staging and production should each use their own ERP credentials, tokens and middleware endpoints. Test environments often connect to a sandbox ERP with copied production data, so a shared credential can expose live systems to test code. Confirm that a token issued for staging cannot authenticate against production, and that rotating one environment's secret does not disturb the others. Record the owner and rotation schedule for each credential set.
Secrets kept out of code and the admin
API keys, client secrets and database passwords for the ERP link should be held in a secrets manager or in environment configuration managed by the hosting team, not committed to a repository or stored in plain text in the Magento admin. Where the ERP connector needs values in the Magento configuration, confirm how they are encrypted at rest and who can read them. Check that secrets do not appear in logs, error reports or exported configuration files.
TLS between Magento, middleware and ERP
Every hop in the link should use TLS with certificates that the sending side validates, including the call from Magento to middleware and from middleware to the ERP. Disable certificate verification shortcuts in test code before they reach production. Confirm which protocol versions and cipher suites the ERP endpoint accepts, and set the same minimum on the Magento side. Plan certificate renewal with an owner, since an expired certificate stops order flow without an obvious error in the store.
Allowlisting source addresses
Restrict inbound connections to the ERP and middleware so that only the outbound addresses of the Magento web and worker nodes can reach them. Ask the hosting team for the egress addresses of every node, including those added by autoscaling or a managed NAT gateway, and update the allowlist when they change. Pair the allowlist with credentials, not instead of them, because addresses can be spoofed inside a network and shared hosting ranges change. Review the list during each infrastructure change.
Access to queued message content
Queued messages for orders and customer updates often contain names, shipping addresses and contact details. Limit who can view, retry or replay them in the message queue console, the middleware dashboard and the database tables that hold them. Log replay actions with the operator's identity. Set a retention period for completed and failed messages that matches your data handling policy, and confirm that purged messages are removed from backups on the schedule you have promised.
Keeping payment data off the ERP link
Card numbers and payment authorization data should not flow through the ERP integration at all. The ERP needs an order reference, a payment status or an invoice reference, not the card or the gateway token. Verify this in the integration mapping, in the message payloads and in the logs, because payment fields are sometimes copied into order objects by default. Scope decisions for the payment page are covered in the PCI DSS compliance guidance, and the store's Content Security Policy and admin hardening are covered on their own pages.
What to monitor, back up, upgrade and document after go-live
The integration does not finish at go-live. Once products, stock, prices, orders and invoices move between Magento Open Source and the ERP, someone must watch the flow every day, keep its data recoverable, and keep it working through every platform change. Assign those duties before launch, not after the first incident. Start with the signals that show whether messages are moving. Track queue depth for each consumer, the status of each consumer process, the count of failed messages, the lag between an order being placed and the ERP receiving it, and the number of reconciliation differences found in each comparison run. Set a threshold for each one and decide who is paged when it is crossed. A rising failed-message count with a flat queue usually means a mapping or data problem, while a growing queue with stopped consumers usually means a process or broker problem, so the alerts should point the on-call engineer to different runbooks.
Backups for this integration cover three stores: the message store used by RabbitMQ, the mapping configuration that translates Magento attributes and ERP codes, and the integration logs. Ask the business to set retention periods for each, because finance and tax teams often need order and invoice logs for longer than engineers need debug output. Confirm with your ERP partner whether replaying messages from the broker is enough to recover a lost window, or whether you also need the ERP-side records to rebuild state. Test a restore of the mapping configuration on a non-production environment, since a backup that cannot be loaded is not a recovery plan. Treat the integration module as part of every patch cycle, not as a side project. Adobe's upgrade guide recommends upgrading every patch cycle to stay secure and PCI compliant, and it names third-party integrations as one of the drivers of upgrade effort. Your custom or vendor connector code therefore needs an owner who reviews each Magento patch against it. Upgrade scope and timing are covered in the sibling upgrade topic, so use that guidance to plan the cycle itself.
Re-test the sync after any change to Magento, PHP, RabbitMQ or the ERP. A minor PHP or RabbitMQ change can alter how consumers handle connections and serialization, and an ERP upgrade can change field validation or API responses without changing your code. Keep a regression suite that replays a fixed set of product, stock, price, order and invoice messages end to end, and compare the ERP results with expected values. Record the version of every component in the test report so an auditor or incident reviewer can see what was tested. Document the integration so someone other than its builders can run it. The core documents are a data ownership map that states which system is the source of truth for each entity and field, a field mapping sheet with transformations and default values, and an alert register that names the owner and escalation path for each alert. Add runbooks for two common cases: a stuck queue, where you check consumer status, broker health and the failed-message store before restarting anything, and a replay procedure, which states who approves a replay, how duplicate orders are prevented, and how the result is reconciled. Finally, confirm ownership in writing. Name a person or team for monitoring, backup restores, patch review, post-change testing and documentation upkeep, and review the register after each platform change or staff move. Illustrative example: if the ERP team owns invoice mapping but the store team owns the consumer servers, a stuck invoice queue can sit unnoticed for days because each team assumes the other is watching it.
Questions buyers ask before building a Magento ERP integration
What drives the cost of a Magento ERP integration?
Four areas drive the cost: the ERP side, the Magento side, testing and the run cost after go-live. The ERP side covers API access, licensing and any vendor or consultant time needed to expose the data objects you need. The Magento side covers module development, data mapping and how much custom logic sits in pricing or stock rules. Testing covers test environments, test data and the cycles needed for sign-off. Run costs recur: hosting for queues and workers, monitoring and maintenance across Magento patch releases. Build work is one-time, while monitoring and maintenance recur. In a written quote, ask who is paid for each line: your ERP vendor, DeployOpen under the agreed scope, or your own staff time. The number of data objects and sync directions usually moves effort more than any single feature.
Is a packaged connector or a custom build better for Magento?
A packaged connector is faster to start, a custom build gives more control, and the right choice depends on fit. Check whether the connector supports the data objects, sync directions and ERP version you run, and whether its maintainer supports the Magento 2.4.x line you plan to use. Custom builds suit unusual ERP logic, such as multi-warehouse stock rules or contract pricing, but your team owns every upgrade. Adobe's upgrade guide names customizations, extension count, third-party integrations and coding practices as drivers of upgrade effort, so count those integrations in the comparison. Ask the connector vendor for its compatibility statement and release history, and test it against your own data before buying. A hybrid is also possible: a maintained connector for standard objects and a thin custom layer for the rest. Be explicit about who fixes a connector defect and how fast.
How long does an ERP integration usually take to build?
Duration depends on scope and on how ready the ERP is, so no fixed figure applies. The main drivers are the number of data objects, whether sync runs one way or two ways, the maturity and documentation of the ERP's API, and the quality of product and customer data on both sides. Timelines stretch when sandbox access is delayed, when data owners take a long time to decide mapping rules, or when test cycles fail and repeat. Multi-warehouse stock, custom price tiers and split orders add design time. Ask for a timeline in the written scope tied to milestones, and ask what the plan assumes about access and sign-off dates. If a vendor gives a duration before reviewing your ERP API and sample data, ask what that estimate is based on.
What does our internal team need to provide for the integration?
Your team provides access, data owners, test cases and one sign-off owner. Specifically, provide ERP API credentials and a non-production sandbox with representative data volumes. Name data owners for products, prices, stock, customers, orders and invoices who can confirm field mappings and business rules. Write test cases with expected results in business terms. Appoint one sign-off owner with authority to accept or reject the build. Also provide access to the hosting environment, change approval contacts and the ERP vendor's support route for API questions. Late access is a frequent source of delay, so confirm each item and its owner before work starts. Agree in writing what happens if an item arrives late, because that affects scope and timing.
Can our team build a Magento ERP integration without a partner?
Yes, a capable internal team can build it, but the core skills must be in place before work starts. You need Magento module development experience, including the PSR-4 module structure that Adobe's developer documentation describes, plus dependency injection and event handling. You also need message queue consumer design, experience with the ERP's API and its error model, and QA staff who can write data-level tests. Someone must own the code after go-live, including Magento patch releases and extension compatibility. If one of these skills is missing, the gap usually appears in testing or at the first upgrade. A practical check is whether two engineers on your team could explain the failure modes and the replay procedure without help. If not, a partner can fill the gap for the build, for support or for both.
How should we handle ERP sync failures after go-live?
Design for retries and visibility, then decide who acts on each failure. Make every sync operation idempotent so a retry does not create duplicate orders or invoices. Route failed messages to a dead-letter queue, alert on backlog growth and repeated errors, and produce a daily reconciliation report that compares store and ERP totals for orders, stock and invoices. Adobe's system requirements for 2.4.9 list RabbitMQ 4.3, so queue monitoring belongs in the run plan. Write a replay procedure with steps, permissions and a log of what was replayed. Assign a named owner for each alert class and rehearse the procedure before go-live. Document which failures a replay can fix and which need a decision from someone on the ERP side.
What should a written quote for an ERP integration include?
A written quote should turn the scope into named deliverables, assumptions and exclusions. List each data object (products, prices, stock, customers, orders, invoices) with its sync direction, frequency and system of record. Name the environments included, the test cycles and the acceptance criteria, and who signs off. State what the ERP vendor must provide, what your team provides and what happens if those items arrive late. Separate one-time build from recurring items such as queue hosting, monitoring, patch testing and support hours. Name exclusions explicitly, such as ERP-side configuration or changes to third-party extensions. Ask who is paid for each line and whether change requests follow a written process. DeployOpen works on fixed scope, with scope, deliverables and timelines agreed in writing before work starts, so compare every quote against that same level of detail.
How DeployOpen scopes, builds and hands over an ERP integration
DeployOpen plans, builds, tests, documents and supports Magento Open Source ERP integrations inside the client's own infrastructure, from the first scope discussion through handover. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts.
How we scope
- Inventory which ERP objects move between systems: products, stock, prices, orders and invoices, with the sync direction for each.
- Confirm the ERP's API style, whether REST or asynchronous, and the message queue or middleware the integration will use.
- Record the Magento Open Source version, PHP, MySQL or MariaDB, RabbitMQ and OpenSearch versions the integration must run on.
How we build
- Build the integration as custom modules that follow the PSR-4 structure Adobe documents for Magento Open Source extensions.
- Define how sync failures are retried, queued, logged and reported to the operations team before any production traffic flows.
- Test order and invoice flows end to end in a staging environment that mirrors the production stack, including the ERP side.
How we hand over
- Deliver the code, configuration, data mapping tables and a runbook covering monitoring, reprocessing and rollback steps.
- Walk the client's developers and operations staff through the sync design, failure handling and the admin tools they will use.
- Document the upgrade path so later Magento patches and ERP API changes can be tested against the integration without a rewrite.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer that starts after handover.
- Retainer scope covers integration checks during each Magento patch cycle and after ERP API version changes, as agreed in writing.
- Ask any provider to confirm response times and support hours in the written scope, since these vary by engagement.
