Switching from SAP Business One to Microsoft Dynamics 365 Business Central

SAP Business One and Microsoft Dynamics 365 Business Central are direct competitors in the mid-market ERP segment. Organisations switching between them typically do so for strategic reasons rather than functional gaps: ecosystem alignment, partner-relationship changes or specific feature preferences. For DACH mid-market in particular, the choice increasingly favours Business Central due to broader Microsoft 365 integration and a wider partner network. This guide covers the migration considerations specific to this switch.

Common migration drivers

Five drivers commonly push the switch. (1) Microsoft 365 alignment: organisations standardising on Microsoft 365 benefit from Business Central's native integration with Outlook, Excel, Teams, SharePoint and Power Platform. SAP Business One lacks comparable integration. (2) Partner-network breadth: Business Central has roughly 3-5x as many DACH implementation partners as SAP Business One. Partner choice and switching is easier. (3) Power Platform extensibility: Business Central's low-code extensibility via Microsoft Power Platform exceeds Business One's SDK-and-add-on model for most use cases. (4) Cloud-first roadmap: Business Central is cloud-native by design; Business One has been moving to cloud (BTP) but with mixed maturity. (5) Cost competitiveness: Business Central's Essentials tier offers attractive per-user pricing; SAP Business One pricing has been less competitive for DACH SMB customers in recent years. When the switch is not justified: stable Business One operations with deep SAP-side integration (SuccessFactors, Ariba, Concur), strong existing SAP partner relationship, no transformation pressure.

Migration effort and approach

The migration from Business One to Business Central is conceptually straightforward but operationally meaningful. Both products serve the mid-market with similar functional scope; the conceptual mapping is close. Standard approach. (1) Vendor and partner selection: evaluate Business Central partners independently of any Business One partner relationship. Different ecosystems. (2) Process mapping: Business One process patterns mapped to Business Central standard. Minor configuration differences accepted; significant changes deferred for the implementation phase. (3) Chart-of-accounts redesign: import from Business One or rebuild in SKR 03 / SKR 04 within Business Central. (4) Master-data export-and-cleanse: customers, suppliers, materials from Business One via DI API or database export. (5) Open-transaction migration: open AP, AR, inventory, POs at cutover. (6) Custom-logic re-platforming: Business One SDK extensions rebuilt in Business Central AL extensions or Power Platform. Implementation duration: 6-12 months typical for mid-market 30-150 user operations. Cost: 200,000-1,000,000 EUR depending on complexity and customisation.

Key functional differences

The two products are largely peer-equivalent with specific differentiation. SAP Business One strengths: tight integration with SAP-side products (Concur, SuccessFactors when applicable), mature German tax-compliance, established add-on ecosystem from partners like beas Manufacturing for production. Business Central strengths: Microsoft 365 integration depth, Power Platform extensibility, broader ISV ecosystem (apps.microsoft.com Business Central marketplace), faster modern UX evolution. Functional parity areas: core financials, AP, AR, inventory, basic manufacturing, sales-and-distribution — both products cover broadly equivalent scope. Where Business Central is materially better: low-code extensibility, modern UX, Microsoft 365 integration, cloud-native architecture. Where Business One is materially better: specific industry-add-on scenarios where the SAP B1 partner has built deep capability not yet matched on Business Central.

Practical considerations

Three patterns for successful Business One to Business Central migrations. (1) Treat as opportunity for process improvement: don't just replicate Business One processes; use the migration to adopt Business Central best-practices where appropriate. (2) Plan for ecosystem switch: partners, tools, training, support relationships all change. The ecosystem switch is often larger than the technical migration. Plan and budget the ecosystem transition. (3) Manage user-experience change: users familiar with Business One face meaningful UX differences in Business Central. Training and communication matter substantially for adoption.

Integration architecture during transition

Many organisations operate Business One alongside other systems — CRM (Salesforce, HubSpot), e-commerce (Shopware, Shopify, Magento), specialised manufacturing (beas Manufacturing add-on), payroll (DATEV Lohn). The migration must address each integration explicitly. (1) Re-implementation on Business Central's API platform: Business Central exposes REST APIs and OData services natively; most integrations can be re-platformed. (2) Vendor-provided connectors: established Business Central ISV connectors (Salesforce, Shopify, Microsoft Teams) cover many common scenarios out-of-the-box. (3) iPaaS approach: organisations with complex integration landscapes benefit from iPaaS platforms (Microsoft Power Automate premium, Boomi, Workato) for cross-system orchestration. Plan for 3-6 months of integration work as part of the migration scope; underestimating integration cost is a persistent project-failure pattern.

Add-on-ecosystem differences

Business One has a mature partner-built add-on ecosystem with industry-specific extensions (beas Manufacturing for production, Boyum IT for industry verticals, COSMO CONSULT specifics, citixsys for retail). When switching to Business Central, these add-ons rarely transfer directly; equivalent Business Central ISV apps must be evaluated. Business Central app ecosystem: Microsoft AppSource marketplace hosts hundreds of Business Central apps from partners worldwide. Major categories: industry verticals (manufacturing, distribution, services, retail), functional extensions (advanced AP, expense management, document management), localisation (German, Swiss, Austrian compliance). DACH-focused ISVs: To-Increase, Cosmo Consult, Hougaard.com, Sycor, Anveo. Evaluation discipline: for each Business One add-on currently in use, identify Business Central ISV equivalent or rebuild as custom AL extension. Decide whether the capability still earns its cost.

