Switching from Sage 100 to Microsoft Dynamics 365 Business Central

Sage 100 has served DACH mid-market for over two decades, particularly strong in trade, distribution and discrete manufacturing. As organisations evolve their IT strategy toward cloud-first architectures or seek tighter integration with Microsoft 365, migration to Microsoft Dynamics 365 Business Central becomes a common path. The switch is neither trivial nor disruptive: Business Central is a natural functional peer of Sage 100 at a similar mid-market tier.

Common migration drivers

Three primary drivers. (1) Cloud strategy: Sage 100 is largely on-premises; Business Central is cloud-native with strong SaaS economics. Organisations adopting cloud-first IT favour Business Central. (2) Microsoft 365 integration: Business Central's tight integration with Microsoft 365 (Outlook, Excel, Teams, SharePoint, Power Platform) delivers productivity benefits hard to match on Sage 100. (3) Partner ecosystem and roadmap: Microsoft's investment in Dynamics 365 is substantial; the partner network and ISV ecosystem grow rapidly. When not yet: stable Sage 100 operations meeting business needs; significant existing customisation tied to Sage; no transformation pressure. Mid-market organisations should evaluate the case carefully rather than switching just for cloud fashion.

Key functional differences

The two products are conceptually similar but operationally different. UX: Sage 100 is Windows-desktop-style; Business Central is web-based with mobile app. Architecture: Sage 100 is database-centric with rich client logic; Business Central is cloud-native with API-first extensibility. Customisation: Sage 100 customised via Sage's SDK and partner add-ons; Business Central via AL extensions and Microsoft Power Platform. Pricing: Sage 100 perpetual licence with maintenance; Business Central subscription per user per month. Strength areas: Sage 100 has mature DACH-specific configurations for trade and manufacturing; Business Central is broader-spectrum with the Microsoft ecosystem advantage. Functional parity is broad; the differentiation lives more in architecture and ecosystem.

Migration methodology

Typical Sage-100-to-Business-Central project. (1) Scope and process design: map current Sage 100 processes; identify Business Central standard versus customisation needs. (2) Chart-of-accounts redesign: import or rebuild in SKR 03 or SKR 04 within Business Central. (3) Master-data migration: customers, suppliers, materials, BOMs from Sage 100 via export-import. (4) Open-transaction migration: open AP, AR, inventory, POs at cutover. (5) Custom logic re-platforming: Sage-specific customisations rebuilt in AL extensions or Power Platform. (6) Integration redesign: Sage 100 integrations re-implemented through Business Central's API or via iPaaS. Implementation duration: 9-15 months typical for mid-market 50-150 user operations. Cost: 300,000-1,500,000 EUR depending on complexity and customisation carryover.

Practical considerations

Three patterns. (1) Re-evaluate customisation: the migration is an opportunity to reduce customisation burden. Question every Sage-side customisation: is the business value still material? Can the requirement be met through configuration in Business Central? Less customisation produces a cleaner long-term operation. (2) Engage works council early: German operations face works-council co-determination rights on systems affecting employees. Early engagement and proper Betriebsvereinbarungen prevent delays. (3) Choose the right partner: Sage 100 partners and Business Central partners are different ecosystems; pick a Business Central-experienced partner with proven Sage-to-BC migration track record. References from completed migrations matter substantially.

Häufig gestellte Fragen

How long does migrating from Sage 100 to Microsoft Dynamics 365 Business Central take and what does it cost?

For typical mid-market projects, experience shows a project duration of roughly five to nine months, depending on company size, process complexity and the number of interfaces. Small migrations with 10 to 50 users often fall into the low six-figure range, while medium-sized projects with more than 150 employees can reach seven figures depending on customising. On top of that come ongoing licence costs, which with a larger number of users quickly become the main annual cost block. Reliable figures only emerge after a structured needs analysis and several partner quotes.

Should Business Central be run as cloud SaaS or on-premises?

The cloud variant (SaaS) is the standard route today, as Microsoft delivers Business Central as true Software-as-a-Service with two major feature updates per year, making the integration with Microsoft 365, Teams, Azure and Power BI easiest to use. An on-premises or private-cloud installation is mainly worth considering for very specific requirements, such as strict data residency or industry regulations. Since Sage 100 is traditionally on-premises-oriented and usually adds cloud operation as hosting rather than as true multi-tenant SaaS, the move to SaaS is often a key strategic driver. The right choice ultimately depends on company size, IT roadmap and the regulatory environment.

Which data can be transferred from Sage 100 and what happens to the posting history?

Master data such as articles, customers, suppliers, accounts and cost centres can in principle be migrated completely, as can open items, open sales orders, purchase orders and stock levels, which can be imported using Microsoft tools such as Configuration Packages (RapidStart). The complete historical posting history, by contrast, is usually not transferred one-to-one, since Configuration Packages are primarily intended for the initial setup of a company. In practice, it has proven effective to migrate only open items as of the cutoff date plus around one to two years of posting history and to keep Sage 100 running as a read-only archive. Sage 100-specific fields and condition logic have to be deliberately mapped onto BC structures in the process.

Does the DATEV integration in Business Central work the same way as in Sage 100?

Sage 100 comes with its own DATEV interface, and Business Central is also productively connected to DATEV in the DACH market — though not natively out of the standard, but via established ISV connectors such as the Continia DATEV connector or comparable partner solutions. The integration is considered robust and widely used in the mid-market, so the switch is technically usually easier than initially feared. What matters is clarifying the specific workflow details with the tax advisor early on, for example regarding posting key logic and export formats. Since Sage 100 users often maintain closely coordinated tax advisor processes, these should be fully documented in the discover phase.

What happens to individual customisations and custom reports from Sage 100?

In practice, Sage 100 is often extended with individual reports and smaller workflow customisations that cannot be transferred automatically. In Business Central, such extensions have to be re-implemented either through suitable add-ons from Microsoft AppSource or through custom AL extensions. Custom reports, which in the German Sage 100 were frequently created with the integrated report generator List & Label, are rebuilt in BC with Word layouts, Power BI or Jet Reports. A complete inventory of all customisations and interfaces in the first project phase is therefore crucial for realistically assessing effort and risks.

Which industry add-ons from Microsoft AppSource are relevant for the DACH mid-market?

Business Central relies heavily on an ecosystem of extensions that comprises well over a thousand apps on Microsoft AppSource, making it considerably broader than the smaller, German-focused Sage 100 marketplace. In the DACH mid-market, widely used options include KUMAVISION for industrial and healthcare scenarios, Continia for banking and document capture, and Sana Commerce for B2B e-commerce. Selecting suitable add-ons belongs in the configuration phase and should be guided strictly by actual functional needs, not by mere availability. Which extensions make sense depends on industry, processes and existing third-party systems and is part of drawing up the individual requirements specification.