ERP and CRM integration: what to define before you start

Why integration is not just a technical question#

ERP and CRM integration connects two systems that play different roles in a company. The ERP system runs orders, stock, accounting and production; the CRM system runs contacts, opportunities and the sales process. When the two are disconnected, sales cannot see stock levels or a customer's payment status, and accounting cannot see the deal context behind an order. Integration closes that gap, but only if it is clear from the start which system is the source of truth for each piece of data and how often data is exchanged.

Before development starts, the scope of the connection has to be agreed with the client: which entities are synchronized, how often, and in which direction. Without that decision, projects tend to change course mid-build, as the development team hits cases the scope did not cover - duplicate records, conflicting data about the same customer, or stock levels that reach sales late. Defining scope up front reduces rework during development and lowers the risk that the integration behaves differently in production than expected.

For the client, this means treating integration as a project, not a technical setting between two systems. Decisions on data ownership, sync frequency and error handling belong to the business users of both systems, not only IT. Epix and its specialist partner network can run project management and coordinate these decisions, but the client needs to provide access to people who know how both systems are actually used day to day, since without their input the scope cannot be reliably defined.

Mapping existing systems and data#

The first step is mapping the existing systems: which ERP and CRM version is in use, which modules are active, and whether either system exposes an API or only allows file-based import. This determines whether integration can run in real time or only in batches, for example hourly or daily. If one of the systems has no usable API, that has to surface before development starts, not during it, since it changes the architecture of the whole solution.

Beyond the technical inventory, the state of the data itself needs review. Duplicate records, incomplete fields and mismatched product or customer codes are not fixed by integration - integration simply moves them from one system to the other, often faster and at greater volume than manual work would. Before starting, we review which entities are in scope, which system is their source of truth, the current data quality, and which identifier links the same record across both systems.

The mapping also shows whether this is a new build or a takeover of an existing, partially built integration. In the latter case, we review the source code, architecture and documentation before continuing, since without that it is not possible to reliably assess what already works and what needs fixing or rebuilding. The mapping result is the basis for estimating scope and for further decisions on which data is synchronized and in which direction.

• which entities (customers, products, orders, invoices, opportunities) are in scope
• which system is the source of truth for each entity
• current data quality and where duplicate records exist
• which identifier links the same record across both systems
• which existing APIs and access points are already available

Which data to sync, and in which direction#

Once mapping is complete, we define which data actually moves between the systems. Not every field needs to sync - it is often better to move only the fields the receiving system genuinely uses. Too much data in an integration means more room for conflict and longer build time; too little means users still check the other system manually, which cuts into the actual benefit for sales and accounting.

Sync direction depends on where the data actually originates. A customer typically originates in the CRM during the sales process and moves to the ERP once an order is placed. Stock and payment status, on the other hand, originate in the ERP and move to the CRM so sales can see them without switching systems. One-way sync is simpler and more predictable; two-way sync needs clear rules for cases where the same record changes on both sides at once, a common source of errors.

When defining sync direction and scope, several questions are decided together with the client, since each choice affects the integration's architecture and how much automation can safely be built in. We resolve these before development starts, because changing sync direction later often means reworking parts of the integration already built. Among other things, we define:

These decisions directly shape the integration's architecture and how much automation it can safely carry. Clear rules on sync direction and conflict handling mean less manual reconciliation after go-live and fewer cases where data in one system no longer matches the other, which would otherwise raise extra questions for sales and accounting.

• which entities sync one-way and which sync two-way
• what happens when a record changes in both systems at once
• whether deleting a record in one system propagates to the other
• how transfer errors are handled (retry, notification, manual confirmation)
• where the log of what was transferred, and when, is kept

Who owns the data, and what happens on conflict#

Data ownership means which system is treated as authoritative for a given field. If, for example, a customer's address is CRM-owned, then a change to that field in the ERP must not silently overwrite the CRM value - the sync should instead flag it. Without this rule, the same field can end up looping between the two systems, with users on each side seeing different values and no way to tell which one is correct.

Conflicts arise when a user changes the same record in both systems before a sync runs. The resolution rule has to be set in advance: last change wins, the owning system's value wins, or the conflict is surfaced to a user for manual approval. This is a business decision, not a technical one, and it needs sign-off from the people who use both systems day to day, not only the development team building the integration.

For the client, this means naming a responsible person or group, before development starts, who can make these calls during the project. If such decisions cannot be made quickly, integration work stalls exactly at the points where it would otherwise move forward, extending the whole project. That is why, early in the project, we agree with the client who owns these decisions and record that agreement before any integration logic is built.

Security, access and audit trail#

