SAP Business One to Business Central: The 2026 Migration Guide

Migrating from SAP Business One to Microsoft Dynamics 365 Business Central is a structural data translation problem, not a lift-and-shift. You are moving from a monolithic, traditionally on-premise architecture into a cloud-native SaaS platform with different extension, reporting, and workflow patterns. If you attempt to push SAP tables directly into Business Central using standard export tools, the migration will fail.

The work is mostly about extraction, mapping, replacement, and reconciliation. This guide covers the technical realities of extracting data from SQL Server or HANA, specific object mapping strategies, what happens to your SAP B1 add-ons, what it actually costs, and how long it takes.

For related ERP migration guidance, see Dynamics GP to Business Central: Migrating 20 Years of History and 7 Costly Mistakes to Avoid When Migrating Financial Data.

Why SMBs Are Leaving SAP Business One in 2026

The decision to leave SAP Business One is rarely driven by a single missing feature. Three forces are pushing B1 customers toward Business Central right now.

The HANA migration tax. If you are on SQL Server today, SAP's strategic direction points at HANA. But migrating B1 from SQL to HANA is not a simple database swap — it is a project in itself. Custom queries must be rewritten from T-SQL to HANA SQLScript (case sensitivity alone breaks most existing queries). Add-ons must be recompiled or replaced. HANA requires certified hardware or a cloud hosting contract. The database migration itself may take only hours, but the full project — test migration, customization adjustments, and key-user testing — runs 2 to 10 weeks depending on complexity. For many SMBs, the cost and timeline of this upgrade force a re-evaluation of the entire ERP strategy. (support.sap.com)

S/4HANA is not a viable SMB path. SAP's flagship cloud ERP, S/4HANA, is engineered for large enterprises. The entry cost for S/4HANA implementations typically starts around $5 million, compared to roughly $100,000 for B1. It is not an upgrade path for a $20M distribution company.

The thinning SMB partner ecosystem. SAP reports 850+ partners globally, but the number actively investing in B1 SMB practices has visibly contracted in many markets. Many are shifting focus toward enterprise S/4HANA deployments, leaving B1 customers with reduced support SLAs and fewer resources. When your partner goes quiet, you are left managing an on-premise ERP with custom Crystal Reports, stored procedures, and add-on dependencies — and no one to call.

The pull from Microsoft is real: native integration with Microsoft 365, Power BI, Power Automate, Teams, Copilot, and an AppSource marketplace with thousands of industry extensions. For companies already paying for Microsoft 365 licenses, the operational gravity is hard to ignore. (learn.microsoft.com)

Functional Comparison: SAP B1 vs. Dynamics 365 Business Central

Both platforms target SMBs in distribution and light manufacturing. The differences are architectural and strategic, not just feature-list.

Where SAP B1 Is Stronger

B1 has genuinely deep multi-currency and localization capabilities, especially for companies operating across regulatory jurisdictions in LATAM, APAC, or EMEA. Its financial core — particularly around intercompany transactions in specific country localizations — can be more mature than BC's out-of-the-box handling. B1's unified Business Partner concept (customers, vendors, and leads managed in a single master table) simplifies certain types of reporting. And its Crystal Reports are deeply embedded in many companies' operations.

Be fair to B1: if you run deep manufacturing or warehouse processes through Boyum, Beas, or Produmex, and your partner is strong, staying on B1 can still be the right answer. Business Central is not automatically stronger in every specialty workflow out of the box. (boyum-solutions.com)

Where Business Central Is Stronger

Business Central's practical advantage is that it behaves like part of the Microsoft stack. Users work through Excel and Outlook, share records in Teams, connect workflows through Power Automate, and sync data through Dataverse.

• Cloud-native extensions: Instead of modifying core code (which breaks upgrades), BC uses AL extensions. Customizations live outside the base application, ensuring updates apply automatically.
• Microsoft 365 integration: BC natively embeds into Outlook, Teams, and Excel. You can generate and send a sales quote directly from an Outlook email without switching applications.
• Dimensional accounting: Instead of rigid, segmented chart of accounts structures, BC uses dimensions (tags) to slice financial data dynamically.
• AppSource marketplace: Thousands of vetted, plug-and-play extensions replace the need for heavy, custom-coded add-ons.
• Copilot: Embedded AI assistance for chat, list analysis, and forecasting inside BC.

There is a trade-off CFOs should hear plainly: BC manufacturing and warehousing can be very good, but complex plants and warehouses often still rely on ISV apps and extensions. The real-world comparison is usually B1 plus Boyum/Beas/Produmex versus BC Premium plus AppSource apps and targeted custom extensions — not base versus base.

The Data Extraction Challenge: SQL Server vs. HANA

