Integrating Dynamics 365 with NetSuite during a migration

Nobody integrates NetSuite with Dynamics 365 for the long term. They integrate the two because they are leaving NetSuite and the leaving takes longer than one weekend. This guide is about the integration work inside that window: getting data out of NetSuite reliably, keeping the two systems coherent while both are live, and sequencing the cutover so the integration can be switched off cleanly. For the functional side of the migration, the module mapping and the licensing arithmetic, see migrating from NetSuite to Business Central.

Getting data out of NetSuite

NetSuite offers more extraction routes than most systems, and they are not equivalent.

Saved searches exported to CSV. The route every NetSuite administrator already knows. Fine for one-off extracts of master data and for reconciliation reports. Poor for anything repeated, because saved searches are hand-maintained and a column added in week three quietly changes the file layout.

SuiteAnalytics Connect (ODBC/JDBC). Direct SQL-style access to NetSuite's data model. This is the best route for bulk historical extraction: you can pull years of transaction lines in one pass, join across records, and script it. It needs a separate licence and a service account, and the schema is NetSuite's internal one, so expect to spend time understanding transaction line tables.

SuiteTalk REST and SOAP web services. The API for record-level operations. Use them for the live sync during the overlap window, not for bulk history; concurrency governance limits will throttle a naive bulk pull.

SuiteQL through the REST API. A query language over the same model SuiteAnalytics exposes, but callable over REST without the ODBC licence. Good middle ground for scripted, repeatable extracts when you cannot get Connect approved.

The practical answer for most projects: SuiteAnalytics Connect or SuiteQL for history, SuiteTalk for anything that must stay in sync during parallel running, and saved searches for reconciliation.

Getting data into Dynamics 365

Business Central takes bulk loads through configuration packages (RapidStart) and, for larger volumes, through API pages or an extension-based import. Finance and Operations takes them through the Data Management Framework; see our DMF deep dive. Both prefer clean, pre-mapped files. Do the transformation between extract and load in a staging database or a proper ETL tool, not in Excel, so you can rerun it. You will rerun it.

What to migrate versus what to leave

Open items and balances, yes: open AR and AP, open sales and purchase orders, inventory quantities and costs, fixed asset registers, and opening trial balances. Closed history is the argument. Loading years of posted NetSuite transactions into Dynamics 365 as real postings is expensive, distorts your new ledger with old account structures, and rarely earns its keep. The usual compromise is to load summarised historical balances by period and keep NetSuite in read-only mode, or export its history to a reporting database, for lookups.

NetSuite customisations, SuiteScripts, and custom records need a decision each: rebuild, replace with standard functionality, or drop. The migration is the one chance to drop things.

Coexistence during parallel running

The safest overlap is short and one-directional. Pick the go-live date, freeze master-data creation in NetSuite a week before, load Dynamics 365, and run the cutover. If the business insists on a phased approach by entity or subsidiary, you now need a live sync for whatever is shared across the boundary, which in practice is customers, vendors, items, and intercompany transactions.

For that sync, one system owns each record type. NetSuite keeps ownership of subsidiaries still running on it; Dynamics 365 owns the migrated ones. Master data shared by both goes one way from the system that is still the long-term home. Building bidirectional master-data sync for a temporary overlap is money you will not get back.

Tooling for the live sync is the usual set: Power Automate with an HTTP action against SuiteTalk for low volumes, an iPaaS such as Celigo (which is deeply NetSuite-native), Boomi, or Workato for anything with more than a couple of objects, and Azure Functions if you would rather own code than a subscription.

Reconciliation is the real deliverable

Every load needs a reconciliation report that a finance person, not an integration developer, can read. Record counts by type, control totals for balances, and a sample-level comparison of key records. Run it after every trial load, and make sign-off on it a formal gate. Migrations that go wrong are almost never wrong because of the extraction technology; they are wrong because nobody compared the two trial balances properly before go-live.

Cutover sequencing

The order that works: freeze NetSuite master data, extract and load master data, reconcile, extract and load open transactions and balances as of the cut date, reconcile again, open Dynamics 365 for transactions, switch NetSuite to read-only. If a live sync existed during a phased overlap, disable it before the final balance load, not after, so the two systems cannot drift during the reconciliation window.

Keep NetSuite access for at least one full audit cycle. Contracts often lapse before the auditors ask their questions.

What breaks in practice

Currency and tax setups that were implicit in NetSuite becoming explicit in Dynamics 365, and turning out to have been wrong all along. Item costing methods that do not match, so inventory values differ at cutover and need an explicit revaluation. Subsidiary structures in NetSuite OneWorld that map awkwardly onto Business Central companies or F&O legal entities. None of these are integration problems; they surface through the integration and are solved in the design.

Stability verdict

The extraction tools are mature and the load tools on the Dynamics 365 side are mature. The risk sits entirely in scope decisions and reconciliation discipline. A migration that treats the integration as a short-lived tool, with a clear switch-off date, goes well. One that lets a "temporary" sync become permanent ends up running two ERPs.