The Hidden Costs of Failing Post-Go-Live Support

Nobody budgets for post-go-live support the way they budget for the implementation. The implementation gets a business case, a steering committee and a number the board has seen. Support gets a line added late in the negotiation — often a percentage of the licence cost — and a shared mailbox. That gap does not stay theoretical. It opens within months of go-live, inside departments that never signed off on the project budget, which is why it takes so long to notice.

Why post-go-live support is systematically under-budgeted

There are two structural reasons, and neither is anyone’s fault. The first is that implementation money and running money come out of different pockets. An implementation is a one-off with an end date, so it gets scrutiny and a sponsor. Support is recurring, with no end date, so it competes with every other operating cost every year, indefinitely. A large one-off figure is easier to approve than a modest permanent one, even when the permanent one is smaller over any horizon you measure.

The second is that the support number is agreed at the moment of least information — during contract negotiation, months before go-live, when nobody knows which processes will break, which key user will resign, or which overnight integration will start failing silently. Most contracts then add a hypercare window of elevated attention after go-live. That window is useful, and it almost always closes before the system has been properly tested. The first weeks prove people can log in and raise an order. The expensive discoveries arrive later.

• The first month-end close, when a reporting gap that testing never surfaced becomes an accounting problem with a deadline attached.
• The first VAT return prepared from the new system, where a mis-mapped tax code stops being a configuration detail and becomes a filing somebody has to sign — in Intervat, or its equivalent across the border.
• The first real peak: the seasonal spike, the large tender, the quarter the year depends on, run at volumes no test script ever produced.
• The first year-end and the first audit, when someone asks for a reconciliation nobody has had to produce before and the answer turns out to live in a spreadsheet on one laptop.
• The first departure among your key users, who leave with the undocumented reasoning behind half your configuration.

The costs that never reach the support line

Here is where the money goes instead. Only one of the seven arrives as an invoice with support written on it, which is why the rest survive so long.

Senior people doing work they were never hired for

When support capacity is short, the gap gets filled by whoever understands the system best — and that is rarely a support engineer. It is your financial controller, your operations manager, the one key user who paid attention during testing. They do not raise tickets. They fix it themselves, because fixing it is faster than explaining it to someone who will take three days to reply.

Do the arithmetic on your own numbers rather than on borrowed ones. Suppose a finance lead spends two days a week on manual reconciliation and data corrections that the new system was bought to eliminate. That is 40% of one senior salary redirected into unplanned system maintenance. Put your own all-in employment cost into that percentage and you have the annual figure — for a role costing €75,000 a year all-in, an illustrative input rather than a market rate, it is roughly €30,000. It lands in the payroll line, where nobody is looking for it, and the support budget goes on looking healthy.

Workarounds that harden into shadow processes

Every unresolved issue produces a workaround, and the workaround is usually a spreadsheet. That is fine for a fortnight; the problem is that nothing removes it afterwards. Six months later it has an owner, a naming convention and a place in the month-end checklist. It has become a process, and it charges you three times over: the manual effort every cycle, the errors it introduces, and the fact that the system you paid for is now bypassed for that step, so the reporting built on top of it is quietly wrong.

Data quality decay

Data quality is not a state, it is a rate. The day after go-live your master data is as clean as it will ever be, because somebody was paid to clean it for the migration. From then on it degrades: duplicate customers created because the search did not find the existing record, articles set up with the wrong tax code, addresses maintained in one system and not the other.

None of that raises an incident. It produces a slow drift between what the system says and what is true, and the bill arrives months later as a stock count that will not reconcile, an intercompany balance nobody can explain, or a management report the board has stopped believing. Recovering is a project. Preventing it is a few hours a month.

A month-end close that never recovers

The close is the clearest instrument you have, because it is measured already. If it took five working days before the implementation and takes eight afterwards, that is three days a month of finance capacity plus three days of delay on every number the business steers by. Twelve months of that is thirty-six working days you did not plan to spend. Year-end follows the same logic: whatever the monthly close leaves unresolved becomes an audit question, and audit questions are billable time on both sides.

Ad-hoc day rates and licence drift

This is the cost you can actually point at, which is usually what finally triggers the conversation. Work outside the support scope gets billed ad hoc, and ad hoc work is priced for the inconvenience: a premium for urgency, a minimum billing unit that rounds a two-hour fix up to half a day, travel where attendance on site is required, and no volume commitment to negotiate against.

Run the comparison yourself. Add up the ad-hoc days you bought over the last twelve months, multiply by the rate on those invoices, and put the total beside the annual cost of reserved capacity from the same supplier. Where support has been running short, the ad-hoc column usually wins — a premium paid for not having planned. For reference, our own embedded consultants are priced at €1,500 to €2,500 a month depending on seniority; hold your supplier’s day rate against that shape of number.

Licences drift the same quiet way: users provisioned generously for training and never reviewed, modules bought for a phase two that never started, a sandbox nobody has opened since acceptance. That one is worth an afternoon.

Attrition, and the retraining behind it

People leave systems, not only jobs. If the six months after go-live consist of firefighting, working late through every close and apologising to customers for things they cannot fix, your best operational people update their CVs. They are the ones with options, which is the whole problem.

That cost is easy to underestimate because it looks like an ordinary resignation. It is not. You lose the undocumented knowledge of why the system is configured the way it is, then pay for recruitment, notice-period overlap and a ramp-up measured in months. In the Belgian and Dutch market for people who genuinely understand ERP operations, you are competing for that replacement against every organisation currently mid-implementation.

The roadmap that never gets built

Every implementation ships with a phase two: the scanning that would remove a manual step, the customer portal, the reporting that was going to replace the weekly spreadsheet, the integration that would end double entry. Phase two is where most of the business case lived.

When support is under-resourced, phase two never starts, because the people who would deliver it are the same group keeping the lights on. The improvements are not rejected — they are postponed at each quarterly review until they stop being raised. You end up having bought a platform and using it as a ledger. That is the largest cost here and the hardest to quantify, which is why it survives longest.

A support budget that is too small does not produce a support problem. It produces a finance problem, a data problem and a retention problem — and none of them arrive labelled as support.

What a properly budgeted support arrangement looks like

The fix is not a bigger number. It is a number that exists as a decision rather than as a residue, and that is sized against the work the system actually generates. In practice that means six things.

• A named person rather than a shared mailbox — someone who knows your configuration and your close calendar, and who you can reach without first finding out who is on duty.
• Reserved capacity priced monthly: a fixed number of days that are yours whether you spend them on incidents or improvements, so the quiet months fund the difficult ones instead of expiring.
• Response commitments that match your calendar rather than a generic service level. Four-hour response is worth little on the third day of the close; agreed availability during close week, VAT deadlines, stock counts and year-end is worth a great deal.
• A visible backlog with a standing improvement allocation. Anything purely reactive spends everything on incidents, so ring-fence part of the capacity for phase two or accept that it will not happen.
• A quarterly review of data quality and licences: duplicates, dormant users, unused modules, and any spreadsheet that has appeared in a process since last time.
• An explicit exit route for workarounds. Every temporary fix gets an owner and a review date, otherwise it becomes permanent by default.

Sized that way, support appears in one place where it can be managed, rather than distributed across payroll, the close, the audit fee and the recruitment budget. And if you already recognise the pattern — senior people reconciling by hand, a close that never recovered, a spreadsheet that has become load-bearing — then you are paying for post-go-live support today. The only question is whether you are paying for it deliberately.