ERP System Integration: A Practical Planning Guide

ERP system integration connects enterprise resource planning softwarewith the other applications, databases and services a business dependson. Done well, it allows information to move through a complete businessprocess without repeated data entry or gaps between departments.

But connecting two systems technically is not the same as creating areliable business process.

An ecommerce order might need to update customers, stock, purchasing,fulfilment, invoicing and reporting. If any part fails, somebody mustknow what happened and how to recover. The difficult questions are oftennot about APIs. They concern data ownership, timing, validation,exceptions and responsibility.

The right starting point is therefore not, “Do these products have aconnector?” It is:

What business process must work, which information does it requireand what should happen when something goes wrong?

This guide explains how to answer those questions—including whenimportant legacy systems run locally and have no modern API.

What is ERP systemintegration?

ERP system integration is the process of connecting an ERP with otherinternal or external systems so that they can exchange and useinformation. IBM describes ERP integration as connecting ERP systemswith enterprise applications, software and databases to improve datasharing and analysis. IBM: What Is ERPIntegration?

Common examples include:

• Ecommerce platforms sending orders to the ERP and receiving stockavailability.
• CRM systems sharing customers, quotations and sales activity.
• Electronic data interchange (EDI) platforms exchanging orders,dispatch notices and invoices with trading partners.
• Accounts-payable automation passing approved invoices intofinance.
• Warehouse systems exchanging stock movements and fulfilmentstatus.
• Manufacturing execution systems (MES) sending production activityback to the ERP.
• Product lifecycle management (PLM) systems providing productdefinitions and bills of materials.
• Payroll, banking, shipping, reporting and specialist operationalsystems.

These connections may use APIs, events, message queues, files,database access or older vendor-specific interfaces. They may operateimmediately or according to a schedule.

The technology matters, but it should follow the businessrequirement.

Start with thecomplete business process

Integration projects often begin too low down. A team lists systems,finds available endpoints and starts mapping fields. This can produce atechnically correct connection that fails to support the work peopleactually perform.

Begin by following one real transaction from start to finish.

Consider an online order:

1. The customer places an order.
2. Stock availability is checked and reserved.
3. Payment or account terms are validated.
4. The warehouse receives fulfilment instructions.
5. Purchasing responds to shortages where necessary.
6. Dispatch information returns to the ecommerce platform.
7. The ERP creates the appropriate financial entries.
8. A cancellation, return or correction may need to reverse part of theprocess.

This reveals more than a list of data fields. It shows wheredecisions occur, which system should act first, what users need to seeand what happens when a later step cannot complete.

For each process, ask:

• What triggers it?
• Which system creates the original information?
• Which departments and systems use it?
• Which decisions and approvals occur?
• How quickly must information move?
• What confirms that processing is complete?
• What happens when data is missing, duplicated or rejected?
• Who owns the process from end to end?

An ERP integration consultant should understand this operationaljourney before recommending tools or connectors.

Build a system and data map

Once the process is understood, document how information shouldmove.

InformationOwning systemReceiving systemDirectionFrequency/LatencyExample integration patternValidationFailure ownerCustomer accountCRM or ERPOther business systemsOne-way or two-wayImmediate or scheduledREST API / WebhookRequired fields and duplicate checksSales operationsProduct definitionERP, PIM or PLMEcommerce and warehouseUsually outwardOn approvalBatch CSV / EventStatus, units and identifiersProduct ownerSales orderEcommerce or CRMERPInwardNear real timeWebhook / QueueCustomer, price, tax and stockOrder managementDispatch statusWarehouse or ERPEcommerce and CRMOutwardEvent-basedMessage QueueOrder and shipment identifiersFulfilmentApproved supplier invoiceAP automationERP financeInwardImmediate or batchREST API / FileSupplier, purchase order and totalsFinance

The table should reflect your business rather than a generictemplate. Its most important column is often Owningsystem.

Decide whichsystem owns each type of information

“Create one source of truth” sounds attractive, but it can becomemisleading. A business may legitimately have different authoritativesystems for different information.

The CRM may own sales prospects. The ERP may own invoicing and creditstatus. The PLM system may own engineering definitions. The warehousesystem may be the most current source for physical stock movements.

Problems arise when ownership is unclear. If users change an addressin three applications, which wins? If a cancelled order reappears duringsynchronisation, which system failed?

For every important entity, define:

• Where it is created.
• Which system is authoritative for each field.
• Who may change it.
• How other systems receive updates.
• How corrections and deletions are handled.
• How conflicting changes are resolved.

Do not create two-way synchronisation simply because it appears moreflexible. It adds conflict, sequencing and recovery problems. Use itonly where the business genuinely needs changes to originate in bothsystems.

Choose the right ERPintegration approach

