Migrating to SAP Business One: a practical guide for UK businesses

A SAP Business One migration is rarely a single event. For most UK companies it means one of two journeys. Either you are moving to SAP Business One from spreadsheets, an accounting package or an older ERP, or you already run it and need to move between versions. The principles overlap, but the risks differ, so this page treats them separately.

If you are still weighing the product itself, start with our guide to ERP migration. If you have already decided to switch to SAP Business One, read on.

Why UK businesses decide to move to SAP Business One

Companies tend to look at moving to SAP Business One when the current setup stops keeping pace with the business. Typical triggers include:

• a patchwork of Excel workbooks that only one person fully understands;
• an accounts package that handles the ledger but not stock, purchasing or production;
• an older ERP whose version, hosting or supplier no longer fits;
• growth across sites or subsidiaries that demands consolidated reporting;
• compliance pressure, such as Making Tax Digital for VAT, that exposes manual re-keying.

SAP Business One is aimed at small and mid-sized organisations and covers finance, sales, purchasing, inventory and reporting in one database. Our overview of the modules shows what you would be moving into.

Migrating to SAP Business One: where you start matters

From Excel and standalone spreadsheets

This is the least structured starting point and often the hardest to clean. Spreadsheets hold no enforced rules, so the same customer may appear under several spellings, and item codes may be reused or missing. Expect the clean-up to be the largest part of the work, not the load itself.

From an accounting package such as Sage

Accounting software gives you well-structured ledgers, customers and suppliers, which makes the master data straightforward to map. The gap is usually in everything the package never did: stock by location, batch or serial tracking, production and purchasing workflows. Your chart of accounts needs a deliberate review rather than a straight copy, because the new system may let you simplify it. If you are comparing the two products, see Odoo vs Sage for how that landscape looks more broadly.

From an older ERP

Here the data is rich but tangled. Years of customisation, bespoke fields and workarounds have to be understood before they are replaced. Decide early which behaviours you want to reproduce and which you are happy to retire. The more your old system was customised, the more important a proper fit review becomes, and customisation options in SAP Business One should be assessed before you promise users that every habit will survive.

What SAP provides for the data move

SAP's own implementation methodology places the migration of data from the legacy system in the realisation phase of the project, and supplies a data migration guide among the tools of that methodology. In practice your integrator uses it as a framework: define the objects to load, prepare the files, load them in a test company, check the results and repeat until the load is clean.

That sequence matters more than any single tool. A migration that is only attempted once, on the day of go-live, is a migration that fails in public. For the surrounding project, see how an implementation is normally structured.

Which data to bring across

Not everything deserves to move. A useful rule is to separate data into three groups.

Cleaning before loading

Cleaning is where most of the value is created. Practical steps include:

1. remove duplicate and dormant customers, suppliers and items;
2. standardise addresses, postcodes, units of measure and naming conventions;
3. agree one owner for each data set who signs off the result;
4. reconcile source totals, such as debtors, creditors and stock value, before and after the load.

Ask your finance lead and your accountant to sign off the opening balances. Reconciliation to the old ledger is the proof that the migration worked.

How much history to import

More history means more mapping, more testing and more places to go wrong. Many firms load open items and summarised prior periods, then keep the old system or an archive available read-only for enquiries. Decide this with your accountant, since the right answer depends on audit needs and on how often users genuinely look back.

Choosing a cut-over strategy

The cut-over is the moment the business stops using the old system and starts using the new one. Three broad approaches exist:

• Single cut-over: everything switches at once. Simple to explain, but demanding on a small team.
• Phased by function or site: finance first, then sales, then warehouse, or one site at a time. It spreads risk but means temporary interfaces between old and new.
• Parallel running: both systems operate for a limited period. It builds confidence but doubles the workload, so keep it short and targeted.

For many UK SMEs, a single cut-over at a period end is the cleanest, because balances, VAT returns and payroll cut-offs line up. If you also run payroll in a separate tool, plan the date with that cycle in mind; our page on payroll and HR in SAP Business One explains what the product covers and what usually sits alongside it.

