Plan the SAP Business One Go-Live Correctly

The Go-Live is the moment when Excel spreadsheets, legacy systems, and transitional solutions are no longer an excuse. If you want to plan an SAP Business One Go-Live, you don’t need to theoretically solve every conceivable scenario to the last detail. The key is something else: on the deadline, critical processes must work, the data must be correct, and your team must know what to do. Projects rarely fail because of the software, but because of unclear decisions shortly before the start.

Planning SAP Business One Go-Live Begins Before the Deadline

A Go-Live is not a single date on the calendar. It is the culmination of a series of binding decisions: Which processes will go live? Which data will be transferred? Who is allowed to post in the legacy system? And who decides if something doesn’t go as expected on the first day?

For a small company with three to ten users, a lean start can be sensible. Sales, purchasing, inventory, and finance go live together, while a specific reporting format follows a few weeks later. A growing mid-sized company with multiple entities, warehouse locations, or international requirements usually needs a coordinated phased transition. Both can be correct. It becomes problematic when the scope is only discussed during the Go-Live week.

Therefore, determine early what belongs to the productive core. Typically, these are customer and supplier master data, items, prices, open documents, inventories, bank accounts, and necessary accounting data. Additions like particularly complex reports or rarely used special processes can wait if they endanger the start. This is not a loss of quality, but a clean prioritization without overengineering.

A Go-Live Criterion is Better Than a Gut Feeling

“We are actually ready” is not a reliable release criterion. Better is a short, written list with clear conditions. For example: test postings have been checked, opening balances are correct, open receivables and payables have been reconciled, print layouts work, and responsible users have tested their daily routines.

It’s not just about whether a document can be created. An order must run through to the invoice. A goods receipt must correctly change the inventory and accounting. An incoming invoice must be assigned to the correct supplier, account, and possibly the purchase order. Test the processes with which your company actually earns or spends money - not just the ideal sample case.

Data Migration: Not Everything Old Belongs in the New System

Bad data does not get better with a new ERP. Duplicate business partners, unclear item numbers, incorrect payment terms, and missing tax keys become apparent at the latest when the first document is posted productively. Data cleansing is therefore not a technical side task but part of your business decision.

Define a responsible person for each type of data. Sales checks customers, purchasing checks suppliers, inventory checks items and stocks, accounting checks accounts, tax keys, and open items. The project management coordinates, but it cannot replace professional decisions. Especially when a lot of data has been in various Excel files so far, a clear source per record is needed.

When transferring, the rule is: as much as necessary, not as much as possible. Master data, current stocks, and open transactions belong to the standard case. Historical documents from many years do not necessarily have to be fully migrated if they remain available in the legacy system or archive in a revision-safe manner. This reduces effort, sources of error, and pressure on the Go-Live date.

Plan at least one complete trial run of the data transfer. Afterwards, quantities, values, open items, and central balances are professionally reconciled. Only when this reconciliation is documented does a renewed transfer for the productive start have a reliable basis.

The Cutover Plan Turns Work Steps into Responsibility

In the last week before the start, too many things often happen simultaneously: last changes to master data, final work in the old system, data export, import, checks, and training. Without a Cutover Plan, the dangerous question quickly arises: Who is actually doing this?

A usable plan contains not only tasks but also a responsible person, a time, and a test result for each step. It begins with the last posting date in the legacy system and ends only when the first productive business transactions in SAP Business One are checked. Also consider dependencies. Open deliveries can only be transferred when customers, items, prices, and inventory are correctly set up.

For the deadline itself, you need a clear decision chain. Who is allowed to approve the Go-Live? Who decides on a fallback plan? Who informs users, tax advisors, logistics, or external service providers? In smaller companies, one person can hold multiple roles. The important thing is that the responsibility is known beforehand and does not arise spontaneously.

A fallback plan does not mean you expect failure. It soberly describes what happens if a critical requirement is missing: for example, if inventory values are incorrect or a necessary document print fails. Often it is enough to postpone the start by a controlled period and not allow productive postings until then. Uncontrolled parallel posting in two systems is almost always the beginning of additional reconciliation effort.

Tests Must Reflect the Workday

A test system forgives a lot. The workday does not. Therefore, the later users should test the most important processes themselves. Not so they take over IT tasks, but because they immediately recognize whether a process fits their daily business.

Take real cases from sales, purchasing, inventory, and finance. Test special cases that occur frequently: partial quantities, down payments, credits, different delivery addresses, foreign currencies, or invoices without orders. If your company uses batches, serial numbers, or multiple storage locations, these processes must be in place before the start.

Permissions also belong in the test. A sales employee should be able to create orders but not accidentally change account plans. Accounting needs different rights than inventory. Too broad permissions seem convenient at first but later create risks and unnecessary errors. Too narrow rights, on the other hand, block operations. Here, a targeted test with the actual roles is worthwhile.

If you want to use AI-supported functions for processing incoming invoices or operating via chat, treat them initially as a clearly defined productive process. Check document quality, approvals, posting suggestions, and data protection architecture. Especially with financial and personnel data, it must be clear before the start whether a model hosted in Germany, a separate access key, or a fully local model is used. AI can significantly reduce routine work but does not replace correct posting or defined approvals.

Training: Fewer Slides, More Concrete Cases

A general system training shortly before the Go-Live helps only to a limited extent. Users need answers to their own tasks: How do I create an order? What do I do with an incorrect invoice? Where do I see if goods are available? Who do I call if a posting is blocked?

Therefore, train role-based and close to the start time. Short units with realistic examples are more effective than a whole day of theory. Supplement them with a simple work instruction for the most common processes. It does not have to be perfectly designed. An understandable process with screen images, responsibilities, and clear instructions saves many questions on the first day.

Also appoint a Key User per area. This person is not solely responsible for every problem, but they collect questions, recognize recurring errors, and can solve simple cases directly. This relieves management and prevents ten small uncertainties from becoming a standstill.

The First Weeks After the Start Decide on Acceptance

The project does not end with the release. The first two to four weeks are the stabilization phase. During this time, you should check daily whether orders, deliveries, invoices, payment receipts, goods receipts, and postings run as expected. A short meeting with the Key Users is often enough: What is blocking? What is a training topic? What is an error? What can wait?

Consistently separate errors from improvement requests. An incorrect tax amount, missing authorization for a critical process, or an incorrect data set must be resolved immediately. The desire for an additional report or a more comfortable interface can be planned. Treating both equally loses speed and creates unrest.

RConsult accompanies SAP Business One implementations with exactly this focus: clear responsibilities, tested processes, and a start that fits your company’s everyday life. Not every function has to be ready on the first day. But every critical process must work reliably.

A good Go-Live does not feel spectacular on the first morning. Your team works, documents run through, inventories remain traceable, and accounting has reliable figures. This calm operational capability is the goal you should plan for.