Getting data out of SAP Business One is the first technical gate. The approach depends entirely on your underlying database.

B1 on SQL Server

For SQL Server-based B1, direct SQL queries against the database are the preferred extraction method for bulk read operations. You have full read access to the underlying tables: OCRD (business partners), OITM (items), ORDR (sales orders), OPOR (purchase orders), OJDT (journal entries), and all associated line-item tables.

-- Extract all active customers with UDFs
SELECT T0.CardCode, T0.CardName, T0.CreditLine,
       T0.U_CustomField1, T0.U_Region
FROM OCRD T0
WHERE T0.CardType = 'C' AND T0.validFor = 'Y'

B1's database schema is cryptic — table names like OINV for A/R Invoices, ORDR for Sales Orders. Your extraction scripts must correctly join header tables with their respective line tables (INV1, RDR1) while maintaining primary and foreign key relationships.

SAP's own documentation acknowledges that the database can be read via SQL — writes must go through the DI API or Service Layer to maintain data integrity. (help.sap.com)

B1 on HANA

For HANA-based B1, you have three options:

1. HANA ODBC driver — Connect via the HDBODBC32 driver for direct queries using HANA SQL syntax.
2. Service Layer SQL API — Available since B1 10.0 FP 2011, this REST API executes SQL queries against the HANA database via HTTP. Since FP 2102 it supports user-defined tables, and as of FP 2405, OData v4 is the primary protocol API teams should expect.
3. HANA Studio — For complex extraction jobs, HANA Studio provides a SQL console for running queries, exporting result sets, and inspecting schema objects.

DI API and Service Layer for Complex Objects

For transactional documents with complex nested structures (sales orders with line items, serial numbers, batch allocations), the Service Layer or DI API gives you objects that respect B1's business logic. This is especially important for marketing documents where header-level and line-level data are interleaved across multiple tables.

The DI API is COM-based and slower for bulk operations. It also has strict concurrency limits that make it impractical when extracting millions of rows of historical data. The Service Layer (REST/JSON) is the modern alternative and works on both SQL Server and HANA as of version 10.0. (help.sap.com)

In practice: SQL is best for bulk extraction, DI API is useful when business object logic matters, and Service Layer fits API-first pipelines.

The safe pattern is repeatable extraction scripts for master data, open documents, inventory balances, journal history, UDFs, attachments, and add-on tables, followed by one or more delta loads near cutover. One-off manual exports are fine for discovery. They are not a migration plan.

Object-by-Object Data Mapping: B1 → Business Central

This is where most migration projects get into trouble. B1 and BC use fundamentally different data models.

Business Partners → Customers and Vendors

In SAP B1, a Business Partner represents a customer, vendor, or lead, distinguished only by a type flag. Business Central strictly separates Customers and Vendors into different tables with distinct posting groups. If a single entity acts as both a customer and a vendor in B1, you must split the record into two entities in BC and link them using BC's native contact management.

The job is not just field mapping — it is deduping shared identities, contacts, tax IDs, payment terms, and cross-references so one real business does not become multiple weakly linked records after go-live. (help.sap.com)

Items and Inventory

Item masters are usually the easy part. Basic fields (Item No., Description, Base Unit of Measure) map cleanly. The hard part is location design, bin behavior, serial/lot tracking, replenishment, and costing. If you use moving average in B1, you must map this to the equivalent costing method in BC, ensuring that historical inventory adjustments align with BC's item ledger entries. Redesign around BC's location and warehouse structure rather than copying B1 form fields one-to-one. (learn.microsoft.com)

Marketing Documents → Sales and Purchase Documents

SAP B1 groups quotes, orders, deliveries, and invoices under "Marketing Documents." Business Central splits these into distinct functional areas: Sales Header/Line and Purchase Header/Line.

When mapping open orders, translate B1's document status flags into BC's release and posting statuses. Only migrate open documents (open orders, open invoices) as active records. Historical, closed documents should be migrated as posted ledgers or archived into a data lake for reporting. BC configuration packages can import some transaction tables from spreadsheets, and BC APIs support create/update patterns for documents, but full historical migration usually needs custom routines plus strict reconciliation.

For guidance on deciding what to migrate versus archive, see What Data Should You Actually Migrate to Your New ERP?.

Journal Entries → General Ledger Entries

B1 stores manual journal entries and system-generated financial postings in the OJDT (header) and JDT1 (lines) tables. BC uses the G/L Entry table and requires strict adherence to Posting Groups (Customer, Vendor, Inventory, and General). You cannot push debits and credits directly into BC — the data must flow through general journals and be validated against BC's posting setup to ensure the subledgers match the general ledger.

Preserve posting dates, document numbers, source references, and currencies. BC's dimension model is designed for analytical tagging, and it is usually cleaner to map B1 reporting tags into dimensions than to keep expanding the chart of accounts. This is the part teams most often underestimate. (learn.microsoft.com)

