Dynamics GP / NAV to NetSuite Migration

The problem

A Dynamics GP or NAV estate that has run for a decade is not a database you can export and re-import. It is a set of accumulated decisions: an account string split across segments, analytical accounting dimensions that only three people fully understand, inventory valued under an averaging method that was changed once in 2014, and a receivables ledger where half the open items are partial applications against invoices that were themselves credited and re-raised.

When that estate moves to NetSuite, the mechanical part — customers, vendors, items — is the easy quarter of the work. The hard three quarters are: deciding what a GP analytical dimension becomes in NetSuite (a class, a department, a location, or a custom segment), reconciling a trial balance that has to tie to the penny on day one, carrying enough transaction history that the business can still answer questions about last year, and doing all of it while the legacy system is still taking orders.

Most migrations fail not at the load step but at the reconciliation step, when nobody can explain why the NetSuite AR aging is $14,000 different from the GP one and there is no audit trail from source row to target record.

What ECOSIRE builds

ECOSIRE builds you a migration toolkit as a SuiteCloud Development Framework (SDF) project deployed into your own NetSuite account. It is not a generic wizard — it is written against your actual GP or NAV schema and your actual target chart of accounts.

Staging layer

A set of custom records holds every extracted source row before anything touches a real NetSuite record: staging records for customers, vendors, items, open AR, open AP, GL opening balances, and historical transactions. Each staging record carries the source system key (GP customer number, NAV entry number), a status field, an error field, and a link to the NetSuite record it produced. This is what makes the migration auditable and re-runnable: you can re-load a single failed batch without touching the 40,000 rows that already succeeded.

Dimension mapping engine

A mapping custom record translates GP account segments and analytical accounting codes — or NAV global and shortcut dimensions — into NetSuite equivalents. The engine supports mapping a source dimension to a Class, Department, Location, Subsidiary, or a Custom Segment, and it supports composite rules where the target depends on two source values. Where GP used a segmented account string, the toolkit splits the string and routes each segment to its configured target, so your NetSuite account list stays flat and reportable instead of inheriting a 6,000-row combinatorial explosion.

Extraction and transform

SuiteScript 2.1 RESTlets accept extract payloads pushed from your source environment, so no inbound connection into your finance network is required. Payloads are validated on arrival — required fields, referential integrity against already-migrated masters, date and currency sanity — and rejected rows land in the staging error field with a readable message rather than silently disappearing.

Load engine

Map/Reduce scripts do the actual record creation, which is what lets the migration handle volume without governance failures. Separate Map/Reduce deployments handle Customers, Vendors, Items, Opening Balances (as Journal Entries), Open AR (as Invoices or a summarized Journal), Open AP, Inventory Adjustments for opening quantities and costs, and historical Sales and Purchase transactions. Each stage is independently runnable and independently re-runnable.

OneWorld handling

If you are on OneWorld, the toolkit maps each GP company database or NAV company to a Subsidiary, handles the intercompany accounts that GP kept in its own intercompany tables, and sets the correct subsidiary context on every created record. Currency handling covers both the transaction currency and the exchange rates in force at the historical dates, using the Currency Exchange Rate record rather than hard-coded rates.

Reconciliation reporting

Saved searches and a summary custom record compare source totals to loaded NetSuite totals by account, by customer, by vendor, and by item, at every stage. You get a variance report before go-live, not a surprise after it. Every created record carries a custom field pointing back to its source key, so any balance can be traced from the NetSuite GL Impact back to the GP journal number.

Cutover controls

A User Event script can lock migrated records against accidental edit during the parallel-run window, and a Scheduled script produces a daily delta report during that window so finance can see divergence between the two systems while both are live.

Who this is for

This is for finance and IT teams leaving a Dynamics GP or NAV installation that is at or near end of mainstream support, where the data volume and dimensional complexity are past the point where a spreadsheet-and-CSV migration is credible. It suits organisations with multiple companies, multiple currencies, meaningful inventory, and an auditor who will ask how opening balances were derived.

It is not for a five-user GP install with 200 customers and no history requirement — for that, NetSuite's standard CSV import is genuinely sufficient and we will tell you so on the call.

How delivery works

1. Scoping call. We walk your source system: GP or NAV version, number of companies, module footprint, analytical dimension usage, volume by table, and what history you actually need in NetSuite versus what can live in an archive. We look at your target NetSuite account: edition, OneWorld or not, existing chart of accounts, existing segments.

2. Fixed quote. You get a written scope naming the exact record types in scope, the dimension mapping approach, the history depth, and the reconciliation reports you will receive. The price is fixed against that scope. If the scope changes, we re-quote before building.

3. Build. ECOSIRE writes the SDF project — custom records, RESTlets, Map/Reduce scripts, saved searches, mapping tables — against your specification. Typical lead time is one working week depending on the number of record types and companies in scope.

4. Install in a test account. Everything is deployed to your NetSuite sandbox or a Release Preview account first. We run a full trial migration there with real extracted data, produce the reconciliation reports, and iterate on the mapping until the variances are explained or zero. You sign off on the trial before anything is deployed to production.

5. Production deployment. The same SDF project is deployed to your production account. The cutover run happens on your schedule, with the reconciliation reports produced as the migration proceeds so you are never waiting until the end to find out whether it worked.

6. Support window. Two weeks of go-live support covering defects, mapping adjustments discovered during the parallel run, and re-run assistance. You own the SDF project source in full — it is an unmanaged bundle in your account, and you or another developer can modify it without us.

Nothing here is pre-built and instantly downloadable. Every migration toolkit is written for one source estate and one target chart of accounts, because that is the only way the reconciliation ties.