Testing before you go live

Testing is the part most often squeezed when the timetable slips. A sound test plan includes:

• Data load rehearsals in a copy of the company database, repeated until totals reconcile.
• Process tests that follow a real order from quotation to cash and a real purchase from request to payment.
• Integration tests for every connected system, such as your website, EDI links or banking. See integrations for what those links involve.
• User acceptance testing by the people who will do the work, not only by the project team.
• Tax and reporting checks, including that VAT outputs match what you need for Making Tax Digital. Our guide to Making Tax Digital and your ERP covers what to verify.

Training belongs in the same window. Users who meet the system for the first time on go-live day will create the errors you spent weeks removing, so book training before the cut-over, not after.

A rollback plan you can actually use

Every migration needs a documented way back. That means:

1. a full backup of the old system, taken and verified at the freeze point;
2. a clear go or no-go decision point, with named people and criteria;
3. a defined window in which reverting is still practical, before new transactions in the new system make it costly;
4. agreement on how any transactions entered in the new system would be re-created if you revert.

A rollback plan that has never been discussed is not a plan. Agree it in writing with your integrator well before the date.

Migrating between SAP Business One versions

If you already run SAP Business One, the question is how to move to a newer release safely.

How SAP delivers new versions

According to SAP, it guarantees at least five years of mainstream maintenance for each version family, counted from general availability of the major release, and later functional deliveries are covered. SAP's maintenance page lists version 10.0 as in mainstream maintenance until 31 December 2028, with the dates subject to change. Versions 8.8, 8.81, 8.82, 9.0, 9.1, 9.2 and 9.3 have completed their mainstream maintenance period. The same page says only that version 11 will follow version 10, and gives no date.

Since version 10.0, SAP has delivered innovation continuously through cumulative feature packages. These bring new features, fixes, security corrections and legal updates, and interfaces remain stable between the major version and its feature packages. SAP also distinguishes support packages, cumulative patches for the cloud edition and hotfixes, the last being temporary solutions outside the normal cycle. SAP does not provide fixes or security patches for old feature packages, support packages, patches or hotfixes, so staying current is a security question as well as a functional one.

For more on how releases and editions differ, see versions and editions.

Upgrade paths and cost

Direct upgrades are supported only between consecutive versions, for example from 9.3 to 10.0. A non-consecutive jump needs several steps, and each step needs testing. SAP provides version upgrades at no charge to customers with a valid maintenance contract, so the cost lies in the project work, not the licence.

What to check before an upgrade

• compatibility of every add-on and extension with the target version;
• custom reports, queries and user-defined fields;
• integrations that call the system;
• the database platform and server sizing, including any move to a hosted or cloud environment;
• a full rehearsal on a copy of the live database, with users testing it.

If a previous upgrade went badly or the system has drifted, an audit can show what to fix before upgrading.

Mistakes that derail a migration

• Loading dirty data and hoping the new system will tidy it.
• Copying the old chart of accounts and processes without questioning them.
• Treating the cut-over date as fixed when testing has not finished.
• Forgetting add-ons, reports and integrations until the last week.
• Leaving key users untrained and the partner as the only person who understands the setup.
• Having no tested rollback and no named decision-maker on go-live day.

Our wider guide to ERP project mistakes shows where the same patterns appear across other products.

Choosing who runs the migration

The quality of a migration depends heavily on the team that runs it. A good integrator can show how it handles data mapping, rehearsals and rollback, and can explain it in plain language to your finance and operations leads. Read how to choose a SAP Business One partner, and see the UK-specific page for local points such as localisation and tax.

ERP Integrator is a free matching service. We are not affiliated with SAP, and we do not carry out the project ourselves: we connect you with an integrator suited to your starting point, your sector and your region, and that integrator delivers the migration.

Software names mentioned are trademarks of their respective publishers and are referred to for information only. This site is independent and is not affiliated with any software publisher.