ERP Go Live Checklist for a Smooth Start

The go-live is the moment when good ERP project work pays off - or fails due to small details. Not due to the big strategy, but things like open user rights, incomplete master data, unclear approvals, or missing contacts on the first workday. That’s exactly why you don’t need a theoretical project slide, but an ERP go live checklist that holds up in everyday life.

Especially for small and medium-sized enterprises, the margin around the start is often tight. The team continues to work in parallel, customers don’t wait, suppliers don’t either, and accounting needs reliable figures. If the ERP start wobbles here, you’ll feel it immediately in orders, inventories, invoices, and reporting. A good checklist is therefore not an extra, but a safeguard against unnecessary friction.

What a Good ERP Go Live Checklist Must Achieve

Many checklists are too general. They say things like “check data” or “train users.” Sounds right, but helps little in an emergency. A usable ERP Go Live checklist must be more specific. It must record exactly what is checked, who approves it, by when it must be completed, and what happens if a point remains open.

The difference is crucial. If you find out before the go-live that item master data is incomplete, it can still be resolved. If the same error is only noticed during the first delivery, it becomes hectic. The same applies to price lists, tax logics, bank connections, email templates, print layouts, or role rights. The start rarely fails due to a single big problem. Usually, it’s several small gaps that together become critical.

Before the Go-Live: The Professional Foundations Must Be in Place

Before you talk about the actual switch-over day, there must be calm in the system professionally. This doesn’t mean that every conceivable optimization has already been implemented. It just means that the core processes for your everyday life function reliably.

These typically include sales, purchasing, warehouse, financial processes, and reporting. If you produce, bill of materials, operations, and feedback are added. If you work with service, tickets, contracts, or deployment processes must also be cleanly tested. What matters is not whether a hundred special cases are already modeled. What matters is whether 80 percent of your daily business runs without a workaround.

A common mistake is to tie the go-live to too many nice-to-haves. This delays projects and creates uncertainty. The other extreme is just as risky: going live too early, even though core processes only looked good in workshops but were never realistically played through. Here, as so often, it depends. If a fringe process is still missing, it can be added later. If goods issue, invoicing, or payment reconciliation are not stable, it’s no longer a fringe issue.

Master Data: Not a Glamorous Point, but Often the Most Important

Few people enjoy working on master data. Yet it massively determines whether the start runs smoothly. Customers, suppliers, items, prices, units, tax codes, account assignments, and warehouse parameters must not only be present but also consistent.

It becomes particularly critical with grown Excel structures. Then there are often duplicate customer accounts, old item numbers, inconsistent payment terms, or free text fields that have replaced individual logic for years. If you simply transfer these inaccuracies into the new ERP, the old chaos moves with it.

Therefore, your ERP Go Live checklist should not end with “import completed” for the data. More important are questions like: Are the leading data sources clear? Have duplicates been cleaned up? Are active and inactive datasets separated? Do prices, tax codes, and booking logics match? Is there a final approval from the department? Without this clarity, the go-live becomes unnecessarily expensive because errors then land directly in operation.

Tests: Not Testing More, but Testing Right

Shortly before the start, many teams fall into activism. Then everything is tested again, mostly hectically and without clean documentation. This calms in the short term but does not replace a reliable acceptance.

A better approach is a clear test strategy with real business transactions. An order should not only be created. It should be played through to delivery, invoicing, and payment. A purchasing process should cover ordering, goods receipt, invoice verification, and payment. In finance, it’s not just about bookings, but also about evaluations, period logic, and reconciliation.

It’s also important to think about exceptions. What happens with returns, price deviations, partial deliveries, or blocked creditors? You don’t have to fully secure every exotic special case before the start. But the most common deviations belong in the test. Otherwise, the system appears stable in the workshop and collapses in everyday life.

Users, Rights, and Training

An ERP system can be technically well-prepared and still become unusable on the first day because users can’t work. Rights are too tight, approvals are missing, printers are not assigned, or the team only knows the new processes superficially.

Therefore, training is not a mandatory appointment shortly before the end, but part of the go-live preparation. What matters is that every role knows what it must do on the first day. Sales needs confidence in offers, orders, and invoices. The warehouse must know how bookings, pick lists, and inventory checks run. Accounting must master documents, account assignments, payment runs, and evaluations.

For rights, the rule is: better targeted and tested than generally open. Too broad authorizations create control problems later, too narrow authorizations paralyze processes. The best way is a role model with real practical tests. If a user cannot fully perform their task, it can be resolved before the go-live. Afterward, it costs time, nerves, and often trust in the system.

The Cutover Plan: Who Does What, When, and in What Order?

The actual switch-over moment needs a clear sequence. This is where clean project management separates from hope. A cutover plan defines which tasks are completed in the last days before the start, who is responsible, and what dependencies exist.

These typically include the last data export from legacy systems, final data imports, checking open documents, system approvals, user activation, print and email checks, and the decision from which point only the new system is used. Without this clear timing, parallel worlds arise. Then orders are still recorded in the old tool, invoices are partly written in the new system, and Excel suddenly lives on.

Especially in smaller companies, this point is often underestimated because everyone “already knows what to do.” In practice, this is exactly what is risky. What seems clear in the head is often no longer unambiguous under time pressure. A written, coordinated process saves more problems here than it creates effort.

Support on the First Day: Not Just Reachable, but Capable of Action

Many go-lives fail not at the start itself, but in the first 48 hours afterward. The team works in reality, questions arise by the minute, and suddenly no one is clearly responsible. That’s exactly why your checklist should also cover the hypercare phase.

You need fixed contacts, clear response times, and a simple rule for prioritizing tickets. A blocked goods issue is not the same as a cosmetic layout adjustment. If everything seems equally important, the wrong thing comes first in the end.

Pragmatic ERP partners plan this phase consciously with close support. Not with corporate rituals, but with quick accessibility and clear responsibility. Especially with SAP Business One, it shows how valuable a partner is who doesn’t overengineer but immediately classifies and solves operational problems. RConsult works exactly in this style - direct, predictable, and without surprises.

The Actual Checklist: What You Should Base the Start On

When you approve the go-live, at least these points should be reliably clarified: core processes are professionally accepted, master data is finally checked, users and rights are tested, open legacy documents are evaluated, interfaces are controlled, print and email outputs are approved, financial logics are checked, and support for the first days is firmly organized.

Additionally, there’s a point that’s often forgotten: Who is allowed to stop the start? A clear decision-making instance is needed. If critical errors appear the night before, it shouldn’t turn into an endless discussion. Either the risk is bearable, or the start is postponed. Both can be right. It’s only wrong to go into Monday with unclear responsibility.

What You Don’t Have to Do Perfectly

A go-live is not a beauty contest. Not every dashboard, not every evaluation, and not every special process must be at full development at the start. Those who wait for everything to be really finished often postpone for months and unnecessarily hold on to old workarounds.

More important is that your system reliably supports daily business and that it’s clear which points will come in phase two after the go-live. This separation creates focus. It prevents the project from being overloaded with additional requests shortly before the end. A clean start almost always beats a delayed perfection claim.

If you want to seriously secure your ERP implementation, then treat the go-live not as a calendar date, but as a business start. With this perspective, an ERP Go Live checklist becomes not a paper for the project folder, but a tool that lets you work calmly on the first day.