There is no single best integration architecture. The appropriatemethod depends on system capability, volume, timing, business risk andinternal expertise.

Direct point-to-pointintegration

One system connects directly to another, commonly through an API.

This can be efficient for a small number of straightforwardconnections. However, as the number of systems grows, mappings,credentials, monitoring and error handling become scattered and harderto manage.

Middleware or anintegration platform

Middleware sits between systems and handles routing, transformation,orchestration and monitoring. An integration platform as a service mayprovide managed connectors and operational tools.

This can reduce duplication when several applications need the sameinformation. It also creates another important component that must begoverned, secured and supported.

Event and message-basedintegration

A system publishes an event such as “order accepted” or sends amessage to a queue. Receiving systems process it independently.

This can improve resilience and reduce tight coupling, but introducesquestions about message order, duplicate delivery and delayedprocessing. Microsoft recommends idempotent consumers so that processingthe same message more than once has the same effect as processing itonce. Without that protection, retries can create duplicate records orfinancial transactions. Microsoft:Idempotent Consumer pattern

Scheduled batch integration

Data is exchanged at defined intervals—perhaps every few minutes,hourly or overnight.

Batch processing is entirely appropriate when immediate informationis unnecessary. It may be simpler and more reliable for large datavolumes, finance postings, reporting extracts or systems with limitedinterfaces.

Managed file exchange

Systems export and import structured files such as CSV, XML, JSON,fixed-width records or EDI documents. Files may be placed in acontrolled folder or transferred securely.

File integration is sometimes dismissed as outdated. In practice, itcan be dependable when formats, naming, validation, acknowledgements,archiving and error handling are properly defined.

Controlled manual exchange

Not every connection deserves automation. If a low-risk transactionoccurs twice a year, a validated manual import may be more economicaland transparent than a fragile automated interface.

The objective is not maximum automation. It is the most reliable andmaintainable process for the business.

What if the legacy systemhas no API?

Many businesses still depend on local software that was designedbefore modern web APIs became standard. Some systems run only on aninternal server, use an older database or provide little integrationdocumentation.

That does not make integration impossible. It changes the availableoptions and usually demands more caution.

Use a supported databaseinterface

The legacy application may store data in SQL Server, Oracle, Accessor another database accessible through technologies such as ODBC orJDBC.

Read-only views or a vendor-approved reporting interface may provideuseful data without changing the application. For inbound transactions,use documented stored procedures or supported import tables whereavailable.

Avoid writing directly into undocumented production tables. Bypassingthe application's business rules can create incomplete records, brokenrelationships or data that appears valid until a later process fails. Itcan also invalidate vendor support.

Exchange files

Older systems frequently support scheduled export and import evenwhen they lack an API. A controlled process can:

1. Export new or changed records.
2. Place the file in a secure location.
3. Validate and transform it in a staging area.
4. Import it into the receiving system.
5. Record which rows succeeded or failed.
6. Archive the original file and result.

This is not real-time integration, but it may meet the businessrequirement perfectly well.

Use the vendor'solder integration technology

A legacy product may provide a software development kit, COMcomponent, DLL, command-line utility, SOAP service, message interface orproprietary connector. These can be viable if they remain supported andthe organisation can maintain the necessary expertise.

Document the dependency. An integration that relies on one oldruntime or one employee's knowledge represents a future operationalrisk.

Introduce a staging database

A staging database separates extraction and transformation from thelive application. Data can be copied out of the legacy system, cleanedand mapped before being passed onward.

The integration should record source identifiers, extraction times,transformation rules and processing status. A staging layer isparticularly useful when the source system cannot provide clean changetracking or when reconciliation is important.

Install a localgateway or integration agent

A small service inside the customer's network can communicate withthe legacy database, file system or vendor interface locally. It thenexchanges approved information with cloud services through a secureoutbound connection.

Microsoft uses this general pattern for its on-premises data gateway,which acts as a bridge between data held on an internal network andsupported cloud services. Microsoft:On-premises data gateway

The idea is useful beyond one vendor: keep the legacy system awayfrom direct internet exposure while placing a controlled, monitoredbridge at the network boundary. Any such service still requirespatching, credentials, logs, availability monitoring and a clear supportowner.

Useuser-interface automation only as a last resort

Robotic process automation can enter information through anapplication's screens or extract data from reports. It may be the onlyshort-term option where no supported technical interface exists.

However, screen layouts, timing changes and unexpected messages canbreak the automation. UI automation should be monitored closely andtreated as a transitional or carefully justified solution rather than aninvisible permanent interface.

Accept a controlled manualstep

Sometimes the safest answer is a user-reviewed export and import.This can be preferable to automated updates that occasionally corruptdata without anyone noticing.

The key principle is simple:

Do not force real-time integration onto a legacy system that cannotsupport it reliably.

Protect the legacyenvironment

