Key Takeaways
- Many organizations research ERP options informally for a year or more while the specialized system running a critical part of the business is evaluated only after a vendor has been chosen.
- ERP system integration should shape the selection criteria from the beginning, because the cost of connecting a specialized platform is largely decided before implementation starts.
- Vendor claims of integration cover a wide range of realities, from certified connectors the vendor supports to custom interfaces the customer must build and maintain.
- Writing ERP system requirements around the integration gives the team a testable basis for comparison and keeps the work inside the contract rather than a later change order.
Most ERP evaluations begin with the systems everyone can name. Finance wants better reporting, operations wants inventory visibility, and the project team builds a shortlist, sits through demonstrations with two vendors, and forms an opinion over the course of a year or more. Meanwhile, the system that runs a critical part of the business sits outside that conversation.
It may be a clinical platform, a field service application, or a laboratory information system. It is not being replaced, it will have to exchange data with whatever ERP is selected, and nobody has asked how.
Today, we are discussing why ERP system integration belongs in the selection criteria from the first week of the evaluation rather than the first week of implementation.
The 2026 Top 10 ERP Systems Report
What vendors are you considering for your ERP implementation? This list is a helpful starting point.
What Vendors Mean When They Say the System Is Integrated
An integration is the mechanism that moves data between the ERP and another system on a defined schedule or trigger, and ERP system integration is not a binary property. When a vendor confirms that its ERP integrates with a specialized platform, the statement can describe several very different arrangements, and the difference between them is measured in months of effort and, frequently, six figures.
At the strongest end, the vendor maintains a certified connector with published field mappings and commits to keeping it current through upgrades. In the middle sits a documented API that the customer or a partner uses to build and maintain a custom interface. At the weakest end is a file-based exchange, a scheduled export and import that moves data but eliminates the real-time visibility the ERP was purchased to deliver.
The distinction that matters most to a CFO is ownership. A certified connector is a vendor obligation. A custom interface is a line item in the implementation budget and a maintenance commitment the organization carries for the life of the system. Our discussion of ERP integration challenges covers the design decisions that make these interfaces fragile in the first place.
Why the Integration Question Gets Deferred
ERP evaluation follows the path of least resistance. The systems being replaced are easy to discuss, because everyone in the room has an opinion about them. The system that is staying is harder, because it belongs to a department that is not losing anything and has little reason to participate.
Four patterns push the integration question to the back of the queue:
- No seat at the table: The specialized system belongs to a department that is not represented on the ERP steering committee, so its requirements never reach the evaluation team.
- Untested vendor answers: Vendors answer integration questions affirmatively during demonstrations, and those answers are never checked against the actual data structures and transaction volumes involved.
- An informal timeline: The evaluation runs casually for a year or more, and by the time it becomes structured, the shortlist has already narrowed to two vendors.
- Misfiled as an implementation topic: Integration is treated as something to sort out after selection, which moves it into a phase where the vendor is chosen and the organization has lost its leverage.
For example, a specialty manufacturer running a product lifecycle management system that engineering will not give up can reach the contract stage before anyone confirms whether the ERP can consume its bill of materials structure without a nightly batch workaround.
That distinction matters. Before the contract is signed, the integration is a selection criterion. After it is signed, the integration is a change order.
Case Study
Nevada Irrigation District, a California water utility serving roughly 19,000 treated water customers, set out to replace aging legacy systems spanning finance through customer service. The district also ran Sedaru, a maintenance management system tracking work across hundreds of miles of canal and pipeline, and that system needed to keep sharing data with whatever ERP was selected.
Panorama documented more than 250 business requirements before any vendor conversation began, and the Sedaru interface was treated as part of that requirement set rather than as an implementation detail to resolve later. Nine solutions were evaluated against those requirements and narrowed to three finalists through customized demonstrations. Because the integration was scoped during evaluation, the district carried a documented expectation for data sharing into implementation.
Read the full irrigation district ERP selection and integration case study.
Building ERP System Requirements Around the Integration
Requirements documents describe what the new system must do. When a critical platform is staying, they must also describe what the new system must exchange, at what frequency, and under whose support. ERP system requirements written as capability statements cannot be tested, because a statement that the ERP must integrate with the maintenance management system has no threshold attached to it.
A workable integration requirement names the data objects moving in each direction, the latency the business needs, the system of record for each contested field, and the party responsible for maintaining the interface through upgrades. Requirements at that level of detail bring the department that owns the specialized system into the process while its objections can still influence the shortlist, and they tend to eliminate one or two candidates on their own.
Three questions surface most integration problems during ERP evaluation:
- Published limits: Ask for the documented record counts, call frequencies, and supported file types for every connector under consideration, in writing from the vendor rather than from a reseller summary.
- Behavior at the limit: Establish what the interface does when a threshold is exceeded, because an integration that queues gracefully presents a very different risk from one that drops records without raising an alert.
- Remediation cost: Confirm what it takes to raise a limit, since some caps are configuration changes while others require a higher licensing tier.
Vendors answer these questions accurately when the questions are asked precisely. The value an independent ERP consultant adds at this stage is a set of reference points from prior projects that indicates whether a published limit is genuinely adequate for the volumes at hand.
Expert Insight
Our ERP selection consultants have found that integration questions asked during demonstrations rarely produce useful answers, because the questions are too general. Asking whether a vendor integrates with a named platform invites a yes, while asking who built the integration, who supports it through upgrades, and how many customers run it today produces an answer that can be verified. Our ERP implementation services begin with a review of exactly those commitments.
How to Choose an ERP Around a System You Are Keeping
The work of choosing an ERP system under this constraint is not harder than a standard selection, but it is sequenced differently. The integration analysis moves to the front.
1. Confirm What Is Actually Staying
Before shortlist work begins, decide formally which specialized systems will remain and why. Some are kept for regulatory reasons, some because no ERP module matches the workflow, and some out of habit. Challenge the third category early, because eliminating an interface costs less than building one.
2. Document the Interface Before the Shortlist
Map the transactions that must cross the boundary in both directions, with the volumes and timing the business depends on. This becomes a scored section of the evaluation rather than a technical appendix, and every vendor answers the same question against the same standard.
3. Test Integration Claims During Demonstrations
Ask each vendor to demonstrate the exchange using representative data, and ask for two reference customers running it in production. Vendors who cannot produce references are describing a capability rather than a deployed connector, and that difference belongs in the scoring.
4. Put the Integration in the Contract
Interface scope, ownership, and upgrade support belong in the statement of work before signature, along with who pays when a future release breaks the connection. An ERP implementation consultant brought in afterward inherits whatever was left ambiguous, and the organization absorbs the cost.
Learn More About ERP System Integration
A specialized system that will outlive the ERP selection is not a detail to be handled later. It is a constraint that should shape the shortlist, the demonstration agenda, the scoring model, and the contract. Organizations that treat it that way finish selection with fewer finalists and far fewer surprises after go-live.
Panorama’s ERP consultants help organizations define testable integration requirements and validate them through ERP software selection and implementation, drawing on the outcome data published in our annual ERP Report. Contact us below to learn more.
FAQs About ERP System Integration
How early should ERP system integration be evaluated?
Before the shortlist is set. Integration requirements narrow the field in ways functional requirements do not, and the leverage to negotiate interface scope and support exists only while multiple vendors remain in play. Evaluating integration after selection converts a criterion into a change order, which is where the cost lands.
What should we ask vendors about ERP system integration during demonstrations?
Ask how many current customers run this specific integration in production, who built it, who maintains it through upgrades, and what happens when a release breaks it. General questions about whether the systems connect invite a yes. Questions about deployed connections and named references produce answers you can score.
Does choosing an ERP system with a suite approach still work if we are keeping a specialized platform?
Often, yes. Suites remain viable when the specialized platform exchanges a manageable set of transactions through a supported connector. The decision turns on interface volume, latency requirements, and support ownership rather than architecture preference. Comparing both models against your actual data flows is more useful than a general position.
Who should own the interface after go-live?
Ownership should be named in the contract, not assumed. Certified connectors are typically a vendor responsibility. Custom interfaces usually fall to the customer or the systems integrator, which creates an ongoing cost that belongs in the business case. Ambiguity surfaces at the first upgrade, when nobody has budgeted the rework.
Why involve an independent advisor when a system is staying in place?
Because that system determines whether the ERP delivers its expected value. An independent advisor structures the requirements, scores vendor claims against evidence, and negotiates interface commitments before signature. Taking no vendor referral fees means the recommendation reflects your integration constraints rather than a partner relationship.
