ERP support after go-live: a model beyond one key person

Most ERP implementations have a well-defined plan up to go-live and almost nothing defined after it. The implementation partner's contract ends, the project team disbands, and support quietly becomes the responsibility of whichever internal person happened to be most involved during the project — usually because they understood the system best, not because anyone deliberately decided they should own its support going forward.

This works for a while, because that person genuinely does know the system well. It stops working the moment they take an extended leave, change roles, or leave the company, at which point the organisation discovers that a substantial amount of operational knowledge existed only in one person's head, was never documented, and has no succession plan. This is an entirely predictable failure and it is predictable specifically because it is common — most mid-market companies we work with have lived through some version of it, usually more than once.

This article is about building a support model deliberately, before go-live rather than after the gap becomes visible.

Why this matters

The immediate cost of undocumented, single-person-dependent support is operational fragility: a question that should take an hour to answer takes days because the one person who could answer it is unavailable, and everyone else is reconstructing logic from scratch.

The compounding cost is worse. Every enhancement, configuration change and workaround made informally by that person, without documentation, becomes technical debt indistinguishable from the customisation-accumulation problem discussed elsewhere in this series — except here it accumulates in institutional memory rather than in code, which is arguably harder to recover from, because there is no register to audit and no code to read. When that person eventually leaves, the organisation does not just lose a person, it loses an undocumented map of its own system.

There is a governance dimension too. A system whose operation depends on tacit knowledge held by one individual is a control weakness that becomes visible at the worst possible time — during an audit, during that person's absence, or during a subsequent project that needs to understand the current configuration and cannot, because nobody wrote it down.

At a glance: the support model components

Every row in this table exists during a well-run implementation, provided by the partner as part of the project. The failure is not that these things are hard to do — it is that nobody deliberately decides who does them once the partner's contract ends.

What works, and what to be honest about

What works:

Deciding the support model before go-live, not after. This should be a specific deliverable of the implementation project, not an afterthought — who handles what tier of issue, with what internal resource, escalating to what external resource, documented before the partner's contract ends rather than negotiated in a panic afterward.

Documentation as a living artifact, not a one-time handover. Implementation documentation describes the system as built. A support model needs documentation that describes the system as it currently is, updated whenever it changes — the same discipline as the customisation register discussed elsewhere in this series, applied to configuration generally rather than only to customisation.

Named ownership, distinct from deepest expertise. The person who knows the system best is a resource to be protected and supported, not automatically the owner of its ongoing governance. Separating these roles — an accountable owner who ensures documentation, succession and process exist, supported by whoever has the deepest technical knowledge — reduces single-person dependency even before that person leaves.

A retained, lighter-touch relationship with implementation expertise. Not necessarily the original partner, and not at project intensity, but some ongoing access to expertise for genuinely difficult configuration questions, upgrade impact assessment, and periodic health checks. Companies that sever this entirely tend to either under-use the system's capability or accumulate configuration drift nobody catches.

A deliberate cadence for reviewing vendor updates. Someone should be assigned to review release notes, assess impact on your specific configuration and customisations, and test before updates are applied — rather than either applying them blind or deferring them indefinitely out of fear.

What to be honest about:

This costs real, ongoing money, and it competes with other post-go-live priorities. A support model with proper documentation discipline, named ownership and retained expertise access is not free, and mid-market companies frequently under-invest here because the cost is visible and the risk it mitigates is not, until it materialises.

Documentation discipline decays without active maintenance. A support model that starts well-documented and stops being updated after six months is not meaningfully better than no documentation, because stale documentation that contradicts the actual system state is often worse than an honest absence of documentation — it actively misleads.

The single-person dependency often serves that person's interests, even unintentionally. Being the only one who understands the system is a source of job security and influence, and there can be quiet resistance to genuinely transferring that knowledge. This needs to be managed as an incentive problem, not just a documentation problem — recognise and value the knowledge holder explicitly rather than treating knowledge transfer as something imposed on them.

Retained partner relationships need genuine scoping, or they become expensive without being useful. An open-ended retainer with no defined scope tends to be underused until a crisis, then over-relied upon. A periodic health check with defined scope, plus availability for genuinely difficult questions, is usually more useful than either extreme.

Decision framework: building or fixing the support model

Run in order. Stop at the first match.

