Migrating from NetSuite to Business Central

Moving from NetSuite to Business Central — the data and customisation challenges, the cost angle, and what to expect from the project.

Updated 2026-03-15

NetSuite-to-Business-Central migrations are not as common as QuickBooks or SAP B1 migrations, but they do happen — typically driven by cost (NetSuite per-user pricing scales aggressively), by Microsoft 365 integration preferences, or by partner ecosystem in specific countries. The migration is doable but not trivial; both products are real ERPs and the data and customisation footprints are usually substantial.

Why customers consider it. Common triggers:

  • Total cost of ownership. NetSuite list pricing tends to escalate as user count and module footprint grow. Business Central licence costs are usually meaningfully lower for the same headcount.
  • Microsoft 365 alignment. Customers heavily invested in Microsoft 365 (Teams, SharePoint, Power BI) often find BC's tighter integration more productive than NetSuite's connectors.
  • Partner ecosystem. In some markets (DACH, Nordics, parts of Asia), the Microsoft partner base is broader and more accessible than the NetSuite consulting base.

Why customers stay on NetSuite. Equally common: deep customisation already in place, industry-specific NetSuite modules (SuiteCommerce, advanced revenue management) without direct BC equivalents, or established global multi-entity consolidations.

Data migration. NetSuite exports cleanly via its SuiteAnalytics API or Saved Searches exports. Standard approach:

  1. Inventory the NetSuite data model — standard objects, custom records, custom fields.
  2. Map to BC equivalents — chart of accounts, dimensions (NetSuite classes, departments, locations map to BC dimensions), items, customers, vendors.
  3. Pull data via the API, transform with Azure Data Factory or Power Query, load to BC via Configuration Packages or REST API.

Open transactions, balances, and the master data migrate; historical detail typically stays in NetSuite read-only.

Customisation. NetSuite customisations live in SuiteScript (JavaScript), SuiteFlow, and SuiteBuilder. None of this ports directly. The rebuild path:

  • Standard fields and forms → BC's table extensions and page extensions in AL.
  • SuiteFlow workflows → BC's built-in workflows or Power Automate flows.
  • SuiteScript business logic → AL codeunits with event subscribers.
  • SuiteAnalytics reports → Power BI.
  • SuiteCommerce e-commerce → typically Shopify, Sana, or a custom Power Pages + headless front end.

Many customisations turn out to be workarounds for NetSuite features BC implements differently — re-do the fit-gap honestly before committing to rebuild.

Multi-entity and consolidations. NetSuite OneWorld is strong at multi-subsidiary consolidations. BC's multi-company is real but less feature-rich. Customers running 20+ legal entities with complex consolidations should evaluate whether Dynamics 365 Finance is the right step rather than BC. For 5–15 entities with moderate complexity, BC is usually sufficient.

Integration rebuild. NetSuite's connector library is wide; BC's is wide too but the specific connectors differ. Audit every NetSuite integration and budget the rebuild.

Time to live. Substantial. Typical NetSuite-to-BC migrations are 6 to 18 months for a mid-sized customer, dominated by configuration, customisation rebuild, and parallel running.

Related guides