Connecting an older system can increase its exposure. Beforeintegration, understand its architecture, network boundaries,authentication, patch status and operational importance. The UK NationalCyber Security Centre recommends understanding the architecture ofexisting systems and identifying important trust boundaries,particularly where systems connect to the internet, third parties orcloud services. NCSC:Asset management

Practical safeguards may include:

• Giving the integration service only the permissions it requires,following the principle of least privilege.
• Using read-only access wherever possible.
• Separating staging and integration components from the productiondatabase.
• Avoiding direct inbound internet access to the legacy server.
• Protecting traffic through appropriate encrypted connections.
• Rotating and securely storing service credentials.
• Logging access, transformations and failures.
• Monitoring the performance effect on the old system.
• Keeping an inventory of integration dependencies.

Where an older application cannot support modern secure protocolsdirectly, a managed network layer may provide protection while broadermodernisation proceeds. NCSC:Building zero trust across a mixed estate

Integration is not a substitute for a legacy-system replacement plan.It may extend the useful life of the system, but the business shouldunderstand when the connection becomes more costly or risky thanmodernisation.

Decidebetween real-time and scheduled integration

“Real-time” often appears in requirements without a businessjustification. It adds complexity and can make systems more dependent oneach other's availability.

Ask how quickly the information is genuinely needed:

• A customer may need stock availability within seconds.
• A warehouse may need a released order within minutes.
• Management reporting may refresh hourly.
• Finance totals may post overnight.
• Historic product data may migrate once.

Use the slowest frequency that still supports the business process.This can reduce load, cost and operational risk.

Also define what real-time means. Is five seconds acceptable? Thirtyseconds? Five minutes? A measurable expectation is more useful than alabel.

Design for failure beforegoing live

Every integration will eventually encounter an unavailable system,invalid record, network interruption or unexpected data value. Failurehandling is therefore part of the design, not a later support task.

For each connection, decide:

• Will the transaction wait, retry or fail immediately?
• How many retries are appropriate?
• Can retrying create a duplicate?
• Where are unprocessed transactions held?
• Who receives an alert?
• Can authorised users correct and replay a failed transaction?
• How are partial updates reversed or completed?
• How does the business operate while the connection isunavailable?

Retries are valuable for temporary failures, but they need limits anddelays. Microsoft's Retry pattern recommends designing for anticipatedtransient faults rather than retrying every error indiscriminately. Microsoft:Retry pattern

For persistent failures, a dead-letter or exception queue allows atransaction to be retained for investigation (acting like a digitalholding area) instead of being discarded or retried forever. Microsoftdemonstrates this pattern in its guidance for reliable asynchronous datasynchronisation. Microsoft:Reliable data sync

Long-term Governance& "Day-Two" Operations

Once the integration is deployed, long-term stability relies on aclear operational framework. Ensure your organisation establishes clearanswers to the following governance points:

• Technical Failure Owner: Who diagnoses droppedconnections, API timeouts or server downtime?
• Data Quality Owner: Who fixes a transaction stuckin the exception queue due to a missing postcode or invalid taxcode?
• Change Management Owner: Who coordinates testingwhen a downstream application updates its API version?
• Audit & Compliance Owner: Who regularly reviewsreconciliation sheets to confirm that every outbound dispatch matches aninvoice?

Reconcile, do not merelytransmit

A successful technical response does not always mean the businesstransaction is correct.

Reconciliation compares what each system believes happened. Examplesinclude:

• Ecommerce orders versus ERP orders created.
• Warehouse dispatches versus invoices raised.
• Supplier invoices approved versus finance postings accepted.
• Stock balances versus confirmed stock movements.
• Messages sent versus acknowledgements received.

Agree control totals, exception reports and ownership. Reconciliationis particularly important for finance, stock and external tradingtransactions.

Test the complete process

Integration testing should include more than a few successfulexamples.

Test:

• Normal transactions.
• Missing mandatory data.
• Invalid codes and identifiers.
• Duplicate messages and files.
• Out-of-order updates.
• Corrections, cancellations and returns.
• Large volumes and peak periods.
• One system becoming unavailable.
• Time-outs and delayed responses.
• Retry and replay behaviour.
• Permissions and unauthorised requests.
• Reconciliation and audit evidence.
• Recovery after planned and unplanned outages.

Use realistic end-to-end business scenarios and involve the peoplewho will manage exceptions after launch. A connection is not readymerely because developers can demonstrate data moving between testsystems.

How to choose ERPintegration services

An ERP integration service provider needs more than experience with aparticular connector.

Ask candidates:

Do they begin withbusiness processes?

The provider should understand the operational outcome beforeproposing architecture. Be cautious if the first recommendation isalways the integration platform they resell.

Can they workwith both modern and legacy systems?

