Migrating off SAP Business One: the options, the order, and what to extract first

SAP Business One is a competent product that a lot of companies genuinely outgrow. That is not a criticism of it — it is what happens when a system sized for one stage of a company keeps running into the next one.

This guide assumes you have already concluded that something has to change, and deals with the part that actually determines whether the move goes well: sequence and data.

What is usually forcing the decision

Three pressures show up repeatedly, often together.

Volume and complexity. Business One is architected for roughly 100 users and moderate transaction volumes; independent reviews note that concurrent user counts, transaction volumes and reporting complexity eventually outgrow the underlying database architecture. The symptom is not a crash. It is month-end taking four days, and reports that have to be run overnight.

Recurring cost. Licence and support renewals scale with headcount rather than with the value the system delivers. This is the same structural pressure visible across the software market, where 79% of IT leaders reported price increases at renewal in the last year.

Customisation ceiling. Extending B1 through the SDK and DI API is possible but narrower than the extension ecosystems around newer platforms. The practical consequence is a growing set of processes that live in Excel beside the ERP because the ERP would not bend.

If none of those describe you, the most economical answer may genuinely be to stay and fix the specific thing that hurts.

The four realistic destinations

Path	Best when	Main risk	Finance migration required?
Up to S/4HANA	You are genuinely enterprise-scale and want one vendor	Cost and duration out of proportion to the trigger	Yes, full
Across to another mid-market package	Your processes are conventional and per-seat cost is acceptable	You inherit a new set of constraints, and migrate twice in a decade	Yes, full
Out to custom operations + smaller accounting core	Operations are your differentiator; accounting is not complex	Requires a supplier who will hand over source code	Yes, but a simpler one
Hybrid: keep B1 for finance, build custom operations	The pain is operational, not financial	Interface discipline — two systems must not drift	No

The fourth row deserves more attention than it usually gets. Most companies describing themselves as “leaving Business One” are actually describing operational pain — production scheduling, warehouse, quoting, dealer ordering, field service — while their accounting is fine. Migrating finance to solve an operations problem is a large project aimed at the wrong target.

On S/4HANA: it is the right answer for some companies. It is worth knowing the scale of the step. Published comparisons put S/4HANA implementation entry costs an order of magnitude above a typical Business One deployment. For a 60–200 person manufacturer, that is a different category of decision, and it should be triggered by strategy rather than by frustration with a report.

Extract this before you do anything else

Do this now, before you talk to vendors, while you still have working access, unpressured timelines and the people who remember why things were configured the way they were.

• Master data with keys. Customers, suppliers, items, BOMs, price lists, exchange rates. Include the internal keys — relationships are worthless without them.
• Transaction history. At minimum three years of closed periods plus everything open. Agree the retention requirement with your accountant, not with your instinct.
• Chart of accounts and every mapping. Which document type posts to which account, and under which conditions.
• Every user-defined field and user-defined table. These are where undocumented business rules hide, and where migrations break.
• Every report and query anyone runs. Including the ones built by someone who has left. Each is a requirement statement for the new system.
• The integration inventory. Every system exchanging data with B1: bank, e-invoicing, e-commerce, marketplaces, EDI, carriers, warehouse hardware. Note the direction, frequency and format of each.
• The spreadsheet inventory. Every workbook that exists because the ERP could not do something. This is your custom-build requirements list, already written.

Two rules. Export in an open format you can read without the vendor’s tools. And validate: row counts, control totals, spot checks against the live system. An export you have not verified is not a backup.

A phased sequence that keeps the company running

Big-bang cutovers fail for a predictable reason: they concentrate all the risk into one weekend, and by the time you discover the problem, the old system is off.

1. Weeks 0–2 — inventory and rehearsal. Complete the extraction above. Run a trial load into a scratch environment. Do not skip this because it produces no visible progress; it produces the list of data problems, which is the most valuable artefact of the whole project.
2. Weeks 2–4 — clean, with owners. Every data problem gets a named owner and a decision. Duplicate suppliers, inconsistent units, obsolete items, three spellings of the same customer. Only your people can decide which record is correct.
3. Weeks 4–8 — one operational module in production. Pick the workflow causing the most pain. Build it, connect it to B1 for the data it needs, and put it in front of real users while B1 still runs. On our bands this sits at $3,000–6,000 over 2–4 weeks, with a clickable prototype in the first two weeks.
4. Months 2–4 — extend module by module. Each increment goes live on its own, each is usable alone, and each can be stopped after. Never build a second module before the first one’s integration is proven in production.
5. Then, and only then, decide about finance. By this point the operational pain is gone, you know how the supplier actually works, and you can judge the finance question on its own merits rather than under pressure.
6. Run parallel for one full period. One complete month-end in both systems, reconciled line by line. Expensive, tedious, and the cheapest insurance available.
7. Retire deliberately. Keep read-only access to the old system for the statutory retention period. Do not let the licence lapse until you have confirmed you can retrieve historical documents without it.

The data traps that actually cause failures