Integrating ERP and CRM means API access from one system reaches into the other, so before development starts we define who has access to integration credentials, how they are stored, and who can change sync rules. This matters even more in a regulated industry or the public sector, where access-review and data-security requirements are stricter and every change to integration logic needs to be traceable.

An audit trail means that for every transferred record you can see when it moved, from which system, and what triggered the change. Without it, tracing the cause of a mismatch between the two systems is hard, and proving compliance during a review or audit is harder still - a common requirement in the public sector and regulated industries. Before integration work starts, we agree with the client on access, environment separation and log retention.

These decisions are not one-off - they need to hold after go-live too, as the integration is maintained and extended over time. We include them in the documentation handed over to the client, along with access and credentials, while the integration's source code and data remain the client's property. That arrangement lets the client take over support at any point, or move it to another provider, without depending on a single team.

• who has access to integration credentials and API keys
• how development, test and production environments are separated
• that the test environment does not use the client's real personal data
• how long transfer logs are retained and who can access them
• who is responsible for response if a security incident occurs during data transfer

Testing the integration before go-live#

Testing an integration between two systems is not the same as testing a single application, because a fault on one side can corrupt data on the other. Before go-live we prepare test scenarios covering typical data transfers, edge cases, and deliberately triggered failures such as an unreachable API, an incomplete record, or a duplicate identifier that would otherwise go unnoticed in production.

Testing runs in a separate test environment that does not use the client's real personal data. That means test data has to be prepared in advance, realistic enough to mirror the structure of production data without containing actual customer or business information. Environment separation holds throughout development, not just during pre-launch testing.

The test suite for an ERP-CRM integration depends on the scope of the connection, but typically spans several layers, from manually checking individual records to automated repetition of full sync runs. The goal is to catch faults before they touch real production data, and to confirm the integration correctly handles the rare edge cases that carry outsized impact when missed. The test suite typically includes:

Where needed, we bring in independent QA, separate from the development team that built the integration. This matters most for integrations touching financial data or compliance-relevant records, where a post-launch fault affects multiple departments, not a single user. In those cases, independent testing before go-live lowers the risk of a fault surfacing only after it has already affected the business.

• manual checks of individual record transfers between systems
• automated testing of repeated sync runs
• API testing of error responses and time-outs
• regression testing after every change to integration logic
• acceptance testing against agreed criteria before go-live

What the rollout plan needs to cover#

Rolling an integration into production is a separate step from development and testing. The rollout plan sets out when the sync first goes live, how existing discrepancies between the two systems are handled before that first run, and who monitors the integration in the days that follow, when unexpected cases are most likely. We plan this step separately from development, even though the same project team carries it out.

The first run often requires a one-off reconciliation of existing data before ongoing sync is switched on. This step needs its own plan, since it moves a large volume of records in one pass, worth checking manually before the system switches to automatic operation - an error at this stage affects every sync that follows.

For the client, the rollout plan brings clarity on what happens on go-live day, who is reachable if something fails, and how the team responds if the integration needs to be paused. We agree these details with the client before the go-live date, not during it, to avoid improvising once the system is already in use.

Support and maintenance after go-live#

After go-live, the integration remains a system that needs monitoring. A minor change on either connected system - a new version, a field change - can break the sync, so it is worth agreeing in advance who monitors the integration and who fixes faults when they occur, and how each type of fault is handled.

Support work is organized by impact on the business: an integration outage, where the system or a key part stops working, gets top priority; a disruption to a single function is handled by priority as agreed in the support contract; minor faults with no business impact go into the next release. Requests for changes or upgrades to the integration are scoped separately and scheduled with the client.

The client retains ownership of the integration's source code and data; documentation, access and credentials are handed over at project close. That means the client can take over post-launch support directly, hand it entirely to Epix and its specialist partner network, or choose a mix where some tasks stay in-house and others are handled externally.

How Epix approaches this kind of project#

For ERP-CRM integration, we can take on the full project - from mapping existing systems through go-live and support - or a single work package, such as building the integration layer, while the client manages the rest. On larger projects we assign a project lead, define team responsibilities, timelines, and how communication and reporting run throughout.

Within Epix and its specialist partner network, we build and connect ERP, CRM, DMS and ECM systems through APIs. We assemble project teams to match each project's requirements, from solution architects who define the integration architecture to QA engineers who prepare and run test scenarios before go-live. We take the same approach when an integration needs continued development after launch, or has to adapt to changes in one of the connected systems.

We can also take over an existing or unfinished integration, after reviewing its source code, architecture, infrastructure and data state. Pricing is not fixed in advance - it is set after reviewing requirements and scope, which is why we typically propose a short analysis first, breaking the scope into packages that can each be estimated and delivered separately. That lets the client decide step by step, without committing to the full project up front.