What Drives the Cost of a Systems Integration in Israel

I am not publishing a price list here, and not out of evasion. Integration rates vary by the systems, the specific installation, and who does the work - any range I wrote would be wrong for most readers, and somebody would build a quote on it. What does transfer between projects is what moves the number, and that is what lets you ask the right questions and recognise an estimate resting on a guess.

The rule that precedes everything else

You cannot price an integration without seeing the installation.

That sounds like a supplier's hedge, and it is a fact: the same two systems at two clients can require entirely different code. In Priority, in SAP Business One and in a CRM - each accumulates customised fields and forms over years.

What that means practically: a quote given after a phone call alone is an estimate, not a price. The gap between an estimate from documentation and one after seeing the schema is a multiple, not a percentage.

What is possible: pricing a short discovery day, at the end of which there is a real number. A supplier offering that is working properly; one giving a number immediately is taking a risk you will pay for later.

The five factors that move the number

1. How many flows, and in which direction

"Connect the systems" is not one project. It decomposes into one-way flows, each with its own cost.

A flow that reads data is cheap. A flow that writes is dearer. Two-way sync of the same field is the most expensive - and usually the wrong solution.

What to ask: "how many separate flows are there, and in which direction?" If the answer is "everything should update both ways", that is not a requirement - it is a request that needs decomposing.

2. Identity matching - the line nobody budgets

This is usually the largest piece of work, and it is invisible in the project description.

One system identifies a customer by email. The other by a numbered card. Deciding when two records are the same customer is business logic, and sometimes it has no clean answer.

What affects the price:

• Is there a shared key? A company registration number on both sides reduces it dramatically.
• Is the existing data clean? Duplicates in the base mean cleanup work before the integration - not instead of it.
• What happens without a confident match? A human review queue costs more to build and less to fix.

The question worth asking first: "is there a shared field that identifies a customer with certainty in both systems?" A negative answer doubles the estimate.

3. Whether it creates a real-world commitment

This is the difference that most surprises clients.

The reason: a tax document is not deleted, and a courier ordered twice arrives twice. Such operations require idempotency, a daily reconciliation job and an error queue a human sees - and that is a third to half the work, not an extra.

A supplier pricing an invoicing flow the same as a read flow either does not understand this or will not build it.

4. Urgency

"Real-time" costs more. Scheduled polling is simple and cheap; event push needs a public endpoint, authentication, a queue and duplicate handling.

And in most cases only one flow is genuinely urgent. Recognising that reduces cost without harming the outcome - and it is a question worth asking: "what genuinely must be immediate, and what can wait an hour?"

5. Who maintains it, and what happens when it breaks

The line most often omitted - and an integration is not a delivered object.

It depends on systems that change: a version that changes a limit, a token that expires, a user who leaves. These are not bugs - they are reality.

What should be defined in advance: who handles it when it breaks, within what time, and who pays.

What makes a request priceable

These are the questions I ask, and each one moves the number:

1. Which systems, and at which version and installation?
2. Is there access to a test environment? If not, that raises cost and slows delivery.
3. How many flows, and in which direction?
4. Is there a shared key identifying a customer?
5. How clean is the existing data?
6. Is there an operation here that creates a commitment?
7. What must be immediate?
8. Who maintains it after delivery?

A request without answers to these is not priceable - and saying so is a legitimate answer from a supplier.

What raises cost without anyone intending it

• No test environment. Developing against production means more careful work and repairing real mistakes.
• Nobody to answer. If questions to the system vendor take a week, the timeline follows from that.
• A module that must be purchased. Discovered mid-project, and then it is a purchasing decision that halts everything.
• "Real-time" that is not genuinely needed.
• A requirement discovered late because nobody described the process fully.

And what lowers it

• A shared key in both systems.
• Dropping two-way sync in favour of one handover point.
• Accepting polling instead of real-time where possible.
• Starting with one flow that produces value, then extending.
• Cleaning data first rather than asking code to compensate.

The question worth asking before any of it

How many hours a month does this manual work take?

That is the number turning the conversation from "what does it cost" into "is it worth it". Two hours a month almost never justifies an integration with maintenance. Twenty hours does.

And sometimes the honest answer is that it is not worth it - which is an answer a good supplier should be willing to give.