Panorama Consulting’s research attributes the majority of ERP failures to change management, data migration and team experience. The migration half almost always reduces to a small set of concrete problems:

• A field that means different things to different users. A comment field used as a delivery instruction by one team and a payment note by another. Migrating it faithfully migrates the confusion.
• Dates without time zones, or stored as text in mixed formats.
• Character encoding. Turkish, German and Nordic characters silently corrupt across badly configured exports, and the corruption is often only visible on a handful of records nobody checks.
• Decimals and units. Grams versus kilograms in the same column. Two decimal places where three were needed.
• Referential orphans. Order lines whose parent order was deleted years ago.
• Soft-deleted records that the old system hides and a naive export includes.

Each is trivial to fix and expensive to discover late. Rehearsal is what moves discovery earlier.

What to do about reports and customisations

This is the part that consistently takes longer than planned, because nobody has an inventory of it.

Start by counting. Every report, query and layout anyone runs. Include the ones scheduled to email themselves to someone every Monday. Include the ones built by an employee who left. Most companies of this size find between forty and a hundred and fifty, and are surprised by both the number and by how few are actually used.

Then triage into three groups. Reports someone would notice within a week if they stopped. Reports someone would notice within a quarter. Reports nobody would notice. In our experience the third group is typically the largest, and deleting it before migration is the single cheapest scope reduction available.

For each surviving report, capture the definition, not the output. What does “revenue” mean in this report — invoiced, shipped or ordered? Which date drives it? Are intercompany transactions included? These definitions are the actual requirement, and they are usually undocumented and inconsistent between reports, which is its own useful discovery.

Do the same for user-defined fields and tables. Each one is a business rule somebody implemented because the standard system would not bend. Ask what it is for, and whether the underlying need still exists. A meaningful proportion will turn out to be obsolete, and the rest are your custom build requirements, already specified by the people who needed them.

A realistic timeline

For a company of 60 to 200 people, moving operational workflows off Business One while keeping finance in place:

Stage	Duration	Who does the work
Extraction and inventory	1–2 weeks	Mostly you
Data profiling and cleanup decisions	2–4 weeks, overlapping	Business owners per domain
First operational module in production	2–4 weeks	Supplier, with your testing
Second and third modules	4–8 weeks total	Supplier, with your testing
Finance decision, if taken at all	Separate project	—

Note where the effort actually sits. Two of the first three rows are largely your team’s work, not the supplier’s, and they are the rows most likely to be underestimated in a project plan written by a vendor.

What to require from any supplier you engage

• The repository is created in your organisation’s account before the first commit.
• The schema and migration scripts are deliverables, not internal artefacts.
• A deployment recipe that takes a blank server to a running system, tested by someone other than the author.
• Fixed-scope increments with payment tied to delivery into your repository.
• No proprietary runtime underneath that only the supplier can operate.

If a supplier hesitates on the first of those, you have learned what you needed to know before spending anything.

Our sequencing approach for replacing a live system is set out in the migration guide, the data side in detail on ERP data migration, the delivery bands and timelines on the pricing page, and a specific first module can be scoped through the quote form.

Frequently asked questions

Why do companies leave SAP Business One?

Three reasons dominate. Volume — B1 is designed around roughly 100 users and moderate transaction volumes, and reporting complexity outgrows it. Cost — recurring licence and support charges scale with headcount. And customisation limits, since extending B1 through the SDK and DI API is narrower than the app ecosystems around newer platforms.

Is S/4HANA the natural next step from Business One?

Natural in the sales narrative, rarely proportionate in practice. Published comparisons put S/4HANA implementation entry costs an order of magnitude above a typical B1 deployment. For a company of 60 to 200 people, that is usually a step change in cost and complexity out of proportion to the problem that triggered the move.

What should we extract before we start a migration?

Full master data with keys and history, at least three years of open and closed transactions, the chart of accounts and its mappings, every custom field and user-defined table, every report and query somebody relies on, and the full integration inventory. Extract while you still have working access and internal knowledge, not during a contested exit.

Can we keep Business One for accounting and build custom for operations?

Yes, and this is often the least disruptive route. B1 stays the financial system of record; custom modules take over production, warehouse, quoting, dealer ordering or field service; and the two exchange data through defined interfaces. It removes the operational pain without a finance migration, which is the risky half.

How long does migrating off Business One take?

The financial cutover itself is usually short — weeks — because accounting migration is a well-worn path. The long part is everything nobody documented: custom fields, reports and the spreadsheets that fill the system's gaps. On our bands, a first custom operations module goes live in 2–4 weeks, and a multi-department system in 4–8 weeks.

What is the single biggest risk?

Data. Panorama Consulting places poor data migration among the top three causes of ERP failure. The specific failure is discovering, during cutover, that a field everyone assumed meant one thing has meant three different things depending on who typed it. Find that out during a rehearsal, not during a go-live weekend.

Related guides

• ERP data migration: the checklist that prevents a failed go-live
• When does it make sense to leave SaaS and build your own?
• Gulf e-invoicing: what ZATCA and the UAE mandate actually require from your systems

Service page: Migration guide