NetSuite to Dynamics 365

NetSuite to Dynamics 365 Isn't One Migration — It's Two

Dynamics 365 isn't a single target. Microsoft splits it into Business Central, aimed at small and mid-sized businesses with lower licensing cost and an implementation measured in weeks to a few months, and Finance & Operations (also sold as Supply Chain Management), aimed at large, complex organizations with enterprise-tier licensing and implementation timelines running several months to a year or more. Which one a given NetSuite customer lands on isn't a preference question, it's a scoping question, and it changes almost everything downstream: Business Central's multi-company support is described by Microsoft's own partners as handling straightforward multi-entity needs, while Finance & Operations is built for genuine multi-company, multi-country, multi-currency operations with deeper compliance and audit controls.

A genuine migration, in either direction, includes master data (customers, vendors, items, chart of accounts), structural remapping of subsidiaries into whichever entity model the target uses, open transactions and balances, every integration currently pointed at NetSuite, and a reconciliation process auditors will actually check. It does not include a plain NetSuite module addition, a Dynamics-to-Dynamics product change with no NetSuite source, or a CRM-only handoff to Dynamics 365 Sales, each of which is a narrower problem with its own tooling.

Why Companies Actually Make This Move

Three triggers show up in practice, and they carry very different amounts of urgency. The sharpest one is a carve-out or divestiture with a Transition Services Agreement attached: when a business unit is being separated and its financial system sits inside the parent's ERP, IT separation is consistently the longest-running piece of the deal, because most TSA services are IT services and other functions can't exit the agreement until their systems do. Timelines scale with how entangled the systems are — light entanglement runs six to nine months, a shared ERP with commingled company codes runs twelve to eighteen, and a single deeply-shared instance can run eighteen to thirty-six — and TSA pricing is often structured to escalate ten to twenty-five percent per extension period specifically to force the migration to finish.

The second trigger is a NetSuite renewal that lands harder than budgeted: reported full-user pricing has moved from roughly $99 to $129 per month, an increase industry sources describe as directional and partner-reported rather than an Oracle-published figure, but real enough that a rising renewal is treated as a legitimate reason to reassess the platform, not just an annoyance to absorb. The third and softest trigger is outgrowing NetSuite's single-account model or wanting deeper ties into the Microsoft ecosystem — a real motivation, but an aspirational one, without the forcing function the first two carry.

The Structural Mismatch: One Account vs. Separate Companies

This is the fact that should shape every planning conversation before it starts. NetSuite OneWorld runs multiple subsidiaries inside a single account: each subsidiary keeps its own nexus, base currency, and reporting scope, but financial data rolls up automatically into the parent's currency, and consolidated reports with cross-subsidiary elimination entries are a native, real-time capability, confirmed directly in Oracle's own OneWorld documentation. Dynamics 365 doesn't reproduce that in either target product the same way.

Business Central requires each former NetSuite subsidiary to become its own company, complete with its own chart of accounts and dimension structure, plus a dedicated consolidation company built specifically to combine them, with a currency-translation method chosen explicitly for every account. Finance & Operations instead uses legal-entity pairs, configured deliberately through its own intercompany accounting setup, for any two entities that need to transact with each other. Neither is a lesser system, but neither one imports NetSuite's single-account rollup automatically.

Consolidated reporting isn't a feature to migrate here; it's a reporting architecture to rebuild, and that rebuild sits in the data layer, not in the application configuration and training work a Dynamics 365 implementation partner is typically staffed to deliver.

Posting Groups: The Configuration Gap With No NetSuite Equivalent

NetSuite has no direct concept of a posting group. Business Central requires one, and it's mandatory in a way that produces hard failures rather than warnings: Microsoft's own documentation defines three umbrellas of posting groups, with a General Business Posting Group and General Product Posting Group combining to determine income-statement accounts, and a Customer or Vendor Posting Group determining the accounts-receivable or payable balance-sheet accounts. Every combination of business and product posting group needs its own general ledger account assignment in what Microsoft calls the General Posting Setup matrix, and an incomplete combination doesn't get flagged during setup — it blocks the transaction at the moment someone tries to post it.

That matrix has to be fully populated before master data loads, which makes posting-group design a hard predecessor to data migration, not a task that can run in parallel with it. Custom fields carry a similar dependency: NetSuite's custom body and entity fields have no automatic Business Central counterpart, and on that platform they require AL-language table extensions built and deployed before the API can even accept data into them, putting a development task squarely on the critical path of what looks, from the outside, like a pure data-movement job.

What Data Actually Moves — and What Gets Left Behind

