Your ERP Vendor Is Not Coming to Save You

The ticket has been open for eleven days. First response asked for a screenshot you had already attached. Second response said it was a partner issue. The partner said it was a product issue. The product team asked whether you were on the latest patch, and nobody, at any point, actually owned the outcome. Meanwhile the warehouse cannot post a transfer the way the process was designed, so someone has built a temporary adjustment routine that will almost certainly still be temporary in six months.

This is how ERP dissatisfaction actually feels on the ground - not a strategy workshop, but a stalled ticket and a growing workaround. And when leadership finally says "we need a different system," what they often mean is "we need someone who will answer the phone and fix this." That is not the same decision, and treating it as one is how mid-market businesses walk into expensive change for entirely the wrong reason.

The dependency nobody put on the risk register

Most mid-market ERP estates depend on a surprisingly thin chain of people and firms. The vendor owns the platform, a partner configured it, and a handful of internal users understand the quirks well enough to keep things running. One consultant who did the original go-live still gets informal messages when something breaks - until that consultant changes jobs, the partner account manager rotates on, and the vendor support model pushes everything that smells like configuration straight back to the partner. Suddenly the business discovers it does not actually control the system it depends on every day.

That is not bad luck. It is a predictable failure of tech consultancy ownership: if your operating model assumes the vendor or the original implementer will always be around to interpret your customised world, you have outsourced continuity without ever actually buying it.

Ticket ping-pong is an operating model

Vendor support exists to protect the product boundary. Partner support exists to protect the statement of work. Your business sits in the gap between them, full of customisations, integrations, data oddities, and process exceptions that fit neither script cleanly.

So tickets bounce, severity gets quietly downgraded, and you are asked to reproduce the issue on a clean environment that does not resemble production in any meaningful way. Weeks pass, ops invents a bypass, and leadership concludes the software itself is failing. Sometimes it is. More often the support model is failing, and years of customisation have made every issue look uniquely unresolvable - which are genuinely different problems. One might justify a platform change. The other justifies an independent assessment of what you actually own, what is brittle, and who can fix it without a two-week relay race first.

The single point of knowledge

Ask who can explain your customisations without opening a folder of half-finished documents. If the honest answer is one person - an IT manager, a finance systems lead, an external contractor - you do not really have an ERP. You have a key-person risk wrapped inside a licence agreement, and when that person goes on holiday, changes roles, or leaves entirely, every enhancement freezes and every incident becomes archaeology.

This is the quiet reason so many switch conversations start. Not because a rival vendor demo looked prettier, but because support dissatisfaction and knowledge concentration have made the current estate feel genuinely unsafe. Replacing the platform without fixing ownership simply moves the same single point of failure into a brand new project.

Support pain is not automatically a replace signal

Dissatisfaction with vendor and partner support is real, expensive, and corrosive - and it also gets misread constantly. If the floor's complaint is that nobody can change a workflow, clear a stuck posting, or explain why a report lies, that is not proof you need a bigger suite. It may instead prove you need clearer process ownership, better documentation, a retained capability model, and an ERP renewal stance that separates product fitness from service failure properly.

Independent assessment matters here precisely because the incumbent ecosystem has an interest in either defending the status quo or selling you the next upgrade. You need a view that is not being paid to keep the ticket queue full or the migration proposal warm.

What leadership should demand instead of a demo day

Before you invite three vendors to present their roadmap, demand answers to a few operational questions instead. Who is contractually accountable when a production issue sits between product and configuration? What is the measured response and resolution performance over the last six months, not the SLA printed on a slide? Which customisations are undocumented, and what is the actual plan to reduce or own them properly? If the partner who implemented you is no longer engaged, who holds that knowledge now, and what does retained support genuinely cost?

Those questions force honesty about ops risk, and they also change the shape of the renewal conversation. Sometimes the right move is to renegotiate support, simplify customisations, and bring in independent IT and process strategy so you are not permanently trapped between vendor and partner. Sometimes the estate really is untenable - but you cannot tell which from a brochure.

Stop waiting for rescue

Your ERP vendor is not coming to save you. Their job is to sell and maintain a product used by thousands of customers, and your partner's job is scoped work and billable change. Neither party is structured to carry your operational continuity as a personal mission.

That responsibility sits with you: how much customisation you tolerate, how you retain knowledge, how you measure support, and when dissatisfaction is genuinely a service problem rather than a platform one. If switch talk is being driven by ticket ping-pong and a departed implementer, name that risk clearly, and either fix the dependency or consciously exit it. Do not confuse the absence of a hero with the need for a new logo.