How Do You Keep Epicor Integrations from Becoming Hidden Technical Debt?
Epicor integrations become technical debt when business ownership, failure handling, security, monitoring and upgrade testing are unclear. Treat each interface as a governed business process, not invisible plumbing.
The short answer
Keep Epicor integrations from becoming hidden technical debt by giving every important interface a named business owner, a named technical owner, an authoritative transaction direction, monitored failure behavior and a regression-test plan. The integration register should explain why each connection exists and what business process breaks when it fails.
An interface that nobody can explain is already a support risk even if it is currently running.
How this connects to the pillar
Where Should Epicor Stop—and Where Should Connected Operational Apps Begin? explains the broader connected-operating-model principle. Integration governance is the discipline that keeps those connections understandable after years of change.
Integrations become invisible when they work
A successful interface may run quietly for months.
That reliability can create a false sense that it no longer needs ownership. Staff change, the original developer leaves and documentation becomes stale. Then an Epicor upgrade, security change or external-system update exposes how dependent the business has become on the connection.
The problem is not that integrations exist. The problem is losing the ability to explain and test them.
Build an integration register for management, not only developers
A technical inventory of endpoints is useful but insufficient.
For each important integration, record:
- business purpose;
- initiating event;
- source system;
- target system;
- authoritative data owner;
- transaction direction;
- frequency or trigger;
- business owner;
- technical owner;
- security method;
- failure visibility;
- recovery approach;
- dependencies;
- regression-test owner.
This creates a map that management can use during change planning.
Define the authoritative direction
Bidirectional integration often sounds flexible but can hide ambiguity.
If customer data can be changed in two systems, which version wins? If inventory is adjusted externally and in Epicor, how are conflicts resolved? If an order status is updated by several applications, which event is authoritative?
Some processes genuinely require two-way communication, but each business field or event still needs a clear ownership rule.
Monitor business failure, not only technical failure
An HTTP success response does not prove the business transaction completed correctly.
A service may accept a message that later fails validation. A quantity may be rejected. A record may be created without a required downstream consequence.
Monitoring should therefore distinguish communication health from business-process health.
Useful alerts tell the support team what transaction is affected, whether retry is safe and what operational consequence remains unresolved.
Design retry rules before the first failure
Automatic retry is valuable only when the transaction is idempotent or duplicate-safe.
If the same shipment confirmation, receipt or order creation is submitted twice, the result may be materially wrong. Integration design should define which requests can be retried automatically and which require a controlled check first.
This should be tested, not assumed.
Secure integrations as identities
An integration is effectively a system user.
It should have appropriate access, controlled credentials and a defined scope. Shared administrator credentials make it difficult to understand what an interface can do and to rotate access safely.
Security design should also consider logs. Sensitive data should not be exposed unnecessarily in error messages or diagnostic payloads.
Make upgrade testing proportional to business risk
Not every interface needs the same regression effort.
Rank integrations by the process they support. A connection that posts high-volume inventory movements deserves different treatment from a low-frequency informational extract.
For critical flows, maintain a small set of representative test transactions that can be repeated after Epicor or external-system changes.
Retire integrations deliberately
Integration portfolios often grow because new connections are added more visibly than old ones are removed.
When a process changes, confirm whether the old interface is still used. Disablement should be controlled, but retaining inactive services indefinitely increases security and support complexity.
A retirement record should state what replaced the interface and how the business confirmed it was no longer required.
What management should measure
Useful measures include:
- critical integrations without business owners;
- critical integrations without technical owners;
- recurring failures by process;
- manual recovery time;
- duplicate transaction incidents;
- untested interfaces before upgrade;
- interfaces using obsolete credentials or methods;
- inactive integrations still enabled;
- number of reconciliations required because source ownership is unclear.
These measures describe the health of the integration operating model rather than the volume of API calls.
ACC context
ACC’s Epicor work spans ERP implementation and connected operational solutions. That makes integration design an operating-model question as much as a technical one: extensions should improve execution while preserving coherent Epicor data and supportability. Explore ACC’s Epicor capabilities.
Operational review point
Pick the five integrations management would notice fastest if they stopped tonight.
For each one, ask whether the team knows who owns it, how failure appears, whether retry is safe and how it will be tested after the next Epicor change.
If those answers depend on one individual’s memory, document and test the process now.
Version the business contract of an integration
Technical interfaces change, but the more important change is often the business contract.
A field may gain a new meaning. A status may be retired. A quantity may switch from optional to required. The endpoint can remain available while the business assumption behind it changes.
For critical integrations, document the expected business payload and validation rules alongside the technical connection. This gives upgrade teams something meaningful to test.
It also helps identify when a successful technical call is producing a business result that no longer matches the intended process.
Test recovery, not only normal processing
Many integration tests prove that a valid message can travel from one system to another.
Support teams also need evidence for what happens when the process is interrupted. Test a duplicate submission, an invalid master-data reference, a temporary outage and a partial downstream failure where practical.
The objective is to confirm that the interface fails visibly and can be recovered without inventing manual database fixes.
A recoverable failure is far less dangerous than an invisible success.
Connect integration change to process ownership
Developers are often asked to change an interface because another project needs a new field or timing rule.
Before changing it, identify which business owner depends on the existing behavior. A small technical modification may alter when inventory appears, how an order is valued or which status triggers customer communication.
Making business sign-off part of material integration changes protects the operating model from accidental drift.
Reduce point-to-point sprawl
Point-to-point integrations are not automatically wrong. A small environment may support them perfectly well.
The risk appears when the number of direct connections grows faster than the organization’s ability to understand dependencies. A change in one system may then require investigation across many interfaces with no clear map of impact.
Architecture reviews should look for repeated transformation, duplicated credentials and the same business logic implemented in several connections. Those patterns suggest that shared services or a more deliberate integration layer may reduce long-term complexity.
Keep diagnostic logging useful and proportionate
When an integration fails, support teams need enough information to identify the affected transaction and reason.
Too little logging creates guesswork. Too much logging can expose sensitive data, create noise and make important failures difficult to find.
Design diagnostic records around recoverability: transaction identity, time, integration step, validation result and actionable error context. Logs should help restore the business process, not merely prove that software executed.
Review interfaces when business ownership changes
Integration risk can increase even when no code changes. If a process owner leaves, a business unit reorganizes or an external application changes responsibility, confirm who now owns the interface behavior and its exceptions. Ownership review should be part of organizational change so critical connections do not become orphaned while still appearing technically healthy.
Keep ownership visible in support tickets
When an integration incident is raised, route it with both the technical service and the business process named. This stops support queues from treating every interface failure as an isolated software problem and helps the correct process owner assess operational consequence quickly.
Frequently asked questions
Should every Epicor integration use the same technical pattern?
Not necessarily. The right pattern depends on transaction timing, volume and control, but ownership and failure principles should remain consistent.
Is monitoring an IT responsibility only?
Technical teams may run the monitoring platform, but the business owner must understand the operational consequence of failure.
Are bidirectional integrations bad?
No. They simply need explicit ownership rules for the data and events moving in each direction.
How often should the integration register be reviewed?
Review it when major systems change and periodically enough to catch ownership, security and retirement issues before an upgrade exposes them.