Ask how they have handled databases, files, local gateways andvendor-specific interfaces—not only REST APIs.

How will they define dataownership?

They should be able to explain systems of record, identifiers,field-level ownership, synchronisation direction and conflicthandling.

How will failures beoperated?

Request details of monitoring, alerts, retries, exception queues,reconciliation and support responsibilities. “The connector will handleit” is not sufficient.

Who owns the integrationassets?

Clarify ownership of source code, mappings, configuration,documentation and credentials. Understand what happens if you changeconsultant or integration platform.

How will changes be managed?

APIs, databases, file formats and business processes change. Theproposal should include version control, testing environments,deployment and regression testing.

What documentation will bedelivered?

At minimum, expect system diagrams, process descriptions, datamappings, security arrangements, schedules, monitoring instructions,recovery procedures and support contacts.

ERP integration projectchecklist

Before approving an integration for production, confirm that youhave:

• Defined the end-to-end business process.
• Appointed a business process owner.
• Identified every participating system.
• Assigned ownership for important entities and fields.
• Defined direction, frequency and expected volumes.
• Selected an integration method based on requirements.
• Documented mappings and transformation rules.
• Agreed validation, duplicate and sequencing rules.
• Designed retries, exception handling and replay.
• Defined reconciliation controls.
• Reviewed security and personal-data implications.
• Tested normal, exceptional and recovery scenarios.
• Assigned monitoring and support responsibilities.
• Documented how future changes will be introduced.
• Agreed an exit or replacement path for proprietary connectors.

Howadaptable platforms could change ERP integration

Traditional integration projects repeatedly map similar concepts:customers, products, orders, invoices, permissions and workflow states.A metadata-driven platform could describe more of these structures andrelationships consistently, allowing mappings and connectors to bereused rather than rebuilt for every application.

That does not remove integration work. Different systems still usedifferent identifiers, rules and data structures. Legacy software stillneeds practical access methods. Security, reconciliation and operationalownership remain essential.

The opportunity is to move effort away from repeatedly building basicplumbing and towards understanding the business process, handlingexceptions and creating reusable integration capabilities.

Sevenlake's plannedintegration direction

Sevenlake is currently at the vision and architecture stage and ismoving towards a proof of concept. It is not yet a finished platform,and no third-party product integration should be treated as built orproduction-ready.

API-based interoperability and data import and export are confirmedparts of the platform direction. The intended ecosystem would allowdevelopers to extend the platform and create reusable connectors, whileconsultants could help businesses analyse, implement and supportintegrated solutions.

The specific API model, connector framework, supported integrationpatterns and approach to local legacy systems still need to be designed,implemented and tested. A local integration agent may be a valuablefuture requirement, but it is not a current Sevenlake capability.

Frequently asked questions

Does ERP integrationalways require an API?

No. Integrations can use files, supported database interfaces,message queues, vendor SDKs, local gateways, older web services orcontrolled manual imports. The method should suit the businessrequirement and the source system's capabilities.

Should everyERP integration operate in real time?

No. Scheduled or batch exchange may be simpler and more reliablewhere immediate updates are unnecessary. Define the maximum acceptabledelay for the process before selecting the technology.

Is it safeto connect directly to a legacy database?

Read-only, vendor-supported access may be appropriate. Directlyupdating undocumented production tables is high risk because it canbypass application rules, damage relationships and affect vendorsupport.

What isthe difference between an API and middleware?

An API exposes functions or data from a system. Middlewarecoordinates communication between systems and may providetransformation, routing, monitoring, retries and connectormanagement.

Which system shouldbe the source of truth?

There may be different authoritative systems for different entitiesor fields. Define ownership explicitly rather than trying to make everysystem authoritative for everything.

Who supports anintegration after launch?

Support responsibilities should be agreed before implementation.Define who monitors it, who corrects business data, who fixes technicalfailures and how suppliers cooperate when the cause crosses systemboundaries.

How much does ERPsystem integration cost?

Cost depends on the number and condition of systems, processcomplexity, data quality, volumes, security requirements, availableinterfaces and operational support. A simple supported connector is verydifferent from a two-way integration with an undocumented legacyapplication. Requirements analysis is necessary before a credibleestimate can be produced.

Integrate theprocess, not merely the software

Successful ERP system integration begins with the business process.Understand what must happen, establish which system owns each piece ofinformation and select the simplest reliable way to move it.

Do not assume every connection needs an API or real-time processing.Local legacy systems can often participate through controlled databaseaccess, files, vendor tools or a secure gateway. The important questionsremain the same: Is the data correct? Can the process recover? Doessomebody know when it fails? And can the business maintain it whensystems change?

Interested in helping businesses implement and integrate moreadaptable business software? Register your interest inSevenlake's planned partner ecosystem and follow the platform'sdevelopment.