Systems Integration

Almost always, yes. Where there is no API we work with what the system does expose — a reporting database, a scheduled file export, a vendor data feed. It costs more than a clean API and it is less tolerant of vendor upgrades, so we tell you that up front rather than after the quote.

Sometimes. If three of your systems are genuinely at end of life and the vendor is gone, replacement can be the honest answer. But a single-platform program is a multi-year commitment and it removes tools your team is good at. We will say so when replacement is right — most of the time the cheaper answer is to connect what you have and replace one system at a time. The average enterprise runs 897 applications, but only 29% are integrated, according to the [MuleSoft Connectivity Benchmark](https://www.salesforce.com/blog/mulesoft-connectivity-benchmark-2025/) (2025).

The first connection is usually live in three to six weeks after the workshop. We deliberately start with one pair of systems rather than the whole map, so there is something running and measurable before the budget is committed to the rest.

It breaks, and the question is whether you find out from a monitor or from a customer. Every connection we build logs its failures, alerts a named person and makes it easy to see what did not make it across. Under an Apex partnership, watching for deprecation notices and updating ahead of them is part of the work.

Not in the connection — in the disagreement. Two systems hold a slightly different version of the same customer, and nobody has decided which is authoritative. Until that is settled, syncing them faster only spreads the inconsistency more quickly.

A small standing allowance, and it is the line most often left out of a quote. APIs change, vendors deprecate versions, and a connection nobody maintains fails quietly about a year in. The choice is a modest ongoing budget or a manual check every month, which is where you started.

Often worth it. A connection built against a clean interface is a fraction of the cost of the replacement and buys you the time to decide whether the replacement is genuinely needed. What to avoid is deep custom work inside a system with a known end date — connect it, do not extend it.

You do. Integration code, configuration and documentation are handed over as standard, and nothing we build locks you to us. If you take it in-house, it should be readable by whoever picks it up.

Not entirely, and waiting until it is perfect means never starting. But integration does surface the mess, because two systems disagreeing becomes visible the moment they are connected. The workshop tells you how much cleaning has to happen before the first connection and how much can wait.

Related, not the same: systems integration keeps systems in step day to day, while data integration builds one consistent copy for reporting and AI (see the data warehouse section above).

You need consistent data, not necessarily a warehouse: a model given conflicting records gives confident, conflicting answers.

In your own cloud account, in the Australian region unless you ask otherwise, with access set per role and logged. You own the infrastructure and pipelines the same way you own the code.

It starts with a $9,000 + GST [Rapid Insight Workshop](/services/consulting/rapid-insight-workshop), which prices the connections worth building before you commit. The build price then depends on how many systems you connect and how much their data disagrees: defined work is quoted fixed price as an [Amplify](/services/amplify) build (typically from $100K), and connections that keep growing run as an [Apex](/services/apex) partnership (from $15K a month). See the cost section above for timeframes.