ERP Integration: Connecting Your ERP Without Rebuilding It
The clearest sign that an ERP needs integration work is a customer service agent with three tabs open. A customer asks a furniture manufacturer where her dining table is, and the agent checks the e-commerce platform for the order, the ERP for the sales order and the third-party warehouse’s portal for the shipment, then reads the three answers back and hopes they agree. The ERP is doing its job. The business has grown around it, and the gaps between systems are being filled by people.
ERP integration connects your enterprise resource planning system to the other systems the business runs on, such as e-commerce, CRM, warehouse and shipping, payroll and reporting, so that data moves between them reliably without manual re-entry. For most established companies, the right project is to build a well-governed layer around the ERP rather than to replace it: decide which system is the source of truth for each kind of data, pick a sync pattern that fits each flow, keep heavy reporting off the ERP’s production database and make every failure visible to the people who depend on it.
What Is ERP Integration?
ERP integration is the set of connections that move data in and out of the ERP: orders arriving from sales channels, inventory and pricing flowing out to storefronts, shipments and invoices returning from logistics partners, and financial data feeding payroll, commissions and management reports. The connections can be direct API calls, scheduled file exchanges, EDI messages with trading partners, or reads from a replica of the ERP database.
What makes ERP integration different from other integration work is that the ERP usually carries the company’s financial and operational record. A wrong quantity in a marketing tool is an annoyance. A wrong quantity in the ERP can change what the purchasing team orders, what the factory builds and what the finance team reports. That raises the bar for validation, audit trails and ownership on every flow that writes into it.
Should You Integrate Around Your ERP or Replace It?
Integrate around the ERP when its core functions still work and the pain sits in the processes that have grown up beside it. Consider replacing it when the ERP itself can no longer represent how the business operates, is losing vendor support, or blocks a requirement that no integration layer can work around.
The first case is the subject of a Gun.io brief about financial control built around a legacy ERP. A manufacturing and e-commerce business ran on SysPro, and payroll, commissions, inventory reconciliation and executive reporting had drifted into spreadsheets, manual extraction and repeated calculations. The client did not need to replace SysPro. Gun.io built a self-hosted layer around it for data, workflows and internal applications, pulling data straight from the ERP and rebuilding those processes on one consistent foundation. While rebuilding the commission workflow, the team found source data missing from the spreadsheet process it replaced, a gap in controls the old setup had made hard to spot.
Replacing an ERP is a long program that touches every department and changes how people work in all of them. Building around it lets you fix the most expensive manual process first, prove the approach, and extend the same layer to the next workflow without starting over.
Which System Should Be the Source of Truth?
Every shared piece of data needs exactly one system that owns it, and the integration should be designed around those owners. Most ERP integration problems that look like sync bugs are really ownership disputes that nobody resolved.
For the furniture manufacturer, a workable split might look like this:
| Data | Usual owner | What the other systems do |
|---|---|---|
| Item master and bill of materials | ERP | Read only; storefronts display what the ERP defines |
| Prices and discounts | ERP or a pricing system, decided once | Read only downstream |
| Available inventory | ERP | Storefronts read a published availability figure |
| Customer contact details | CRM | ERP receives what billing and shipping need |
| Web orders | E-commerce platform until accepted, then ERP | One handoff point, one order number carried across |
| Shipment status | Warehouse or carrier | Written back to the ERP against the order |
Two rules make the table useful. First, no system writes over data it does not own. If a customer service agent corrects a shipping address in the CRM, the correction flows to the ERP; a nightly ERP export should never overwrite it with the old value. Second, every record carries a cross-reference that survives the trip, such as the web order number stored on the ERP sales order, so anyone can trace a record from one system to the next.
Inventory deserves its own decision. “How many do we have?” means different things to purchasing, production and sales. The legacy ERP brief describes inventory workflows that distinguish physical inventory, committed material, work in progress and finished goods. Agreeing on which of those figures the storefront shows, and how often it refreshes, prevents both overselling and hiding stock you could have sold.
Which Sync Pattern Fits Each Flow?
Choose the sync pattern flow by flow, based on how fresh the data must be, how much of it there is and what the ERP can safely support. There is no single right pattern for a whole ERP integration.
Scheduled batch moves data on a timetable, such as a nightly item and price sync or an hourly shipment import. It is simple to reason about and easy to rerun, and it suits data that changes slowly or where a delay does no harm.
Near real time through the ERP’s API or events suits flows that people wait on, such as order acceptance or available-to-promise inventory for a storefront. It needs more care around retries, ordering and load on the ERP.
EDI and partner file exchanges remain common with large retail customers and logistics providers. The integration’s job is often less about transport and more about tolerating what arrives.
Read-only access to a replica or reporting copy suits analytics and dashboards. It keeps heavy queries away from the system that is taking orders.
One pattern to avoid: writing directly into the ERP’s database tables to save time. ERPs enforce business rules, costing and audit trails in their application layer, and a direct insert can bypass all of it. Write through the interfaces the ERP vendor supports, even when they are slower to work with.
How Do You Handle Messy Data From Partners?
Expect partner data to arrive inconsistent and design the intake to validate, correct what it safely can and quarantine the rest, rather than failing the whole batch. A single malformed row should never stop every other order from reaching the warehouse.
Gun.io’s manufacturing ERP integration brief shows what the alternative costs. The client, a high-volume decor and framing manufacturer serving large retailers, relied on independent Python scripts talking to SysPro through an unstable C# bridge. Order files from retail partners were often inconsistent, and an extra comma or a shifted CSV column would crash the parsers and halt fulfillment until someone intervened. The rebuild moved the system to a unified C#/.NET environment and added validation that identifies column shifts and checks field types before ingestion, so malformed files no longer stop the pipeline.
Any ERP intake can follow the same approach. Validate structure and types at the edge. Hold rejected records in a queue where a person can see the original file, the reason it failed and a button to resubmit once it is fixed. Report partner data problems back to the partner with enough detail that they can correct the source, because the same error will otherwise arrive every week.
How Should ERP Data Feed Reporting?
Feed reporting from a copy of the ERP data shaped for analysis, not from live queries against the ERP’s production database. Month-end reports, margin analysis and executive dashboards run large queries, and running them against the system that is processing orders slows both.
A reporting layer extracts data from the ERP on a schedule, joins it with data from the other systems and stores it in a form that answers the business’s actual questions. In the legacy ERP brief, month-end reporting was redesigned around the same data foundation as payroll, commissions and inventory, which reduced the repeated extraction, transformation and validation steps finance had been doing by hand.
The reporting layer is also where definitions get settled. If “gross margin” in the board report is calculated differently from “gross margin” in the sales dashboard, the integration has moved the spreadsheet problem rather than solving it. Write the definitions down and compute them once. If you are staffing this work, the data engineer job description covers the role that usually owns pipelines and definitions like these.
How Do You Make ERP Integration Failures Visible?
Make failures visible to the business as well as to engineers, with a view that shows each flow’s status, what failed and why. When integrations run as background scripts with no interface, every problem becomes a forensic exercise.
In the manufacturing brief, warehouse staff had no way to see why an order failed to sync or why a customs form was malformed, and simple glitches turned into hours of manual auditing. The rebuild added a visual audit log where stakeholders can watch data move through the pipeline, with documentation built into the interface so non-technical leads can understand the business logic.
You do not need the same tooling to apply the principle. For each flow, show the last successful run, the number of records processed and rejected, and the oldest unresolved error. Alert the owner of the business process, such as the fulfillment lead for shipment imports, as well as the engineer. A planner who can see that yesterday’s shipment file was rejected can act before customers start calling.
Who Should Own an ERP Integration?
Give each integration flow both a business owner who decides what correct looks like and a technical owner who keeps it running. ERP integrations sit between departments, and without named owners they become nobody’s job until month-end goes wrong.
On the technical side, a small team usually works better than a large one. At Gun.io, we tend to favor a small team of full-stack engineers comfortable working across the ERP’s interfaces, the integration services and the screens the business uses, because the person who understands why a record was rejected is then the person who builds the screen that explains it. Bring in specialist depth where the work needs it, such as EDI standards for a demanding retail partner or the ERP vendor’s own customization framework. For .NET-heavy ERP environments like the one in the manufacturing brief, engineers comfortable in C# and .NET are often a practical fit.
How Gun.io Approaches ERP Integration
Internal tools and workflow automation around legacy ERPs, from payroll and commissions to inventory and financial reporting, are work Gun.io has done, as the two briefs above describe. Our first question on an ERP project is which manual process costs the business most, since the answer usually decides what the integration layer should do first and what kind of engineer should build it.
If you have someone who owns the ERP and a roadmap for the layer around it, augmented engineers can work under that person’s direction. If nobody has mapped the processes yet, a scoped project lets Gun.io take on the architecture, delivery and engineering management. Engagements carry no minimum commitment, and Gun.io’s solutions page shows the range of engineering work available.
Frequently Asked Questions
What Are the Main Types of ERP Integration?
The main types are point-to-point connections between the ERP and one other system, a middleware or hub layer that connects several systems through one place, file and EDI exchanges with trading partners, and a data layer that extracts ERP data for reporting and internal applications. Most companies end up with a mix, chosen flow by flow.
Can You Integrate an Older On-Premises ERP?
Yes, in most cases. Older on-premises ERPs often expose a vendor-supported API, an import framework or a reporting database that an integration layer can use, and the SysPro work in Gun.io’s briefs is an example of integration built around an existing ERP instead of swapping it out. The constraint is usually documentation and safe write paths rather than technology.
Does ERP Integration Require Customizing the ERP?
Usually not, and it is worth avoiding where you can. Customizations inside the ERP have to be carried through every upgrade, while logic in an external integration layer can change on its own schedule. Keep the ERP close to its standard configuration and put company-specific workflows in the layer around it.
How Do You Test an ERP Integration Safely?
Test against a non-production copy of the ERP loaded with realistic data, including the awkward cases such as partial shipments, returns, cancelled orders and items with unusual units of measure. Then run the new flow in parallel with the existing manual process for a period and compare the results before switching over.
What Drives the Cost of an ERP Integration?
Cost follows the number of flows, how much the data models differ, the quality of the ERP’s interfaces and documentation, the state of partner data and how much reporting the business needs on top. Experience matters too, because an engineer who has worked inside a similar ERP will spend less time discovering its rules.
Who Inside the Business Needs to Be Involved?
Involve the people who own each process the integration touches, typically finance, operations or fulfillment, purchasing and whoever owns the customer record. They decide what correct data looks like, which is a decision engineers should not make alone.
Build the Layer Your ERP Was Never Meant to Be
Your ERP can stay the system of record while a well-owned layer around it handles the workflows, partner data and reporting that grew up beside it. If people are still carrying data between your ERP and the systems around it, walk us through the ERP and the workflows that depend on it, including where data is re-keyed today and who signs off on the numbers.