User-Defined Fields → Extensions or Dimensions

Most B1 installations have dozens of UDFs scattered across business partner, item, and document tables. In BC, you have two options:

1. Table Extensions (via AL code): Best for fields that need to appear on documents and drive business logic.
2. Dimensions: Best for analytical/reporting fields that slice GL entries (e.g., "Sales Region" or "Customer Tier"). This keeps the core database clean and leverages BC's native analytical power.

That distinction matters. Put analytical tags into extensions and reporting becomes harder than it needs to be. Put operational attributes into dimensions and users will hate maintenance. The choice affects your entire BC configuration and reporting structure — get this mapping wrong and you will spend months fixing reports post-go-live. (help.sap.com)

Handling Legacy SAP Add-Ons: Boyum, Beas, and Produmex

Most SAP Business One environments run 2–4 industry add-ons that are deeply embedded in daily operations. Common ones include Boyum B1 Usability Package (workflow automation, UI customization), Beas Manufacturing (production planning, shop floor control), and Produmex (warehouse management with barcode scanning). These add-ons extend B1 at the database and UI level.

None of them port to Business Central. They are SAP-specific, built on B1's SDK, and have no BC equivalent from the same vendor. (boyum-solutions.com)

Your migration project must include a functional replacement analysis for each add-on:

• Beas / Produmex manufacturing → BC Premium license includes native manufacturing (production orders, capacity planning, BOMs). For deeper needs, AppSource apps like Insight Works or NETRONIC extend BC's manufacturing capabilities.
• Boyum B1UP → BC's extension model and Power Automate handle most workflow customization natively. BC's built-in personalization features cover common UI customization needs.
• Barcode/WMS add-ons → BC supports bin management, directed put-away and pick, and zone-based warehouse management natively. Warehouse Insight (by Insight Works) is the most common AppSource extension for advanced WMS.

3-Year TCO: SAP B1 vs. Business Central

Business Central pricing is unusually transparent. Microsoft lists BC Essentials at $80/user/month, Premium at $110/user/month, and Team Members at $8/user/month, paid yearly, with Copilot included. (microsoft.com)

SAP B1 pricing is far less transparent. Current market references put B1 cloud at roughly $95–$250/user/month, or $3,213–$5,500 per named user for perpetual licenses plus 18–20% annual maintenance. (erpresearch.com)

A useful budget frame for a 15-user SMB:

• BC standard mix (5 Premium + 5 Essentials + 5 Team Members): roughly $35,640 over three years in software before AppSource apps. (microsoft.com)
• BC manufacturing-heavy mix (10 Premium + 5 Team Members): roughly $41,040 over three years in software before AppSource apps.

For a fuller picture including services and infrastructure, here are directional ranges for a 15-user distribution or light manufacturing company:

The cost advantage of BC grows when you factor in infrastructure elimination. SAP B1 on-premise deployments carry hidden costs — server hardware, OS patching, SQL Server licensing, backup infrastructure, and IT staff or MSP fees to manage it all. BC's subscription includes hosting, updates, and security.

If you are considering a HANA migration instead, add $15K–$50K for the database migration project (hardware, consulting, query conversion), plus ongoing HANA hosting costs that typically exceed SQL Server.

The bigger line items are around the ERP, not the ERP itself: on-prem infrastructure, database administration, add-on contracts, partner support, report rebuilds, and the volume of historical data you insist on moving. In many SMB projects, software is the smallest hard problem. Add-on replacement and data quality are the bigger ones. (cetastech.com)

Timeline: Why 8-Week Migrations Fail

A realistic SAP B1-to-Business Central migration for an SMB runs 3–6 months. Companies often push for an 8-week timeline, treating it like a software installation. This fails.

Here is what a realistic timeline looks like for a $5M–$100M company:

• 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.

The bottleneck is almost never the data load into BC. It is the mapping decisions (especially UDFs and add-on data), the chart of accounts restructuring, and the user acceptance testing. Companies that skip test migrations discover mapping errors in production. That costs far more than an extra month of planning.

How ClonePartner Handles B1 Data Extraction and Migration

We have built extraction frameworks for both SQL Server and HANA-based B1 environments. Our approach:

1. 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.
2. 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.
3. 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.
4. Iterative validation — Multiple test migrations with reconciliation reports before cutover. We do not go live on a feeling.

Our migration work runs in parallel with your BC implementation partner's configuration. The implementation team focuses on getting Business Central right. We focus on getting the data right — especially when legacy add-ons, UDFs, and historical reporting make standard import tools too shallow. You get a clean, validated data set loaded into a fully configured BC environment, without either workstream blocking the other.