You committed to a partner integration. It was going to open a channel, or it was a condition of the contract. The date has moved twice. Your side gives answers that do not quite resolve into a picture, and the partner has moved from friendly check-ins to asking pointed questions in writing.
This is a bad position, and it is recoverable more often than it feels.
What is usually actually wrong
In our experience it is one of four things, and they have very different costs. Knowing which one you have is most of the battle, because right now you probably have no way to distinguish “two more weeks” from “not possible as scoped.”
Your system cannot speak the language, and nobody said so out loud. The partner expects to exchange data in a particular modern format, over a particular kind of connection, with a particular way of proving who is calling. Older systems often cannot do parts of this — not because the work is enormous, but because it was never built. What happens next is that someone tries to bolt it on incrementally, hits a wall, backs up, tries another way. From the outside this looks like slow progress. It is actually repeated restarts.
The data does not line up. Their system expects a customer to have one address. Yours allows five. They expect every order to have a delivery date; a third of yours do not. These mismatches are discovered one at a time, deep into the work, and each one requires a business decision, not a technical one — which nobody wants to make, so it sits.
The security review is the real blocker. Increasingly the integration is technically done and stuck in the partner’s vendor review. They want to know what versions you run, how you patch, who has access, what happens if you are breached. If your system is on unsupported software, this is where it surfaces, and no amount of integration work moves it forward.
One person knows and is overloaded. The work is understood by exactly one developer who is also running everything else. Progress happens in the hours nobody else claims. This is extremely common and it is not a performance problem.
The first move: get an honest status
Before anything else, you need a status you can actually rely on, in writing, that separates three things:
- What is genuinely finished and demonstrated working
- What is built but untested against the partner’s real system
- What has not been started, including anything nobody has looked at yet
That third category is where the surprises live. In a stuck integration it is normally larger than anyone believes, because the parts nobody has examined are assumed to be simple.
If you cannot get that list from your own side, that is itself the answer to what is wrong.
The thin layer
Here is the thing most owners in this position are not told: your system usually does not have to change.
The standard fix is a small, separate piece of software that sits between your system and the partner. It speaks the modern language the partner expects on one side, and talks to your existing system in whatever way it already works on the other. It handles the security requirements, the data format, the retries.
This matters for three reasons. It is much less work than modernizing your whole system. It carries almost no risk to your live operation, because your system is not being modified. And it can usually be built and demonstrated in weeks rather than months, which gives you something real to show the partner while the longer conversation happens.
It is not free and it is not always the right answer — if the mismatch is in your data rather than your protocol, a translation layer does not solve it. But it is the option that gets overlooked, and it is often the difference between a rescued deal and a lost one.
What to tell the partner
Tell them early, be specific, and give a reason.
Partners are far more tolerant of a moved date with a cause attached than of repeated confident reassurance followed by silence. What damages the relationship is not the delay. It is the growing sense that you do not know your own status — because if you cannot tell them where the integration is, they start wondering what else you cannot tell them.
If their security review is the blocker, a written document describing what you run, its current state, and your schedule for fixing the gaps is worth more than a promise. Most vendor reviews are looking for evidence that you know your own systems and are managing them, not for perfection.
Where to start today
You can get one piece of the picture yourself. Ask your host which versions the account runs and when support for them ends. If the partner’s security review is stalling, an out-of-support version is very likely what it found, and you want to see it before they explain it to you.
The full version is five business days of reading the system, the integration work done so far, and the partner’s actual requirements, ending in a written document: what is done, what is not, what is genuinely blocking, what each remaining piece costs and how long it takes. Including, if it is the case, that the promise as made cannot be met by the date — which is worth knowing while you can still renegotiate.
That audit is $2,400 fixed, and the fee comes off the work if you go ahead. You own the document either way and can hand it to anyone, including the partner. Full pricing is here.
What we do not do
We do not build new products. Building the connection itself is our work — that is most of what this page is about — but a new product around it is not, and we will not take the job if the honest answer is that it should not be done. If your system genuinely needs replacing rather than repairing, you will get that in writing — which is cheaper to learn now than halfway through.