What Happens After Go-Live

Go-live is the most visible date in an ERP project and the most misunderstood. It is not the finish line. It is the moment the new system becomes the system of record — the point at which your orders, invoices and stock movements stop being test data and start being the numbers your accountant will file. Everything before it is rehearsal under controlled conditions. Everything after it is your business running on software that has never carried real volume, real users or real exceptions. That period has its own shape, its own categories of work and its own end point, and most teams walk into it without knowing any of the three.

What go-live actually means

In an ERP context, go-live is the cutover: the date a new system takes over as the authoritative record for a defined scope — a legal entity, a country, a warehouse or a set of modules. Opening balances are loaded, the legacy system is set to read-only or retired, and every new transaction is posted in the new environment. In project management terms it is a milestone rather than a phase, which is exactly why it gets treated as an ending. What it does not mean is that the system is finished, that users are competent, that the migrated data is correct, or that the project team can be released. A system can be technically live and operationally unusable at the same time, because the two are measured differently: technical success is whether transactions post, business go-live is whether people can do their jobs without inventing a workaround.

Hypercare: the window immediately after cutover

Hypercare is the deliberately over-resourced support period that follows the cutover. The people who configured the system stay attached to it, at response times far shorter than any normal support contract, because the failure modes in the first fortnight are the ones nobody has seen before. For a single-entity implementation we scope two to four weeks, extended when the go-live spans several countries or lands near a period close. The duration matters less than the staffing model. Hypercare only works if the person answering a question is the person who built the thing being asked about. Route week-one questions into a generic ticket queue and every answer arrives after the user has already found their own way around the problem — and workarounds invented in week one are still in use two years later.

The six kinds of work that appear in weeks 1–12

• Data corrections. Migrated records that passed validation but are wrong in context: a customer on the wrong payment terms, a product with a unit of measure that made sense in the legacy system and does not here, an address that was never used because the legacy system quietly ignored it. These surface transaction by transaction rather than in a single reviewable batch.
• Permissions and roles. Usually the largest source of week-one tickets. Roles are designed against an org chart and then used against reality — someone needs to post a credit note at six in the evening and the only person holding that right is unreachable.
• Integration failures. Interfaces to a webshop, a WMS, a bank or a carrier behave differently against production volumes and production edge cases. Failures here are silent more often than loud: a queue stops draining and nobody notices until a delivery does not arrive.
• Report and output requests. Users lose a report they relied on for years and ask for it back. Some are genuine gaps; many are the old report requested out of habit, and some describe a number the business no longer calculates that way. All of them need triage rather than automatic delivery.
• Training gaps. The distance between what was taught in a classroom on clean data and what the job demands under time pressure. It shows up as the same team asking about the same screen repeatedly, which is a signal about the training, not about the people.
• The first period close. The heaviest single event in the whole window, and the one most often missing from the plan.

That last item deserves its own attention. The first month-end close in a new ERP is where every compromise made during migration becomes visible at once: unbalanced opening entries, intercompany mismatches, stock valuation that will not reconcile to the general ledger, and the first VAT return that has to be produced from figures the finance team does not yet trust. For a Belgian entity there is more in the queue behind it — the first Intrastat declaration and the first intra-community listing out of the new system, filed against statutory deadlines that do not move because your ERP is new. Treat the first close as a planned event with named owners and a dry run, not as business as usual. It is also an argument about timing: a cutover early in a period gives users weeks to build competence before the close arrives, while one late in a period gives them days.

Who owns what

• The implementation partner owns defects — anything that does not behave as designed and agreed. This is warranty work, not new scope, and the boundary between the two belongs in writing before go-live rather than in an argument after it.
• The client owns data and decisions. No external party can determine what your correct payment terms are, or which of two conflicting departmental processes is now the standard. Waiting for a partner to decide these is the most common cause of a stalled correction list.
• A named internal application owner owns the queue. One person on your side who decides what is urgent, what is a change request and what is a training issue. Without that role every question becomes a partner question and the partner becomes the bottleneck.
• Key users own their own department. They are the first line, answering routine questions so that specialists stay free for the problems only specialists can solve. This is the role that decides whether support costs fall after month three.
• Someone owns the deferred backlog. Everything cut from scope during implementation still exists as a list. Given an owner and a review cadence it becomes a roadmap; left unowned it becomes a grievance.

When hypercare ends and steady state begins

1. One full period close completed in the new system, reconciled and signed off by finance.
2. No open critical or high-severity defects, with everything remaining triaged and scheduled.
3. Ticket volume falling week on week and dominated by questions rather than faults.
4. Every core process run end to end by your own team, without partner involvement, at least once.
5. Documentation and role assignments current, so that the answers live somewhere other than in one consultant’s head.

Agree those criteria before hypercare starts, because the alternative is an exit by attrition — support quietly thinning out until the day something breaks and nobody is sure who to call. When the criteria hold, the engagement moves to steady state: defined response times, a change process, a release cadence, and a backlog reviewed on a schedule rather than by whoever shouts loudest. Steady state is not the absence of work. It is the same work arriving at a predictable volume, handled by people whose job it is, with a route for improvements that does not require a new project every time. The organisations that come through a go-live well are rarely the ones with the fewest problems in week one. They are the ones that expected the problems, recognised which category each belonged to, and had already agreed who would pick it up.