1. Is your current support model dependent on one specific individual's knowledge, without documentation?
If yes, this is the priority regardless of anything else — begin documenting current configuration and logic now, not as a project but as an ongoing discipline, starting with whatever that person considers most critical or most fragile.

2. Do you have a defined tiered support structure — who handles what level of issue?
If not, define it now. This does not need to be elaborate for a mid-market company, but it needs to exist and be known, rather than defaulting informally to whoever is available.

3. Is there a named individual accountable for the system's ongoing governance, distinct from whoever has the deepest technical knowledge?
If not, assign this explicitly. The two roles serve different purposes and conflating them recreates the single-person dependency this framework exists to prevent.

4. Is there a change control process for configuration changes made after go-live?
If not, establish one, proportionate to your scale — even a simple log of what changed, why, and who approved it prevents configuration drift from becoming untraceable.

5. Do you have any retained access to implementation-level expertise beyond your internal team?
If not, and your internal capability is genuinely sufficient, that may be fine — but confirm this deliberately rather than discovering the gap during a difficult upgrade or a complex new requirement.

6. Is someone assigned to review and assess vendor updates before they are applied?
If not, assign this. Blind application of updates and indefinite deferral are both worse than a deliberate, tested review process, and this is frequently nobody's explicit responsibility.

7. All of the above in place — is documentation actually being kept current?
Audit this periodically. A support model with the right structure but decaying documentation will fail quietly, and the only defence is checking, not assuming.

Indicative cost and effort

Get a quote for a scoped support model design or health check.

Frequently asked questions

Should we keep our implementation partner on retainer after go-live?
Not necessarily the same partner, and not necessarily at the same intensity, but some form of retained access to expertise beyond your internal team is usually worthwhile for at least the first year or two, when configuration questions and upgrade impacts are most likely to exceed internal capability.

How do we get our system expert to document their knowledge without it feeling like a threat to their role?
Frame it explicitly as protecting and valuing what they know, not replacing them — documentation makes their knowledge an organisational asset rather than a personal liability they carry alone, and this framing, delivered genuinely rather than as a line to appease resistance, matters more than any specific documentation template.

What is the minimum viable support model for a small mid-market company?
A tiered structure (even if tier two and three both point to the same small internal team), a living document of current configuration and known workarounds, one named accountable owner distinct from the deepest technical expert if headcount allows, and some defined path to external expertise for anything beyond internal capability. Elaborate tooling is not required; deliberate assignment of these responsibilities is.

How often should the support model itself be reviewed?
Annually is reasonable for most mid-market companies, and additionally whenever there is a significant personnel change, a major system upgrade, or a new module or integration added — each of these is a moment when the model's assumptions are most likely to need revisiting.

We are mid-implementation now. Is it too early to think about this?
It is the ideal time. Support model design is far cheaper and more effective when built into the implementation plan as a deliverable than when retrofitted afterward, and it directly addresses the training and knowledge-transfer failure pattern discussed in the NetSuite implementation article elsewhere in this series.

Closing — Next steps

The gap between go-live and a sustainable support model is rarely a technical problem. It is an unmade decision — nobody explicitly chose who would own the system, document it, and provide continuity when the person who knows it best is unavailable — and unmade decisions default to whoever happened to be standing closest, which is a fragile foundation for something the business now depends on daily.

If you are already past go-live and uncertain where you stand: ask the person who knows the system best what happens if they are unreachable for a month. Their honest answer is the most direct diagnostic available, and it usually reveals exactly where the support model needs to start.

About the author

Bruno Galo is the founder of Atypical Tech, a NetSuite consultancy serving mid-market clients across Iberia. He specializes in connecting CRM and ERP systems for seamless order-to-cash workflows, building automated order management pipelines that eliminate manual data entry between sales and finance teams. As an official Stacksync implementation partner, Bruno designs and deploys AI agents on integration platforms to handle exception routing, document processing, and reconciliation — turning fragmented order flows into reliable, self-monitoring systems.

LinkedIn: https://www.linkedin.com/in/brunogd

Sources

URLs are publisher-level and should be verified before publication.

• Oracle NetSuite, administration and support documentation — https://docs.oracle.com/en/cloud/saas/netsuite/
• ITIL (Axelos), service management framework — support tiering and change control principles — https://www.axelos.com
• Atypical Tech engagement experience, mid-market ERP support models across Iberia