It was go-live Tuesday. The warehouses were ready, users had been trained and the partner had people on site. At ten in the morning the first invoice went out with the wrong price: the migrated price list carried values from two years ago. By noon, a customer showed up three times with three different tax IDs. The system was working fine. The data loaded into it wasn't.
When a company evaluates SAP Business One solutions, most of the conversation is about modules, licenses and price. Implementation gets treated as paperwork the partner will sort out. In practice, it's the part that decides whether the ERP works well from the first month or drags patches around for a year. This article walks through the usual stages of an SAP Business One implementation, what's at stake in each, and the mistakes that most often push back go-live at small and midsize companies.
The stages of an SAP B1 implementation
For Business One, SAP documented its own methodology, the Accelerated Implementation Program, with five phases. Every partner adapts it, but the underlying sequence holds:
| Phase | What happens | What you should have at the end |
|---|---|---|
| Project preparation | Scope, team, schedule and owners on each side are defined | A plan with dates and names, and scope in writing |
| Business blueprint | The partner maps how you buy, sell, invoice, manage inventory and close the month | A design document your team reviewed and signed off |
| Realization | Configuration, development, integrations and test data loads | The system configured and tested with your company's real data |
| Final preparation | Final migration, training, user testing and cutover plan | Validated data, trained users and a plan for cutover day |
| Go-live and support | Production start and support during the first weeks | Incidents closed and an orderly handover to regular support |
The table looks tidy. The trouble is usually in what it leaves out: who from your company takes part, how much time they actually give it, and what happens when someone asks for "just one more change" during realization.
Master data: where projects slip
Customers, vendors, items, price lists, chart of accounts, warehouses. That's master data, and when an implementation runs late, the problem is more likely here than in the software configuration.
The standard tool for loading it is the Data Transfer Workbench (DTW). According to SAP's documentation, data is prepared in spreadsheet templates and saved as delimited text files. Before importing you can run a simulation that lists the errors, or test the load on a copy of the production database. The tool does its job well. What it can't do is decide which of the three records for the same customer is the right one.
A few questions worth answering before the first test load:
- Who owns each master file? Someone in your company has to approve the final customer file, someone else the items, someone else the chart of accounts. If the answer is "the partner," nobody owns it.
- What gets migrated and what stays behind? Customers with no activity in years, discontinued items and one-time vendors clutter the new system from day one.
- How much history do you need? Many companies migrate opening balances and open documents, and look up history in the old system. Migrating years of transactions costs a lot more and is rarely worth it.
- How do balances reconcile? Receivables, payables, inventory value and ledger balances must match the old system as of the cutover date. Finance signs off on that reconciliation, not the consultant.
Something that often goes unnoticed: migration files are full of personal data about customers, vendors and employees. Chile's Law 21,719 takes effect on December 1, 2026, so it's worth agreeing on where those spreadsheets travel, who can access them and when they get deleted. If you also plan to use production copies for testing, see what we wrote about real data in test environments and Law 21,719.
Chilean localization and integrations
SAP Business One has a localization for Chile, but that doesn't mean electronic invoicing works out of the box. Issuing electronic tax documents is usually handled with an add-on from a local partner or by integrating an e-invoicing provider. That piece needs to be in the plan from the design stage, with real tests against the SII (Chile's tax authority) before cutover. Leave it for the last week and that's where the schedule breaks.
Integrations work the same way: banks, e-commerce, payroll, WMS, CRM or Power BI reporting. Each one brings its own requirements gathering, its own tests and someone on the other side who has to answer emails. Advice we give often: separate the integrations you need to operate on day one from those that can come in a second stage. A go-live with fewer moving parts is easier to stabilize.
Training and key users
Training can't be a week of classes right before cutover. What works best in the implementations we've seen is having key users per area (finance, sales, purchasing, warehouse) who join from the design stage, test with their own cases and then teach everyone else.
The catch is that those key users almost never drop their regular job. If the chief accountant has to validate the balance migration in the middle of the monthly tax filing, the project waits. Book their time formally, in writing, and keep critical phases away from month-end closes and the busy season.
Common mistakes that delay go-live
These come up again and again in partner guides and in the SAP community, and they match what we see in practice:
- Scope that grows unchecked. Every new requirement during realization shifts testing, training and migration. A simple change-control procedure, with impact on time and cost, saves arguments.
- Data cleaned too late. If the first test load happens a month before cutover, there's no time to fix anything.
- Key users with no time assigned. The project ends up at the mercy of day-to-day work.
- Testing with sample data. The system looks perfect with three fictional customers. Test with a real month of your operation: your discounts, your returns, your credit notes.
- Customizing before understanding the standard. Often the process someone wants built already exists in SAP B1 under another name. And every custom development has to be maintained through each upgrade, something we cover in SAP Business One: support, upgrades and roadmap.
- No plan for the day after. The first weeks after go-live are when incidents pile up. If the contract doesn't say who responds and how fast, the company improvises.
How long does an SAP Business One implementation take?
There's no honest number that fits everyone. Timing depends on the number of companies, the modules, the volume and quality of the data, the integrations and how available your team is. Be wary of a fixed timeline delivered before anyone has mapped your processes. A reasonable ask is a phased plan with verifiable milestones (approved design, reconciled test load, full integration test passed) and a schedule review at each one.
Frequently asked questions
Is SAP Business One a good fit for small businesses?
Yes, it's built for small and midsize companies. Whether it suits yours depends on your processes, the number of users and how much you need to connect it to other systems.
What tool is used to migrate data into SAP B1?
The most common is the Data Transfer Workbench, which imports data from templates and lets you simulate the load before running it. The tool helps, but cleaning and validating the data is your team's job.
Can go-live happen in stages?
Yes, and it's often a good idea: start with finance, sales, purchasing and inventory, and add integrations or advanced reporting in a second phase.
Already implemented, or about to?
At Disrupsoft we work around SAP Business One: integrations with Azure and Power Platform through Service Layer and DI-API, analytics with Power BI, migrations and upgrades between SQL Server and SAP HANA, and corrective and evolutionary AMS support. If you're preparing for go-live or your system ended up halfway there, let's talk. More on our SAP services page.
