On this page
- Start with the system landscape
- “API available” is not a design
- Who owns the business truth
- Not everything needs real time
- Synchronous and asynchronous
- Design failure first
- Give every integration an owner
- Monitoring is part of it
- Follow one transaction
- Integration changes are lifecycle
- Ownership is not portability
- Report export vs data export
- Structure, not only format
- Test portability early
- What stays available
- End of the relationship
- Backup is not portability
- Support is an operating model
- Who owns each problem
- Incident, support, enhancement
- Severity by business impact
- Response vs resolution
- The support hours you need
- Information support needs
- The surrounding environment
- Keep implementation knowledge
- Manage changes after go-live
- Re-test what a change breaks
- The complete operating model
- Red flags
- Integration responsibility record
- Data-portability record
- How exactllyERP fits
- Checklist
- Go deeper
It may need to exchange information with:
- banks;
- CRM;
- HRMS;
- ecommerce;
- warehouse systems;
- production equipment or specialist applications;
- logistics providers;
- reporting platforms;
- government or compliance services;
- customer or supplier applications.
And after the ERP goes live, somebody has to keep those connections working, maintain the business data, investigate failures and manage future changes.
That means three questions belong in the ERP decision before the contract is signed:
How will the ERP connect to the rest of our business?
Can we practically retrieve the data we depend on?
Who owns what after go-live?
A buyer who answers only the first question has not yet designed the operating environment.
Start with the system landscape, not the API list
Do not begin integration planning by asking:
“Does the ERP have APIs?”
Begin by drawing the systems the business actually needs.
For every important connection identify:
| Question | What the buyer needs to understand |
|---|---|
| System | What is connecting to the ERP? |
| Business purpose | Why does the connection exist? |
| Information | What data or event crosses the boundary? |
| Direction | Into ERP, out of ERP or both? |
| Trigger | What causes the exchange? |
| Frequency | Immediate, scheduled, periodic or on demand? |
| Volume | What level of transaction/data volume is expected? |
| System of record | Which system is authoritative? |
| Failure consequence | What happens operationally if the exchange stops? |
| Owner | Who owns the interface after go-live? |
That list becomes the integration catalogue.
Without it, “integration” remains a collection of technical conversations rather than an operating design.
“API available” is not an integration design
An API tells you that a system provides a mechanism for exchanging information.
It does not answer:
- which endpoint or business object will be used;
- which system initiates the transaction;
- whether the interaction is synchronous or asynchronous;
- how authentication works;
- which fields map to which;
- what happens when one system is unavailable;
- whether a request can safely be retried;
- how duplicates are prevented;
- how errors are logged;
- who monitors failures;
- how the interface changes when either system changes.
Those are architecture and operating questions.
So do not stop at:
“Do you have an API?”
Ask:
“Show us the complete operating path for this integration.”
Decide which system owns the business truth
Two connected systems may both contain a customer.
That does not mean both should independently decide what the customer record means.
For every important shared object, decide which system is authoritative.
Examples might include:
Customer
CRM may originate the relationship.
ERP may own financial terms and credit control.
Or the architecture may be different.
Employee
HRMS may be authoritative for employee identity and organisational structure.
ERP may consume only the information required for approvals or costing.
Item
ERP may own the commercial and inventory item.
A specialist engineering system may own technical design information.
Payment status
ERP may initiate or record the financial obligation.
The banking interface may return confirmation.
The specific answer depends on the architecture.
The important thing is that somebody has decided.
Otherwise two systems can both be technically correct while the business does not know which one to trust.
Not every integration needs to be real time
“Real time” sounds better in a proposal.
It is not automatically better architecture.
Ask what the business actually needs.
A credit-control decision during order entry may need current information.
A nightly analytical export may not.
A large data synchronization may be safer as a controlled scheduled process.
A user-triggered enquiry may be better served on demand.
The design should reflect:
- business urgency;
- transaction volume;
- dependency;
- failure consequence;
- performance;
- operating hours;
- connected-system capability.
Do not pay complexity merely to make every arrow on an architecture diagram say “real time.”
Understand synchronous and asynchronous consequences
Synchronous
In a synchronous exchange, the user or process may wait while another system responds.
That can be useful when the answer is required immediately.
It also means the connected system’s availability can become part of the user’s transaction.
Asynchronous
In an asynchronous design, the transaction can often be queued and processed independently.
That can improve resilience.
It also creates another requirement:
How does the business know what has processed, what is waiting and what has failed?
There is no universally correct pattern.
The buyer should understand why the selected pattern fits the business process.
Design failure before celebrating success
A successful interface demonstration tells you what happens on a good day.
Production support is often about the other day.
Ask what happens when:
the bank does not respond;
the same message is sent twice;
authentication fails;
a connected system is offline;
a payload contains invalid information;
a platform limit is reached;
part of a multi-step transaction succeeds and another part fails.
For each important interface define:
How does anybody know?
What is blocked, queued or allowed to continue?
Can the transaction retry or be reprocessed?
Can recovery accidentally process something twice?
How do both systems eventually agree?
Who needs to know?
Give every integration an operational owner
A common post-go-live conversation sounds like this:
“The API is working.”
“Our system is working.”
“The users say the transaction is missing.”
All three statements can be true.
The business still has a problem.
Every important interface should therefore have a clear operating responsibility.
At minimum know:
Who receives the first alert?
Who performs first diagnosis?
Who can inspect both sides of the interface?
Who can reprocess a failed transaction?
Who contacts the ERP vendor?
Who contacts the third-party vendor?
Who decides that the issue has become a business-critical incident?
Do not design ownership after the first production failure.
Monitoring is part of the integration
An integration should not require a user to discover failure by noticing that a transaction never arrived.
For significant interfaces ask what can be monitored.
Depending on the architecture, useful evidence may include:
- transaction status;
- timestamps;
- message/reference ID;
- source and destination;
- processing status;
- error detail;
- retry status;
- reconciliation status.
The exact implementation differs.
The principle does not:
If the integration matters operationally, somebody should be able to see whether it is healthy.
Follow one transaction across the boundary
When evaluating an important integration, do not ask for a slide showing arrows between systems.
Give the vendor one transaction.
For example:
- customer order
- ERP
- external warehouse
- dispatch confirmation
- ERP
- invoicing.
Or:
- ERP payment instruction
- banking interface
- bank response
- payment status
- reconciliation.
Then ask:
Where can we see the transaction at every stage?
What identifier links the records?
What happens if one stage fails?
How do we know both systems eventually agree?
That gives the architecture something concrete to prove.
Treat integration changes as lifecycle events
An integration that works on go-live day is not necessarily finished forever.
Over time:
- fields change;
- business rules change;
- authentication changes;
- connected applications are upgraded;
- transaction volumes grow;
- APIs change;
- another company or location joins;
- a new workflow needs the same interface.
So ask before purchase:
Who owns future interface changes?
How are changes tested?
Which vendor must be involved?
How are interface versions documented?
What happens when an upgrade affects a custom or third-party integration?
This is where integration architecture becomes part of lifecycle cost rather than only implementation cost.
Data ownership is not the same as data portability
A contract may say:
“The data belongs to the customer.”
That is important.
But it does not answer the practical question:
“Can the customer retrieve the business record in a useful form?”
Ownership and portability are related but different.
A buyer should understand:
Can we see/use the data while operating the ERP?
Can we extract data outside the application?
Can we obtain enough structure and meaning to use or migrate that data elsewhere?
Can historical records remain accessible after operational migration?
What happens if we eventually stop using the product or hosting arrangement?
A report export is not necessarily an ERP data export
Being able to export a report to Excel or PDF is useful.
It does not necessarily mean you can reconstruct the business record.
For portability, ask what can be retrieved for categories such as:
Master data
Customers, suppliers, items, chart of accounts and other core masters.
Open transactions
Orders, receivables, payables and other active transactions.
Historical transactions
Completed commercial and financial history.
Inventory and balances
Quantities, values and relevant dimensions.
Configuration
Relevant masters, parameters or workflow definitions where the platform makes them available.
Supporting records
Attachments or linked documents where these form part of the business record.
Audit/history information
Where required and supported.
Do not assume all vendors expose every category in the same way.
That is exactly why the buyer should ask.
Ask about structure, not only format
CSV is a format.
It is not automatically a migration strategy.
Suppose a vendor gives you ten thousand rows.
You still need to know:
- what each field means;
- which records relate to each other;
- which codes are internal;
- how dates/units/statuses are represented;
- whether important attributes are missing;
- how attachments are referenced;
- whether deleted/inactive records matter;
- how company/location context is represented.
So ask:
What will help another competent team understand this export?
Depending on the solution, that may include:
- field definitions;
- entity definitions;
- mappings;
- identifiers;
- relationship information;
- export documentation.
The exact deliverable differs by product.
The objective is understandable data.
Test portability before you need to leave
The worst time to discover that an export is difficult is during an ERP replacement.
During vendor evaluation, ask for a representative export.
For example:
If an important category cannot be exported directly, ask what the alternative process would be.
You do not need to perform a full migration during procurement.
You need enough evidence to understand the practical exit path.
Decide what needs to remain available after an ERP change
Replacing an ERP does not automatically mean every old transaction must be loaded into the new system.
Some information may move.
Some may remain in an accessible archive.
The decision depends on:
- operational use;
- reporting needs;
- audit requirements;
- statutory retention;
- customer/vendor history;
- migration cost;
- data volume.
Guide 5 covers the migration decision.
Guide 7 asks the related exit question:
If we do not migrate something, how will authorised users still access it when they need it?
Understand what happens at the end of the relationship
Before signing, ask calmly:
If we eventually move away from this ERP, what is the process?
Clarify:
- how data is requested;
- what data can be provided;
- what format/method is available;
- whether assistance is required;
- what commercial services may apply;
- how long access remains available;
- how historical information can be retained;
- what happens to integrations;
- how final support/transition is handled.
This is not an accusation that the vendor relationship will fail.
It is normal lifecycle planning.
A supplier confident in its customer relationship should not need lock-in created by ambiguity.
Backup is not portability
A database backup may be essential for recovery.
It does not automatically give the business a usable migration file.
Likewise, a CSV export may be portable but may not be a disaster-recovery backup.
Ask the two questions separately:
Recovery
How do we recover the current environment after failure?
Portability
How do we retrieve data for independent use or transition?
Guide 3 owns infrastructure and recovery responsibility.
Guide 7 owns practical access and portability.
Do not confuse the two.
Post-go-live support is an operating model
Support should not mean:
“Here is the vendor’s support email.”
That is a channel.
A support model explains how the organisation handles a problem from the moment somebody notices it to the point the business is operating normally again.
Decide who owns each class of problem
After go-live, not every ticket belongs to the ERP software vendor.
Consider a user reporting:
“The invoice is not reaching the customer portal.”
The cause could be:
- user process;
- configuration;
- ERP defect;
- integration;
- authentication;
- infrastructure;
- third-party system;
- bad master data.
The business needs a triage model.
A useful responsibility sheet can look like this:
| Issue area | Questions to settle before go-live |
|---|---|
| User/how-to | Who provides first-line assistance? |
| Business process | Who decides whether behaviour is correct? |
| Master/configuration | Who can change it and who approves the change? |
| ERP product defect | Who raises and owns vendor escalation? |
| Integration | Who can inspect the complete interface? |
| Infrastructure | Who owns the relevant server/cloud/network layer? |
| Third-party application | Who coordinates the external vendor? |
| Data correction | Who has authority to correct operational data? |
| Enhancement | How does a request move from support into change governance? |
The exact owners vary.
The ambiguity should not.
Separate incident, support question and enhancement
Three requests can sound similar:
“The screen is not working.”
“How do I complete this transaction?”
“Can the screen work differently?”
They are not necessarily the same work.
A support model should distinguish:
Something required for agreed operation is not functioning correctly.
The system may be working, but the user needs help.
The business wants behaviour altered or expanded.
If everything becomes a “ticket”, the support queue eventually mixes production problems with future product ideas.
That makes priority harder to manage.
Define severity by business impact
A large number of tickets does not necessarily mean a crisis.
One blocked critical process may matter more.
Ask how severity will consider questions such as:
Is a critical business process stopped?
How many users/locations are affected?
Is there a workaround?
Is financial or statutory processing affected?
Is data integrity at risk?
Is an integration blocking downstream operations?
Do not assume another vendor’s definitions.
Agree what the terms mean in your own support arrangement.
Response time and resolution time are different
Response
A support agreement may promise an initial response.
Resolution
That does not automatically tell you when the underlying problem will be resolved.
Ask separately:
When will the issue be acknowledged?
When will qualified diagnosis begin?
How is progress communicated?
What happens if another supplier is involved?
How does escalation work?
What commercial or contractual commitments apply?
Do not convert those questions into invented universal support numbers.
Make the vendor explain its actual model.
Know the support hours that your operation needs
A business operating one office schedule has different needs from a business running:
- multiple plants;
- warehouses;
- night shifts;
- weekend dispatch;
- different countries or time zones;
- month-end or year-end processing.
Ask:
When do we actually need somebody capable of acting?
Then compare that requirement with the proposed support coverage.
Give support enough information to diagnose the issue
A useful support request should help reproduce or locate the problem.
Depending on the issue, that may include:
- affected business process;
- product/module;
- user/location;
- transaction/reference number;
- what the user was trying to do;
- expected result;
- actual result;
- error message;
- screenshot;
- when it occurred;
- business impact.
Better information does not guarantee an immediate resolution.
It avoids wasting the first part of diagnosis discovering what the problem actually is.
Support must include the surrounding environment
The ERP may be healthy while the business process is failing.
If a critical process depends on:
- ERP
- middleware
- third-party service
- network
- bank
- ERP,
support cannot operate as though only the ERP application exists.
For every important cross-system process, somebody should be able to answer:
Which component failed?
And, if the answer is not yet known:
Who coordinates the investigation until it is known?
That coordination responsibility is often more valuable than another support email address.
Keep the implementation knowledge alive
Guide 5 established that the implementation team should not disappear on go-live day.
Guide 7 carries that principle into steady-state operation.
Support needs enough knowledge of:
- configuration decisions;
- custom development;
- integrations;
- data mappings;
- security roles;
- accepted workarounds;
- important operating exceptions.
Otherwise support can diagnose the product but not the implemented business system.
Manage changes after go-live
A live ERP does not remain unchanged.
The business may add:
- users;
- locations;
- companies;
- reports;
- workflow steps;
- integrations;
- modules;
- statutory changes;
- custom requirements.
Each change can affect something else.
So define how a requested change moves through:
- request
- business approval
- impact assessment
- configuration/development
- testing
- release
- documentation
- support handover.
Do not allow urgent support activity to become an uncontrolled way of changing production.
Re-test what a change can break
An ERP update or configuration change may affect:
- integration;
- customisation;
- report;
- workflow;
- role;
- downstream system.
The exact testing required depends on the change.
But for critical dependencies ask:
What needs regression testing before this change reaches production?
Especially when multiple suppliers are involved.
Support and change governance are connected.
Make the vendor explain the complete operating model
During evaluation, give the shortlisted vendor your real landscape.
Then ask:
The useful question is:
“What will operating this environment require from both sides after go-live?”
Integration, portability and support red flags
“We have APIs” is the complete integration answer
The interface architecture remains undefined.
Nobody can identify the system of record
Shared data can drift without clear authority.
Every integration is proposed as real time
Architecture may be driven by sales language rather than operating need.
Successful messages are demonstrated but failures are not
Recovery remains unproven.
Nobody owns monitoring
The first evidence of failure may be a user complaint.
The ERP vendor and third-party vendor both stop at their own boundary
The business becomes the accidental integration coordinator during every incident.
“You own your data” is the whole portability answer
Practical extraction remains untested.
A PDF/Excel report is presented as proof of complete portability
A report export and a business-data export are different things.
The buyer has never seen a representative export
Exit capability remains theoretical.
The exit process is unclear
Data access becomes a future negotiation rather than a known lifecycle process.
Backup and portability are treated as the same concept
Recovery and migration answer different questions.
Support begins with a contact address but has no responsibility model
The communication channel exists; the operating model does not.
Response and resolution are spoken about as though they are identical
The buyer does not understand the actual service commitment.
Integrations and customisations have no post-go-live owner
Implementation dependencies become support surprises.
Every request enters one undifferentiated ticket queue
Incidents, user assistance and enhancements compete without meaningful prioritisation.
Changes are made directly in production because they are “small”
Support activity becomes uncontrolled change management.
A practical integration responsibility record
Before implementation, maintain one record for every important interface.
| Item | Record |
|---|---|
| Integration | Systems involved |
| Business purpose | Why it exists |
| System of record | Authoritative source |
| Direction | In / Out / Both |
| Trigger | Event/schedule/user action |
| Expected frequency | Operating requirement |
| Integration method | Agreed architecture |
| Business identifier | How transactions are linked |
| Failure consequence | Operational impact |
| Detection | How failure becomes visible |
| Retry/recovery | How processing resumes |
| Reconciliation | How systems are brought back into agreement |
| ERP owner | Responsible party |
| External-system owner | Responsible party |
| Monitoring owner | Responsible party |
| Change owner | Who coordinates future changes |
| Support path | How an incident is escalated |
Do not create this document merely for the implementation project.
It should remain useful after go-live.
A practical data-portability record
For each important data area ask:
| Data area | What to establish |
|---|---|
| Master data | Export method and structure |
| Open transactions | What can be extracted and with what relationships |
| Historical transactions | Scope and accessibility |
| Financial information | Structure, balances and dimensions |
| Inventory | Quantities, values, locations and identifiers |
| Attachments | Whether/how linked documents can be retrieved |
| Audit/history | Whether required information can be exported |
| Configuration | What can be documented/exported |
| Custom fields | How non-standard data is represented |
| Multi-company data | How entity/company context is retained |
| Documentation | What explains fields and relationships |
| Exit assistance | What vendor services may be required |
The point is not to demand the same technical export from every ERP.
The point is to know what your proposed ERP can actually provide.
How exactllyERP fits into this operating model
exactllyERP should be held to the same questions.
Exactlly supports third-party integration through APIs according to the approved implementation requirement.
Real customer environments also provide evidence that integrations are not merely theoretical. Banking API integrations are confirmed in customer operations including ANA Oils, Re-feel, Ambika Foods and Limagrain Seeds.
Pioneer provides a different proof point: selected specialised Exactlly workflows have continued alongside the organisation’s wider SAP environment since its global SAP transition. That is evidence of coexistence; this guide should not convert it into an unconfirmed claim about the technical method by which the two environments exchange data.
For your own environment, do not ask Exactlly only whether an API exists.
Bring us:
- systems that must connect;
- business events/data exchanged;
- required direction and timing;
- volume expectations;
- failure consequences;
- security constraints;
- system-of-record decisions;
- support responsibilities.
Then ask us to explain the implementation architecture for that scope.
For data portability, do not assume capabilities that have not been demonstrated or agreed.
Ask Exactlly:
What business data can we retrieve?
How would we retrieve it?
What structure/documentation accompanies it?
What would an eventual transition require?
That is a better standard than a vague data-ownership promise.
For support, Exactlly’s current support model includes exactllyDesk for raising and tracking requests, product support, remote assistance where required, email/phone channels, and on-site support for existing customers under AMC where appropriate.
But the buyer should still define the complete responsibility model around:
- internal users;
- infrastructure;
- integrations;
- external applications;
- configuration;
- change requests.
The relevant question is:
Who owns each part of our actual operating environment when something changes or fails?
ERP Integrations, Data Portability & Support Checklist
Integration landscape
Integration architecture
Failure and monitoring
Lifecycle
Data portability
Support model
Post-go-live change
The buyer is evaluating the ERP as an operating environment rather than as an isolated application.