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.

Six interfaces, six different jobs

Before anyone talks about hours, establish what was actually handed over. This is the first and largest distinction:

Two rows in that table mislead if you read them quickly. A file looks like the simplest option, and there really is almost no authentication work in it - but everything an HTTP interface gives you for free becomes yours: how you know the write finished, what happens when two files arrive out of order, and what you do when a day already loaded has to be loaded again. A database view looks very cheap, and it is genuinely fast to start, but a closed system's schema is not a contract: a version upgrade can rename a table or change what a field means without notice, because to the vendor that is internal.

Why does authentication move the estimate more than the payload does?

Because payload work is bounded - a finite number of fields and rules - while authentication work recurs. A mechanism that expires takes down an integration that ran for months, usually silently:

The bottom two rows are the ones that surprise people. They add almost no code and add a third-party dependency to every change, which is what turns a small change into a week.

Does a sandbox exist, and what does its absence add?

A sandbox is a separate tenant with its own data, where a failed call leaves no damage. When there is none, the work does not disappear - it moves:

• Every test that changes data needs a reversal plan written before it runs.
• Test records land in real reports, so they need a marker field and a cleanup pass.
• Reproducing a fault means waiting for a real occurrence instead of creating one.
• Rate-limit behaviour cannot be probed, so the limit is discovered in production.
• Some tests can only run outside business hours.

And a sandbox whose data does not resemble production is half a sandbox. It will not surface the duplicate customer, the record with an empty identifier, or the name with an unsupported character - which are precisely the cases that break a go-live.

Who owns the far side

This is the only driver on the list that is not measured in development hours at all:

• A vendor with a support contract and a ticket queue. An answer will arrive, on their schedule.
• A vendor with a professional-services team or a certified partner. An answer costs money and arrives.
• An internal team. The fastest, if they have capacity.
• Nobody. A developer who left, a discontinued product. Every unknown becomes an experiment.

Two projects with identical scope can finish months apart because of this line alone, which is why it belongs in the estimate explicitly rather than as a footnote.

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.