The instinct to migrate everything is the wrong one, and both vendors' own documentation say so independently. Microsoft's own Dynamics 365 Finance & Operations documentation states plainly that transactions from a completed business process aren't migrated in detail but in summary, because migrating completed transactions in full creates real referential-integrity problems in the new system, not just added cost. The practical version of that rule: migrate open accounts receivable and payable, active sales and purchase orders, current inventory, customer and vendor master records, and the chart of accounts with opening balances loaded as a single journal entry per account as of cutover.

Closed transactions, historical general-ledger detail, and superseded custom records get archived for audit access instead, and a commonly cited rule of thumb is keeping three to five years of active data live while archiving the rest, which keeps reporting accurate without carrying unnecessary weight into the new system. This is the same lesson DharmOps has confirmed independently in other heterogeneous migrations: scope by what a completed transaction actually needs to do next, not by how much historical data exists.

Getting Data Out of NetSuite Without Breaking Production

NetSuite enforces real extraction ceilings, and a migration plan that ignores them will hit them mid-project. SuiteQL, NetSuite's own structured query interface, is capped at 100,000 results per query, with Oracle's own documentation directing anything larger to SuiteAnalytics Connect, a separately licensed, read-only ODBC/JDBC/ADO.NET service explicitly designed for static or infrequently-changing data rather than live access. The standard REST API returns a maximum of 1,000 objects per page, defaulting to 100 unless a larger page size is requested.

Concurrency is governed at the account level, meaning extraction jobs compete for the same pool of request slots as whatever production integrations are still running against NetSuite during the transition — a real scheduling constraint, not just a performance detail. Exceeding it returns an HTTP 429 with no guaranteed retry-after header, so extraction tooling needs exponential backoff built in from the start; a fixed-interval retry loop against an already-throttled account tends to make the problem worse, not better.

Rebuilding Integrations: Why 'Repointing' Usually Means Rewriting

Every system currently talking to NetSuite is a rebuild candidate, not a configuration change, because the two platforms don't share an integration standard. Dynamics 365's data entities, on both Business Central and Finance & Operations, are built to be exposed as OData services, an open, vendor-neutral standard. NetSuite's REST API is Oracle's own proprietary interface, described through OpenAPI metadata rather than OData, and it is explicitly not OData-compliant.

That means CRM feeds, EDI connections, ecommerce syncs, and banking integrations built against NetSuite's SuiteScript, RESTlet, or SOAP surface can't simply be pointed at a new endpoint — each one needs to be re-authored against Dynamics 365's OData or Dataverse surface, with different authentication and different rate-limit behavior. It's also worth knowing going in that there's no first-party Microsoft-built connector for NetSuite in Power Automate; what exists is a third-party connector listed on Microsoft's own marketplace and a handful of custom OAuth patterns published by individual developers. Budgeting integration work as a straightforward "repoint" instead of a rebuild is one of the more reliable ways a migration timeline slips.

The Reconciliation Gate Nobody Should Skip

The release gate for any NetSuite to Dynamics 365 migration is a trial balance that matches to the penny, and it needs to survive an audit, not just look right at a glance. The working sequence: extract NetSuite's closing trial balance as the reference point, load Dynamics 365's opening balances as a single journal entry per account dated to cutover, reconcile account by account against a defined tolerance, handle currency-translation differences explicitly rather than absorbing them into a rounding line, and reconcile the accounts-receivable and payable subledgers separately against their control accounts rather than trusting a GL total that could net an error to zero. Every adjustment needs a documented business reason and sign-off.

Running both systems in parallel for a defined window before full cutover, with a genuine rollback path, is what makes this gate enforceable under real deadline pressure — including the TSA-driven deadlines in the previous section, where the temptation to skip a reconciliation step to hit a contractual date is strongest and the cost of getting it wrong is highest.

How to Scope This Migration Without Guessing

Price and scope off structure first, data volume second. The inputs that actually predict effort: subsidiary count and OneWorld consolidation complexity, which drives the size of the posting-group matrix or the number of intercompany pairs needed; the custom-field and custom-record inventory, which drives Dynamics 365-side development work that has to finish before data loads; the number of systems integrated against NetSuite, since each is a rebuild independent of how much data moves through it; and how many years of transaction history the business insists on keeping live rather than archived, weighed against the referential-integrity risk Microsoft's own documentation flags for migrating completed transactions in detail. Record count matters far less than any of these.

A ten-subsidiary NetSuite account with a dozen integrations and moderate transaction volume is a bigger, riskier project than a single-entity account with ten times the data and no custom integrations — and a fixed price offered before a NetSuite-side discovery pass has scored subsidiary structure, posting-group scope, and integration count is a number nobody can actually stand behind yet.

Related: ERP and CRM Systems Integration