Typical project timeline and milestones

For a typical 30-150 user Business One to Business Central migration, the project timeline runs 6-12 months with the following milestones. Month 1-2: vendor selection, partner selection, project kick-off, initial process workshops. Month 3-4: fit-to-standard analysis, customisation specification, data-migration mapping, integration design. Month 5-7: build phase — system configuration, AL extension development, data-migration scripts, integration build, initial testing. Month 8-9: user acceptance testing, training delivery, dress rehearsals for cutover. Month 10: cutover weekend plus hyper-care launch. Month 11-12: stabilisation, second-wave training, issue resolution, transition from project to operations. Cost distribution: roughly 60% in build-and-test phases, 25% in design phase, 15% in stabilisation. Time allocation: business-team key users at 30-50% during build, full-time during cutover.

Long-term roadmap considerations

Beyond the migration project, three long-term roadmap considerations shape the value of moving to Business Central. (1) Microsoft Power Platform extensibility: low-code Power Apps and Power Automate extend Business Central without code, enabling business-user-driven innovation. SAP Business One's comparable capabilities are less mature. (2) AI integration via Microsoft Copilot: Microsoft Copilot for Dynamics 365 increasingly augments Business Central with conversational AI, document understanding and intelligent automation — investments Microsoft is making aggressively. (3) Cross-product Microsoft 365 synergies: deep integration with Outlook, Teams, SharePoint and Power BI delivers operational productivity that compounds over years. These roadmap factors often justify the migration premium beyond the immediate functional comparison.

Häufig gestellte Fragen

How long does a typical migration from SAP Business One to Dynamics 365 Business Central take?

For mid-sized setups without extreme industry specialisation, 6 to 9 months from initial assessment to stabilised go-live is a realistic range. Very small installations with few add-ons and clean master data can be completed in 4 to 7 months, while multi-country rollouts or setups with many industry add-ons can take 12 to 18 months. The biggest time factor is rarely the pure technology, but rather data cleansing, mapping between different data models and user training. An honest fit-gap analysis at the start of the project prevents late-discovered functional gaps from blowing up the schedule.

What does Dynamics 365 Business Central cost per user compared with SAP Business One?

In the cloud variant, Business Central is licensed per named user; Microsoft raised list prices as of 1 November 2025 for the first time in years, putting Essentials and Premium in the US at around 80 and 110 US dollars per user per month respectively, supplemented by inexpensive Team Member licences from about 8 US dollars for read-only and light data-entry roles. With SAP Business One, Professional full users in the cloud are usually above this level, while restricted Limited licences can be comparable or cheaper, and on-premise models are additionally billed via annual maintenance. Viewed over several years, the total cost calculation often works out in favour of BC, especially with growing user numbers and in a Microsoft 365 environment. Actual terms, however, depend heavily on licence type, negotiation position, region and add-on needs, which is why a reliable TCO comparison is only possible with concrete quotes.

Can we carry over our historical transaction data from SAP Business One to Business Central?

In practice, usually only open items are carried over at the cutover date — open sales orders, purchase orders, receivables and payables open items, and inventory balances — which can be loaded easily with BC's standard tools such as Configuration Packages and the Data Migration Tool. Migrating complete historical transaction data 1:1 is technically complex and expensive, because B1 and BC have different data models and no direct mapping paths exist. It is usually more pragmatic to keep the old system running as a read-only archive for two to three years or to offload the history to an Azure Data Lake for reporting. Which variant fits should be determined early in the project based on compliance and statutory retention obligations as well as reporting needs.

Does the end of maintenance for SAP Business One mean the product is being discontinued?

No — the end of mainstream maintenance applies to a specific version, not the product as a whole; for SAP Business One release 10.0, mainstream maintenance ends on 31 December 2026, and SAP does not offer an extended-maintenance phase for Business One. SAP continues to develop the product and provides new versions with subsequent releases, so B1 continues to be maintained in principle. A maintenance deadline therefore does not force an immediate end, but it can be a good occasion to fundamentally review your strategic ERP direction. If you are considering a switch anyway, the version upgrades that would otherwise be due should be factored into that trade-off.

Can custom developments and add-ons from SAP Business One be transferred directly to Business Central?

A direct transfer is not possible, because B1 extensions are typically built with the SAP Business One SDK and the DI API in languages such as C# or VB.NET, while BC extensions are written in the AL language. Every custom development and every add-on must therefore be functionally redesigned — either via BC standard functionality, a suitable app from Microsoft AppSource or a custom AL extension. The data generated by the add-ons also needs its own extraction and migration strategy, for example into custom BC tables or into the archive. If you depend heavily on highly specialised industry add-ons, check thoroughly before deciding whether an equivalent BC counterpart exists at all.

Should we carry out the switch as a big bang or step by step (phased)?

With the big-bang approach, all modules go live together on a single date, which avoids double entries and data consistency problems between two systems running in parallel and is often practicable for a manageable single-system switch from B1 to BC. A phased, module-by-module transition, on the other hand, reduces risk and gives users more time to adjust, which is why it is attractive above all in larger, distributed or production-critical organisations; which variant fits better depends on complexity, site structure and risk appetite. In both cases the choice of cutover date is decisive: peak season and closing months — such as the fourth quarter in retail or the quarter-end close in manufacturing — should be avoided. Either way, a hypercare phase of several weeks with increased support and a firmly planned budget is recommended after go-live, rather than treating the project as finished right after the cutover date.