Two systems that do not talk to each other

The situation

You pay for two systems. Both do their job. Neither knows the other exists, so a person bridges the gap by hand: exporting a report from one, reformatting it, importing it into the other, every morning or every Friday.

It works, mostly. It also introduces errors nobody catches until month end, it consumes a few hours a week of someone's time, and it stops entirely when they are on vacation. The vendors have both quoted an integration. One of the quotes is more than the annual cost of the software.

How we approach it

First we find out what is actually possible, which is not always what the vendor says. Some platforms have a proper API. Some have a read-only API that covers half of what you need. Some have nothing but a nightly file drop, and some have a database you can query directly if you ask the right person.

We work out what each side can do, then design the integration around those constraints rather than around the ideal. That usually means a small service that runs on a schedule, pulls from one side, transforms, and writes to the other, with logging so you can see what happened and alerting when it fails.

The part most integrations get wrong is failure. Networks drop, APIs rate limit, records arrive malformed. We build for that from the start, because an integration that silently stops working is worse than the manual process it replaced.

What you end up with

• A working integration that runs on a schedule or on demand
• A log of every sync, so a disagreement between systems can be traced rather than argued about
• Alerting when something fails, instead of finding out at month end
• Documentation of what maps to what, and the source code

Rough timeline

Three to eight weeks, depending heavily on what the platforms allow. We can usually tell you within a week whether the integration you want is possible at all.