Why integration deserves its own scrutiny
A tool can score well on features and still disappoint because it will not exchange data cleanly with the systems around it. Staff then copy information between screens, reconcile mismatches by hand, and slowly stop trusting the numbers. Integration problems are also expensive to fix after purchase, because they often involve the vendor, another supplier and your own technical staff all at once.
Interoperability is the ability of different systems to exchange data and use it meaningfully. The word “meaningfully” matters. Moving a file from one system to another is easy; making sure that both systems agree on what a customer, a product code or a date means is harder.
Start by mapping what needs to connect
Before asking vendors anything, list the systems the new tool must work with and what should flow between them. For each connection, note:
- what data moves (for example, customer records or approved invoices)
- the direction (one way or both)
- how often (continuously, hourly, daily)
- which system is the authoritative source for that data
- who owns the connection once it exists
A simple diagram on one page is enough. It often shows that the real need is smaller than assumed, or that a forgotten system, such as a spreadsheet someone depends on, sits in the middle of a process. Naming a source of truth for each data item matters because without one, edits made in two places produce conflicts. The wider idea is discussed under centralized data management.
Questions about how the tool connects
Ask the vendor to explain the options in plain terms:
- Does the product offer a documented, supported way to read and write data from outside, and is it included in your plan or charged separately?
- Are there ready-made connectors for the specific products you use, and who maintains them? Ask for the versions supported, not just the product name.
- Which file and data formats can it import and export?
- Are there limits on how much data or how many requests it can handle, and what happens when limits are reached?
- Is data exchange real time, scheduled or manual?
- How are changes to connections communicated, and what notice is given when something in the interface will change?
Treat “we integrate with everything” as a prompt for further questions, not as an answer. A connector that exists on a vendor’s list may handle only a narrow slice of the data you need.
Questions about data meaning
Technical connection is only half of the work. Check whether the two systems can represent the same information the same way.
- Do they use the same identifiers for customers, products or employees, or will you need a matching rule?
- Are formats such as dates, currencies and addresses compatible?
- What happens to fields in one system that have no home in the other?
- Who resolves duplicates and conflicting values?
These issues are the heart of master data management, and they tend to surface late if no one looks for them early. Poor underlying data will also pass straight through an integration, so the common data quality issues you already have will not disappear because a connection exists.
Identity and security considerations
Many integrations require one system to act on another’s behalf, which raises access questions. Ask how the tool handles sign-in and whether it works with the arrangement you already use, for instance single sign-on. Ask what permissions an integration needs and whether they can be limited to the minimum required. Integration accounts are a common source of overly broad access, so they should be reviewed like any other. Questions about data location, encryption and logging belong with your security and compliance colleagues; this article offers general guidance only, and qualified professionals should assess specific risks.
Test, do not just ask
Written answers are a starting point. The reliable method is to test a realistic connection during a trial, which is one purpose of a well-designed software pilot.
A useful test includes:
- a sample of real, messy data, not just clean examples
- a round trip, where data goes out and comes back
- a deliberate failure, such as a connection dropped midway, to see whether errors are visible and recoverable
- a check that totals and counts match between systems after transfer
If the vendor cannot support a test with your own data, record that as a risk.
Think about cost and ownership over time
Integrations are not built once and forgotten. When either system is updated, connections can break, so someone must monitor and maintain them. Ask who will do this, and include the effort and any connector fees when estimating total cost of ownership. Reliance on one tightly connected product also increases switching costs, which is a theme within vendor lock-in.
Keep it proportionate
Not every tool needs deep integration. For a standalone tool used by one team, a manual import may be perfectly reasonable. The more people and processes depend on the data, the more the connections matter. A short, written integration assessment, repeated for each shortlisted product and kept with the decision record, is usually sufficient to keep this part of the evaluation honest.