Migrating SAP B1 to Business Central requires SQL/HANA extraction, structural data mapping, add-on replacement, and 3–6 months. Separate data migration from implementation.
There is no native migration path from SAP Business One to Microsoft Dynamics 365 Business Central; the process requires full data extraction, structural mapping, and reconciliation. The two platforms use fundamentally different data models — for example, SAP B1's unified Business Partner table (OCRD) must be split into separate Customer and Vendor records in BC, and B1's cryptic table schema (OINV, ORDR, OJDT) must be mapped to BC's distinct header/line architecture with different posting group logic. Significant custom work is required for extraction scripting (varying by SQL Server or HANA), translating User-Defined Fields into BC table extensions or dimensions, replacing SAP add-ons (Boyum, Beas, Produmex) with AppSource equivalents, and converting Crystal Reports to Power BI.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Maintenance timeline clarification
There is no general SAP Business One end-of-life deadline on December 31, 2027. SAP states SAP Business One 10.0 is in mainstream maintenance until December 31, 2028, subject to change. The December 31, 2027 date applies to SAP Business Suite 7 core applications (ECC), not SAP Business One — these are different product tracks with different timelines. (support.sap.com)
HANA SQL syntax differs from T-SQL in significant ways — case sensitivity for
HANA SQL syntax differs from T-SQL in significant ways — case sensitivity for identifiers, different date functions, and no TOP keyword (use LIMIT instead). If you have complex extraction queries written for SQL Server, they will not run as-is on HANA.
Do not extract active, open transactional data (like open sales orders or unapplied
Do not extract active, open transactional data (like open sales orders or unapplied payments) using raw SQL while bypassing the DI API. You risk exporting orphaned records that will fail Business Central's posting validation routines.
If you cannot explain why a historical object must live inside Business Central, archive
If you cannot explain why a historical object must live inside Business Central, archive it instead of forcing it through the migration. The same principle applies in long-history BC projects like Dynamics GP to Business Central: Migrating 20 Years of History.
Do not attempt to rebuild every Crystal Report
Many B1 reports were created years ago for requirements that no longer exist. Audit usage before rebuilding — if no one has run a report in six months, archive it.
The data created by add-ons (production history in Beas, warehouse transactions in
The data created by add-ons (production history in Beas, warehouse transactions in Produmex) lives in custom tables within your B1 database. This data does not map to standard BC tables. You need custom extraction scripts and a clear decision: migrate it into BC custom tables, archive it for reference in a data lake, or build a read-only Power BI model. Historical add-on data often belongs in a reporting archive rather than the live transactional path.
If someone promises full SAP B1 to BC migration in eight weeks, ask three questions: What
If someone promises full SAP B1 to BC migration in eight weeks, ask three questions: What add-ons are excluded? How much history is excluded? What reconciliation is excluded? One of those answers is usually carrying the schedule.
Separate your BC implementation partner (who configures the system) from your data migration team
Mixing the two creates resource conflicts and timeline compression. See Why Data Migration Isn't Implementation for a detailed breakdown.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Scope the ledger, the subledgers and the audit obligations.
Objective Agreed scope across master data, open transactions and historical balances, with finance and audit signed up.
Keep these open
-
Inventory master data and transaction volumes in SAP Business One
Count GL accounts, customers, vendors, items, fixed assets, open AR and AP, and transaction lines by year. Transaction line volume, not header count, is what determines your load time.
Data Profiler Get real record counts instead of estimating from memory -
Decide the history strategy with finance and audit
Choose between opening balances only, open items plus balances, or full transactional history. This is the single biggest scope decision in an ERP migration: full history multiplies effort many times over, and most organisations land on balances plus open items plus a read-only archive.
Full transactional history is rarely worth the cost. Confirm what your auditor actually requires before assuming you need it.
Vendor Evaluator Score Dynamics 365 Business Central against alternatives on weighted criteria -
Consult the external auditor early
The auditor has views on cut-over timing, audit-trail retention and how you evidence that balances carried across correctly. Finding this out after go-live can mean a qualified opinion, so get it in writing now.
-
Review the chart of accounts and decide whether to redesign
A migration is the natural moment to restructure the COA, and also the riskiest one. If you redesign, you need a mapping from old to new for every historical balance, plus a plan to restate comparatives.
Redesigning the chart of accounts mid-migration doubles the reconciliation burden. Treat it as a separate, sequenced project if you can.
-
Catalogue integrations and statutory reporting
List banking feeds, payment gateways, tax filing, payroll, CRM, e-commerce, warehouse and BI. Then list every statutory and tax filing obligation with its deadline — those deadlines constrain your window absolutely.
-
Pick a period-aligned go-live date
ERP cutovers align to a period boundary — ideally the start of a fiscal year, otherwise the start of a clean month. Mid-period cutover means split-period reporting for the rest of the year.
SAP Business One → Dynamics 365 Business Central specifics
- Weeks 1–3
- Discovery, B1 data audit, add-on inventory, UDF mapping decisions.
- Weeks 4–8
- BC configuration by your implementation partner (chart of accounts, posting groups, warehouse setup, user roles).
- Weeks 6–12
- Data extraction scripts, transformation logic, first test migration.
- Weeks 10–16
- Second and third test migrations, UAT with key users, delta reconciliation.
- Weeks 14–20
- Final cutover migration, parallel run, go-live support.
Don't move on until
- Chart of accounts and master-data counts confirmed
- History strategy agreed: balances, open items, or full transactional detail
- External auditor consulted on the migration approach
02 Data Audit Reconcile the source before you migrate it — you cannot fix a ledger later.
Objective A source ledger that balances, with master data cleansed and every open item agreed.
Keep these open
-
Produce and sign off a source trial balance
Run the trial balance in SAP Business One and have the controller sign it. This is your migration baseline: without a signed pre-migration position you have nothing to reconcile the target against, and any later discrepancy is unarguable.
Without a signed, dated source trial balance you cannot prove the migration preserved the ledger. Do this before anything else.
-
Reconcile subledgers to the general ledger
Confirm AR, AP, inventory and fixed-asset subledgers tie to their GL control accounts. Pre-existing breaks must be resolved in SAP Business One: migrating an out-of-balance ledger makes the break permanently unattributable.
Data Profiler Profile the SAP Business One export for nulls, outliers and type drift -
Clean and deduplicate master data
Deduplicate customers, vendors and items, and identify records that should not carry forward. Duplicate vendors are also a fraud-control weakness, so this has value beyond the migration.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Agree open AR and AP item by item
Every open invoice, credit note and payment on account needs an owner and an agreed amount, including partially-paid items and foreign-currency balances. Open items are what customers and vendors will dispute in week one.
-
Validate export structure, encoding and precision
Check numeric precision and rounding on the export, and confirm dates and currency codes are unambiguous. Precision loss on amounts is silent, cumulative and produces penny differences that take days to trace.
Amounts exported at reduced precision will not re-total. Verify decimal places before you accept the export.
CSV Validator Catch broken headers and ragged rows in the raw export -
Scan for regulated data and produce masked test data
ERP data holds bank details, tax IDs and payroll information. Scan it, restrict who can see it, and generate a masked copy for the sandbox and for any implementation partner.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Add-on data preservation
Historical data from Beas, Produmex, Boyum, and other add-ons is extracted from custom tables and either mapped to BC equivalents or packaged for archive access.
SAP Business One → Dynamics 365 Business Central specifics
- Direct SQL/HANA extraction
- Custom scripts against the B1 database that pull master data, open transactions, and historical documents with full UDF coverage. No reliance on B1's limited export tools.
Don't move on until
- Trial balance in SAP Business One balances and is signed by the controller
- AR and AP subledgers reconcile to the GL control accounts
- Master data deduplicated and inactive records identified
03 Field Mapping Map the COA, the dimensions and the subledger structures.
Objective A signed mapping covering the chart of accounts, dimensions, tax codes and currency handling.
Keep these open
-
Map the chart of accounts account by account
Every source account maps to exactly one target account, or to a documented split with agreed proportions. The controller reviews and signs this line by line — an unreviewed COA map is how a balance sheet stops balancing.
Schema Mapper Opens pre-loaded with the SAP Business One → Dynamics 365 Business Central field pair -
Map dimensions, cost centres and analysis codes
ERPs differ structurally here: segments, dimensions, tracking categories and classes are not interchangeable. Confirm how Dynamics 365 Business Central models analysis and whether your existing reporting hierarchy survives the translation.
-
Map tax codes, rates and jurisdictions
Map every tax code with its rate, jurisdiction and reporting treatment, then verify the mapping reproduces your last filed return. Tax errors are statutory exposure, not reporting inconvenience.
A tax-code mapping that has not been tested against a previously filed return is untested. Reproduce a real filing before sign-off.
-
Decide multi-currency and exchange-rate handling
Confirm functional and reporting currencies, and how historical rates are stored. Revaluing historical transactions at current rates rewrites reported results and will not tie to filed accounts.
Historical transactions must retain their original transaction-date rates, or your comparatives will not match filed statements.
-
Map master data and subledger structures
Map customer and vendor records with their payment terms, credit limits and tax registrations, and item records with units of measure and costing method. Costing-method differences change inventory valuation, which changes the balance sheet.
-
Set load order and freeze the spec
COA, then dimensions, then master data, then opening balances, then open items, then any historical detail. Version and sign off the spec with the controller before the pilot.
SAP Business One → Dynamics 365 Business Central specifics
- Structural transformation
- B1's single Business Partner table becomes separate Customer and Vendor records. Marketing Documents split into BC's distinct Sales/Purchase document types. UDFs route to table extensions or dimensions based on your reporting requirements.
Don't move on until
- Account-by-account COA mapping reviewed by the controller
- Tax codes and jurisdictions mapped and verified against filings
- Multi-currency and rate handling agreed with finance
04 Test Migration Prove the ledger balances in the target before you trust it.
Objective A sandbox load whose trial balance matches the signed source position to the penny.
Keep these open
-
Configure the Dynamics 365 Business Central sandbox with the agreed structures
Build the COA, dimensions, tax codes, currencies, fiscal calendar and posting rules before loading anything. Every one of these affects how a posted transaction lands, so an unconfigured sandbox produces meaningless results.
-
Load master data and validate it
Load customers, vendors and items first and verify counts, payment terms, tax registrations and costing methods. Transactions cannot post correctly against wrong master data, so this gate comes before any balance work.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Load opening balances and prove the trial balance ties
Load opening balances and run a trial balance in Dynamics 365 Business Central, comparing to the signed source position. It must match exactly — a rounding difference here is a mapping defect, not a rounding difference.
Any variance at all between source and target trial balance must be explained line by line. "Close enough" is never acceptable in a ledger.
-
Load open items and reconcile the subledgers
Load open AR and AP with their ageing intact, then confirm subledger totals tie to GL control accounts and that ageing buckets match. Ageing that shifts means transaction dates mapped wrongly.
-
Run a full period-end close in the sandbox
Execute the whole close: revaluation, accruals, depreciation, tax calculation, and financial statement generation. Compare every statement to SAP Business One for the same period. The close is where structural mapping errors finally become visible.
-
Test transactions end to end and reproduce a tax filing
Post a sales order to cash and a purchase order to payment, then generate the tax return for a previously filed period and compare it to what you filed. If both reconcile, the configuration is sound.
Don't move on until
- Target trial balance matches the signed source trial balance exactly
- Subledgers reconcile to control accounts in the target
- A full period-end close has been run in the sandbox
05 Cutover Switch the ledger on a period boundary, with balances proven.
Objective Balances and open items live in Dynamics 365 Business Central, transacting resumed, and a signed post-load trial balance.
Keep these open
-
Close the final period in SAP Business One and freeze posting
Complete the period-end close, then lock posting entirely. An ERP freeze is absolute: a single journal posted to the old system after the final export leaves the two ledgers permanently divergent.
One journal posted in the old ERP after the final export breaks the reconciliation permanently. Lock posting at the system level, not by asking people nicely.
-
Publish the cutover runbook with the abort point
A timed, owner-named sequence for load, balance verification, integration switch and go/no-go, with an explicit abort criterion. The trial-balance check is the gate — nothing proceeds until it ties.
-
Load balances and open items into production
Load the final opening balances and open AR/AP into Dynamics 365 Business Central production, following the pilot-proven sequence. Do not improvise the order under time pressure.
-
Reconcile and sign the post-load trial balance
Run the trial balance in Dynamics 365 Business Central and reconcile it to the signed source position, then have the controller sign the result. This signature is your evidence for the auditor and your go/no-go gate.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint banking, payment and tax integrations
Switch bank feeds, payment gateways, tax filing connections, payroll and BI, then process one real low-value payment and one bank reconciliation end to end. Banking errors move real money, so verify with live traffic.
Payment integrations left connected to the old ERP can duplicate real payments. Disable them before switching, not after.
-
Go/no-go, then open for transacting with daily reconciliation
Call the decision on the signed trial balance, open Dynamics 365 Business Central for posting, and reconcile daily for the first two weeks with finance support on hand. Keep SAP Business One read-only for statutory retention — this is an audit requirement, not a preference.
Don't move on until
- Post-load trial balance signed by the controller
- Banking, tax and payment integrations verified live
- Users transacting and the first daily reconciliation clean
06 Validation Prove the statements, the tax position and the audit trail.
Objective Financial statements reproducing the source position, a clean tax filing, and auditor acceptance.
Keep these open
-
Reconcile the full ledger and all subledgers
Reconcile trial balance, AR, AP, inventory, fixed assets and bank against the signed source position. Produce a single reconciliation pack that goes to the auditor.
Migration Validation Tool Reconcile SAP Business One and Dynamics 365 Business Central record-for-record -
Reproduce the financial statements
Generate balance sheet, P&L and cash flow in Dynamics 365 Business Central and compare to the pre-migration statements. Every variance needs a documented explanation traced to a specific mapping decision.
-
Complete and review the first period-end close
Run the first real close in Dynamics 365 Business Central with extra review at every step. Compare its duration and outcome to your historical close, and treat anything unexpected as a live finding.
Data Profiler Prove field completeness held up through the load -
Verify the tax position and file
Generate and review the first tax filing from Dynamics 365 Business Central, reconciling it to the underlying transactions before submission. Have the tax lead review it independently.
The first statutory filing out of a new ERP should be reconciled manually to source transactions before submission.
-
Confirm controls, segregation of duties and audit trail
Verify user permissions, approval limits, segregation of duties and audit logging in Dynamics 365 Business Central. Controls do not migrate, and a control gap found by an auditor is far more expensive than one you find yourself.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Obtain auditor acceptance and retain the archive
Walk the auditor through the reconciliation pack, get written acceptance, and retain SAP Business One read-only for the full statutory retention period. Diarise the retention expiry rather than the contract renewal.
SAP Business One → Dynamics 365 Business Central specifics
- Iterative validation
- Multiple test migrations with reconciliation reports before cutover. We do not go live on a feeling.
Don't move on until
- Financial statements match the pre-migration position
- First period-end close completed and reviewed in Dynamics 365 Business Central
- Auditor satisfied and archive retained for the statutory period
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
SAP B1 Object B1 Table
| SAP Business One field | Dynamics 365 Business Central field | Notes |
|---|---|---|
| Business Partners (Customers) | OCRD (CardType='C') | Split into separate Customer and Vendor records |
| Business Partners (Vendors) | OCRD (CardType='S') | Same source table, different target |
| Items | OITM + OITW (warehouse data) | Map warehouse-level data to BC Stockkeeping Units (SKUs) |
| Sales Orders | ORDR + RDR1 | BC uses separate header/line architecture |
| Purchase Orders | OPOR + POR1 | Map B1 tax groups to BC VAT posting groups |
| A/R Invoices | OINV + INV1 | Historical — import as posted entries |
| Journal Entries | OJDT + JDT1 | Map B1 account codes to BC G/L account numbers |
| User-Defined Fields | CUFD + UFD1 | Decision point: extend BC tables or use dimensions |
| Authorizations | OUSR + USR5–USR7 | Map B1 authorization groups to BC permission sets and user groups |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Customers | medium | Customers must be split out of the unified OCRD Business Partner table and mapped to BC's dedicated Customer table, requiring careful handling of shared fields, credit limits, and contact associations. |
| Vendors | medium | Vendors share the same OCRD source table as customers, so extraction logic must correctly filter by CardType and remap tax groups to BC's VAT posting group structure. |
| Items and Inventory | high | B1's OITM item master combined with OITW warehouse-level data must be mapped to BC Items and Stockkeeping Units (SKUs), with careful reconciliation of on-hand quantities, serial numbers, and batch allocations at cutover. |
| Sales Orders | medium | Open sales orders from ORDR/RDR1 must be migrated with correct header-line relationships, and extracting active open documents via raw SQL risks orphaned records that fail BC's posting validation. |
| Purchase Orders | medium | B1 purchase orders require remapping of tax groups to BC VAT posting groups and careful translation of line-level warehouse and item references. |
| Journal Entries and G/L History | high | Migrating OJDT/JDT1 journal entries requires a complete chart of accounts remapping from B1's segmented structure to BC's G/L accounts with dimensions, and historical balances must be reconciled to the penny. |
| A/R and A/P Invoices | medium | Historical invoices from OINV/INV1 must be imported as posted entries in BC, and any open or partially applied invoices require precise payment application matching. |
| User-Defined Fields | high | Each UDF from B1's CUFD metadata must be individually assessed and recreated as BC table extensions or dimensions, with no automated translation available between the two schema models. |
| Crystal Reports and Custom Queries | high | All Crystal Reports and stored procedures must be completely rebuilt in Power BI or RDLC report layouts, as no migration tooling exists to convert them automatically. |
| Multi-Currency Transactions | medium | B1's deep multi-currency and localization handling, particularly for intercompany transactions across regulatory jurisdictions, may not map one-to-one to BC's currency and localization framework. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Business Partner Table Splitting
SAP B1 stores customers, vendors, and leads in a single OCRD master table, which must be decomposed into separate Customer, Vendor, and Contact records in Business Central.
Database-Dependent Extraction Logic
Extraction approaches differ significantly between SQL Server (T-SQL direct queries) and HANA (HANA SQL via ODBC, Service Layer, or HANA Studio), requiring separate scripting and syntax adaptation for each database platform.
Add-On and Customization Replacement
SAP B1 add-ons such as Beas, Produmex, and Boyum solutions built on the DI API/SDK have no direct equivalents and must be replaced with AL extensions or AppSource marketplace apps in Business Central.
User-Defined Field Translation
B1's User-Defined Fields stored in CUFD/UFD1 metadata tables must be individually mapped to Business Central table extensions or dimensions, as there is no automatic schema translation between the two systems.
Chart of Accounts Restructuring
B1's segmented chart of accounts structure must be remapped to Business Central's G/L account numbers combined with its dimensional accounting model, requiring a full financial data reconciliation strategy.
Crystal Reports to Power BI
Deeply embedded Crystal Reports used across SAP B1 operations must be completely rebuilt as Power BI reports or Excel integrations, since Business Central has no Crystal Reports compatibility.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Will my SAP B1 add-ons like Boyum, Beas, or Produmex work in Business Central?
No. Boyum, Beas, and Produmex are SAP Business One products built on B1's SDK. They do not port to Business Central. Each add-on requires a functional replacement — typically native BC features, AL extensions, or an AppSource app. The data created by these add-ons also needs custom extraction and either migration to BC custom tables or archiving.
How does Business Central handle SAP B1's Business Partners?
SAP B1 groups customers, vendors, and leads into a single Business Partner table. Business Central strictly separates these into distinct Customer and Vendor tables with different posting groups. If one entity is both a customer and vendor in B1, you must split and link the records during migration using BC's contact management features.
How long does an SAP B1 to Business Central migration take?
Expect 3–6 months for a typical SMB. This includes discovery and mapping (3 weeks), BC configuration (4–8 weeks), data extraction and test migrations (6–10 weeks), and cutover with UAT (2–4 weeks). Companies that attempt 8-week timelines almost always encounter mapping errors, untested add-on data, and insufficient validation.
Can I keep my Crystal Reports after migrating to Business Central?
Crystal Reports do not run in Business Central. BC uses RDLC-based report layouts and Power BI for analytics. Your Crystal Reports logic (queries, groupings, calculations) can be recreated in BC's report designer or Power BI, but this is a manual rebuild — not an automated conversion. Budget for report recreation in your project scope.
What usually drives SAP B1 to Business Central migration cost?
The main cost drivers are not just licenses. BC pricing is transparent, but total project cost is shaped by add-on replacement, years of history migrated, UDF redesign, report rebuilds, and reconciliation/testing effort. Data migration alone (extraction, transformation, loading, and validation) typically runs $15,000–$50,000 depending on database size, add-on count, and UDF complexity.