Dynamics GP to NetSuite migration is a structural data model translation. Map GP segmented accounts to NetSuite dimensions, respect API concurrency limits, and validate with a trial balance tie-out.
There is no native migration path from Dynamics GP to Oracle NetSuite; the move requires a structural translation from an on-premise SQL Server database with hardcoded segmented account strings to a cloud-native, API-governed platform built on a unified entity model with dimensional segments. The most fundamental data model difference is GP's concatenated GL account segments (e.g., 1100-100-200) versus NetSuite's base GL account tagged with independent dimension values (Department, Class, Location, Custom Segments), which means every chart of accounts entry must be decomposed and remapped. Custom ETL work is required to transform segmented accounts into NetSuite dimensions, preserve trial balance integrity, handle relational subledger data like partially applied AR/AP payments, and load via the SuiteTalk REST API with concurrency governance, automated retry logic, and audit logging.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
NetSuite is retiring SOAP web services
The 2025.2 endpoint is the final planned SOAP release. By the 2028.2 release, all SOAP endpoints will be permanently disabled. Build any new migration integration on REST with OAuth 2.0. (docs.oracle.com)
In OneWorld, a subsidiary's base currency cannot be changed after first save
Bank and credit card accounts are restricted to one subsidiary. Get subsidiary mapping right before you build payloads. (docs.oracle.com)
Do not recreate every GP account combination as a separate NetSuite GL account unless
Do not recreate every GP account combination as a separate NetSuite GL account unless finance explicitly wants that old reporting shape. In most successful projects, one GP segment becomes the natural account and the rest become reporting segments. Custom segments are often the cleanest landing zone for extra GP segments, but you must design them before migration — SuiteScript cannot create the segment definition itself. Pre-create the segment structure and values, then load records against them. (docs.oracle.com)
Avoid pipe characters (|) in external IDs
Oracle's REST API can parse | as a multi-select delimiter. (docs.oracle.com)
This is a simplified outline
A production migration script needs connection pooling, concurrent request management against NetSuite's concurrency cap, comprehensive error logging with request/response payloads, idempotency keys for batch operations, and a separate reconciliation step that compares source totals to NetSuite search or SuiteQL results.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Scope the ledger, the subledgers and the audit obligations.
Objective Agreed scope across master data, open transactions and historical balances, with finance and audit signed up.
Keep these open
-
Inventory master data and transaction volumes in Dynamics GP
Count GL accounts, customers, vendors, items, fixed assets, open AR and AP, and transaction lines by year. Transaction line volume, not header count, is what determines your load time.
Data Profiler Get real record counts instead of estimating from memory -
Decide the history strategy with finance and audit
Choose between opening balances only, open items plus balances, or full transactional history. This is the single biggest scope decision in an ERP migration: full history multiplies effort many times over, and most organisations land on balances plus open items plus a read-only archive.
Full transactional history is rarely worth the cost. Confirm what your auditor actually requires before assuming you need it.
Vendor Evaluator Score NetSuite against alternatives on weighted criteria -
Consult the external auditor early
The auditor has views on cut-over timing, audit-trail retention and how you evidence that balances carried across correctly. Finding this out after go-live can mean a qualified opinion, so get it in writing now.
-
Review the chart of accounts and decide whether to redesign
A migration is the natural moment to restructure the COA, and also the riskiest one. If you redesign, you need a mapping from old to new for every historical balance, plus a plan to restate comparatives.
Redesigning the chart of accounts mid-migration doubles the reconciliation burden. Treat it as a separate, sequenced project if you can.
-
Catalogue integrations and statutory reporting
List banking feeds, payment gateways, tax filing, payroll, CRM, e-commerce, warehouse and BI. Then list every statutory and tax filing obligation with its deadline — those deadlines constrain your window absolutely.
-
Pick a period-aligned go-live date
ERP cutovers align to a period boundary — ideally the start of a fiscal year, otherwise the start of a clean month. Mid-period cutover means split-period reporting for the rest of the year.
-
Record count comparison
Total customers, vendors, items, open invoices, and open bills in NetSuite must match the source.
Dynamics GP → NetSuite specifics
- Multi-subsidiary consolidation
- GP treats each company database as isolated. NetSuite OneWorld provides native inter-company elimination, consolidated reporting, and multi-currency handling across subsidiaries in a single instance.
- Unified cloud data model
- GP requires separate add-ons for CRM and eCommerce. NetSuite bundles ERP, CRM, and eCommerce on a single platform with a shared record model.
- Compliance pressure
- Running unsupported software complicates audits under PCI-DSS, HIPAA, ISO-27001, and SOX. Auditors expect actively maintained systems.
Don't move on until
- Chart of accounts and master-data counts confirmed
- History strategy agreed: balances, open items, or full transactional detail
- External auditor consulted on the migration approach
02 Data Audit Reconcile the source before you migrate it — you cannot fix a ledger later.
Objective A source ledger that balances, with master data cleansed and every open item agreed.
Keep these open
-
Produce and sign off a source trial balance
Run the trial balance in Dynamics GP and have the controller sign it. This is your migration baseline: without a signed pre-migration position you have nothing to reconcile the target against, and any later discrepancy is unarguable.
Without a signed, dated source trial balance you cannot prove the migration preserved the ledger. Do this before anything else.
-
Reconcile subledgers to the general ledger
Confirm AR, AP, inventory and fixed-asset subledgers tie to their GL control accounts. Pre-existing breaks must be resolved in Dynamics GP: migrating an out-of-balance ledger makes the break permanently unattributable.
Data Profiler Profile the Dynamics GP export for nulls, outliers and type drift -
Clean and deduplicate master data
Deduplicate customers, vendors and items, and identify records that should not carry forward. Duplicate vendors are also a fraud-control weakness, so this has value beyond the migration.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Agree open AR and AP item by item
Every open invoice, credit note and payment on account needs an owner and an agreed amount, including partially-paid items and foreign-currency balances. Open items are what customers and vendors will dispute in week one.
-
Validate export structure, encoding and precision
Check numeric precision and rounding on the export, and confirm dates and currency codes are unambiguous. Precision loss on amounts is silent, cumulative and produces penny differences that take days to trace.
Amounts exported at reduced precision will not re-total. Verify decimal places before you accept the export.
CSV Validator Catch broken headers and ragged rows in the raw export -
Scan for regulated data and produce masked test data
ERP data holds bank details, tax IDs and payroll information. Scan it, restrict who can see it, and generate a masked copy for the sandbox and for any implementation partner.
PII & Compliance Scanner Find regulated fields before they land in a new system
Don't move on until
- Trial balance in Dynamics GP balances and is signed by the controller
- AR and AP subledgers reconcile to the GL control accounts
- Master data deduplicated and inactive records identified
03 Field Mapping Map the COA, the dimensions and the subledger structures.
Objective A signed mapping covering the chart of accounts, dimensions, tax codes and currency handling.
Keep these open
-
Map the chart of accounts account by account
Every source account maps to exactly one target account, or to a documented split with agreed proportions. The controller reviews and signs this line by line — an unreviewed COA map is how a balance sheet stops balancing.
Schema Mapper Opens pre-loaded with the Dynamics GP → NetSuite field pair -
Map dimensions, cost centres and analysis codes
ERPs differ structurally here: segments, dimensions, tracking categories and classes are not interchangeable. Confirm how NetSuite models analysis and whether your existing reporting hierarchy survives the translation.
-
Map tax codes, rates and jurisdictions
Map every tax code with its rate, jurisdiction and reporting treatment, then verify the mapping reproduces your last filed return. Tax errors are statutory exposure, not reporting inconvenience.
A tax-code mapping that has not been tested against a previously filed return is untested. Reproduce a real filing before sign-off.
-
Decide multi-currency and exchange-rate handling
Confirm functional and reporting currencies, and how historical rates are stored. Revaluing historical transactions at current rates rewrites reported results and will not tie to filed accounts.
Historical transactions must retain their original transaction-date rates, or your comparatives will not match filed statements.
-
Map master data and subledger structures
Map customer and vendor records with their payment terms, credit limits and tax registrations, and item records with units of measure and costing method. Costing-method differences change inventory valuation, which changes the balance sheet.
-
Set load order and freeze the spec
COA, then dimensions, then master data, then opening balances, then open items, then any historical detail. Version and sign off the spec with the controller before the pilot.
Don't move on until
- Account-by-account COA mapping reviewed by the controller
- Tax codes and jurisdictions mapped and verified against filings
- Multi-currency and rate handling agreed with finance
04 Test Migration Prove the ledger balances in the target before you trust it.
Objective A sandbox load whose trial balance matches the signed source position to the penny.
Keep these open
-
Configure the NetSuite sandbox with the agreed structures
Build the COA, dimensions, tax codes, currencies, fiscal calendar and posting rules before loading anything. Every one of these affects how a posted transaction lands, so an unconfigured sandbox produces meaningless results.
-
Load master data and validate it
Load customers, vendors and items first and verify counts, payment terms, tax registrations and costing methods. Transactions cannot post correctly against wrong master data, so this gate comes before any balance work.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Load opening balances and prove the trial balance ties
Load opening balances and run a trial balance in NetSuite, comparing to the signed source position. It must match exactly — a rounding difference here is a mapping defect, not a rounding difference.
Any variance at all between source and target trial balance must be explained line by line. "Close enough" is never acceptable in a ledger.
-
Load open items and reconcile the subledgers
Load open AR and AP with their ageing intact, then confirm subledger totals tie to GL control accounts and that ageing buckets match. Ageing that shifts means transaction dates mapped wrongly.
-
Run a full period-end close in the sandbox
Execute the whole close: revaluation, accruals, depreciation, tax calculation, and financial statement generation. Compare every statement to Dynamics GP for the same period. The close is where structural mapping errors finally become visible.
-
Test transactions end to end and reproduce a tax filing
Post a sales order to cash and a purchase order to payment, then generate the tax return for a previously filed period and compare it to what you filed. If both reconcile, the configuration is sound.
Dynamics GP → NetSuite specifics
- Trial balance tie-out
- is the controlling test. If debits and credits do not match GP at the account level, stop and find the variance before proceeding.
- UAT with finance
- Your accounting team must sign off. Run aging reports, P&L, balance sheet, cash flow statements, vendor statements, customer aging, subsidiary roll-ups, and segment-based views in both systems and compare.
- Sandbox first, always
- Run the full migration in a NetSuite Sandbox environment at least twice before touching production. Document every variance and fix.
Don't move on until
- Target trial balance matches the signed source trial balance exactly
- Subledgers reconcile to control accounts in the target
- A full period-end close has been run in the sandbox
05 Cutover Switch the ledger on a period boundary, with balances proven.
Objective Balances and open items live in NetSuite, transacting resumed, and a signed post-load trial balance.
Keep these open
-
Close the final period in Dynamics GP and freeze posting
Complete the period-end close, then lock posting entirely. An ERP freeze is absolute: a single journal posted to the old system after the final export leaves the two ledgers permanently divergent.
One journal posted in the old ERP after the final export breaks the reconciliation permanently. Lock posting at the system level, not by asking people nicely.
-
Publish the cutover runbook with the abort point
A timed, owner-named sequence for load, balance verification, integration switch and go/no-go, with an explicit abort criterion. The trial-balance check is the gate — nothing proceeds until it ties.
-
Load balances and open items into production
Load the final opening balances and open AR/AP into NetSuite production, following the pilot-proven sequence. Do not improvise the order under time pressure.
-
Reconcile and sign the post-load trial balance
Run the trial balance in NetSuite and reconcile it to the signed source position, then have the controller sign the result. This signature is your evidence for the auditor and your go/no-go gate.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint banking, payment and tax integrations
Switch bank feeds, payment gateways, tax filing connections, payroll and BI, then process one real low-value payment and one bank reconciliation end to end. Banking errors move real money, so verify with live traffic.
Payment integrations left connected to the old ERP can duplicate real payments. Disable them before switching, not after.
-
Go/no-go, then open for transacting with daily reconciliation
Call the decision on the signed trial balance, open NetSuite for posting, and reconcile daily for the first two weeks with finance support on hand. Keep Dynamics GP read-only for statutory retention — this is an audit requirement, not a preference.
Don't move on until
- Post-load trial balance signed by the controller
- Banking, tax and payment integrations verified live
- Users transacting and the first daily reconciliation clean
06 Validation Prove the statements, the tax position and the audit trail.
Objective Financial statements reproducing the source position, a clean tax filing, and auditor acceptance.
Keep these open
-
Reconcile the full ledger and all subledgers
Reconcile trial balance, AR, AP, inventory, fixed assets and bank against the signed source position. Produce a single reconciliation pack that goes to the auditor.
Migration Validation Tool Reconcile Dynamics GP and NetSuite record-for-record -
Reproduce the financial statements
Generate balance sheet, P&L and cash flow in NetSuite and compare to the pre-migration statements. Every variance needs a documented explanation traced to a specific mapping decision.
-
Complete and review the first period-end close
Run the first real close in NetSuite with extra review at every step. Compare its duration and outcome to your historical close, and treat anything unexpected as a live finding.
Data Profiler Prove field completeness held up through the load -
Verify the tax position and file
Generate and review the first tax filing from NetSuite, reconciling it to the underlying transactions before submission. Have the tax lead review it independently.
The first statutory filing out of a new ERP should be reconciled manually to source transactions before submission.
-
Confirm controls, segregation of duties and audit trail
Verify user permissions, approval limits, segregation of duties and audit logging in NetSuite. Controls do not migrate, and a control gap found by an auditor is far more expensive than one you find yourself.
PII & Compliance Scanner Produce the compliance evidence your auditor will ask for -
Obtain auditor acceptance and retain the archive
Walk the auditor through the reconciliation pack, get written acceptance, and retain Dynamics GP read-only for the full statutory retention period. Diarise the retention expiry rather than the contract renewal.
-
Lock historical periods
in NetSuite (Setup > Accounting > Manage Accounting Periods) to prevent accidental posting to migrated periods.
-
Set up automated dashboards
using Saved Searches and SuiteAnalytics to replace GP SmartList reports and Management Reporter.
Dynamics GP → NetSuite specifics
- Hash validation
- For large datasets, compute checksums on key amount fields in both GP and NetSuite to catch rounding errors at scale.
- Train the finance team
- on NetSuite navigation, segment-driven reporting, Saved Searches, report customization, and period close workflows.
Don't move on until
- Financial statements match the pre-migration position
- First period-end close completed and reviewed in NetSuite
- Auditor satisfied and archive retained for the statutory period
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
GP SQL Table GP Description
| Dynamics GP field | NetSuite field | Notes |
|---|---|---|
| GL00100 / GL00105 | Account Master / Index | Split natural account from segments |
| GL40200 | Segment Description Master | Map each segment type |
| RM00101 | Customer Master | Plan subsidiary logic for OneWorld |
| RM00102 | Customer Address Master | |
| PM00200 | Vendor Master | Handle shared vendors in OneWorld |
| PM00300 | Vendor Address Master | |
| IV00101 | Item Master | Choose by item type and costing |
| RM20101 | Open Receivables | Load only live receivables |
| PM20000 | Open Payables | Preserve due dates and currency |
| GL10110 / GL10111 | Open / Historical Year Summary | Preferred source for summary GL |
| GL20000 | Open Year Posted Transactions | Usually summary load |
| GL30000 | Historical Year Transactions | One per period per account |
| SOP10100 | Sales Order Work | |
| POP10100 | Purchase Order Work | Only if open POs in scope |
| MC00100 | Exchange Rates | Load before foreign-currency docs |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Chart of Accounts | high | GP's segmented account strings must be decomposed into NetSuite's base account plus independent dimensions, making this the single most impactful structural transformation with direct trial balance risk. |
| General Ledger History | high | Migrating detail-level historical GL transactions at scale risks timeouts and imbalanced ledgers; most implementations require summarizing history into period-end balance journal entries. |
| Open Accounts Payable | high | Unpaid vendor invoices with partial payment applications involve complex relational chains that must be accurately reconstructed to maintain correct vendor aging and balances. |
| Open Accounts Receivable | high | Open customer invoices with applied credits and deposits require precise relational mapping to NetSuite internal IDs, and errors produce incorrect aging reports and revenue recognition issues. |
| Customers | medium | Customer master data including ship-to addresses, credit limits, and payment terms transfers relatively well, but GP's flat structure must be mapped to NetSuite's hierarchical customer-subsidiary model. |
| Vendors | medium | Vendor records including 1099 status and payment terms require careful mapping, particularly when consolidating vendors across multiple GP company databases into a single NetSuite instance. |
| Items | medium | Inventory, non-inventory, and service items require costing method alignment between GP and NetSuite, and any mismatch in item types can affect valuation and COGS calculations. |
| Open Purchase Orders and Sales Orders | medium | Open orders must be migrated with correct line-level detail and entity references, and partially fulfilled orders add complexity in reconstructing receipt and fulfillment status. |
| Custom GP Fields and Tables | high | Custom GP Extender fields and ISV module tables have no automatic mapping to NetSuite and require manual mapping to Custom Records or Custom Segments, with risk of data loss if not fully inventoried. |
| Exchange Rate Tables | low | Exchange rate data is structurally simple to migrate, though rates must be validated against NetSuite's currency and subsidiary configuration to ensure correct multi-currency consolidation. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Segment-to-Dimension Account Transformation
GP's hardcoded concatenated account segments must be decomposed into NetSuite's independent dimensional model (Department, Class, Location, Custom Segments) without breaking the trial balance or destroying segment-based reporting.
API Concurrency Governance Limits
NetSuite enforces strict concurrency caps (15 base concurrent API requests for Service Tier 1) and 100-record batch limits, requiring custom throttling, exponential backoff, and retry logic to avoid 429 errors during large data loads.
Multi-Company Database Consolidation
GP isolates each company in a separate SQL Server database, whereas NetSuite OneWorld manages subsidiaries within a single instance, requiring inter-company elimination logic and subsidiary mapping during migration.
Open Subledger Relational Integrity
Open AR and AP transactions with partial payment applications, applied credits, and deposits involve complex relational chains that must be reconstructed with correct internal ID references in NetSuite to maintain accurate aging and balances.
Historical GL Scope Decision
Teams must determine which historical GL data migrates as detail-level transactions versus period-end summary journal entries, since Oracle's own guidance favors historical balances over replaying full transactional history.
SOAP Deprecation Timeline Pressure
NetSuite is retiring SOAP web services with permanent disablement by the 2028.2 release, meaning all migration integrations must be built on the REST API with OAuth 2.0 authentication to avoid rework.
What breaks
Known failure modes. Have a recovery plan for each before you cut over.
Unbalanced journal entries
GP allows some transactions to post with rounding differences across distributions. NetSuite requires perfect debit/credit balance on every journal entry. Detect and resolve these during transformation, not after loading. If your GP data contains historical rounding errors, post the difference to a designated variance account.
Multi-currency and historical exchange rates
If you use NetSuite OneWorld with Multiple Currencies, you must load historical exchange rate tables before importing any foreign-currency transactions. Rates must match the original GP posting rates or translated balances will drift. OneWorld base currency is fixed after subsidiary creation — this cannot be changed. (docs.oracle.com)
Partially received Purchase Orders
GP distinguishes shipment receipts from shipment-invoice receipts using POP10500 (Receipts Work) and POP30300 (Receipts History). NetSuite with Advanced Receiving separates item receipt from vendor bill and tracks states like Pending Billing and Pending Billing/Partially Received. Map the receipt chain, not just the PO header. (learn.microsoft.com)
GP inventory costing layers
GP supports Average, FIFO, and LIFO costing. NetSuite supports Average, FIFO, and Lot-level costing but handles cost layers differently. If you use LIFO in GP, discuss the conversion with your accounting team before migration. NetSuite's inventory adjustment worksheet recalculates FIFO or LIFO items using average costing, which loses FIFO/LIFO history. (learn.microsoft.com)
API failures and retries
Never retry a 429 error immediately. Use exponential backoff with jitter. Log every failed record with the full request payload so you can reprocess without re-extracting.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
How do you map the Dynamics GP chart of accounts to NetSuite?
GP uses a segmented account string stored as a concatenated key (e.g., 1100-100-200). Parse each segment using the GL40200 Segment Description Master table. Map the base account to a NetSuite GL Account and each additional segment to a NetSuite dimension (Department, Class, Location, or Custom Segment). Do not recreate every GP combination as a separate NetSuite GL account unless finance explicitly requires that reporting shape.
What are the NetSuite API concurrency limits for data migration?
NetSuite enforces account-level concurrency governance. A Service Tier 1 account has a base limit of 15 concurrent API requests. Each SuiteCloud Plus license adds 10 more. Exceeding the limit returns a 429 error on REST or SSS_REQUEST_LIMIT_EXCEEDED on SOAP. Design migration scripts with exponential backoff with jitter and a concurrency cap below your account limit.
Should I migrate all historical GL data from GP to NetSuite?
No. Best practice is to migrate master data, open AR/AP, and summary GL journal entries (one per period per account) into NetSuite. Leave transaction-level detail in a read-only GP SQL Server instance for audit reference. Oracle's own OneWorld guidance favors historical balances over full transaction replay. This reduces storage costs, API load, and migration timeline.
When does Microsoft Dynamics GP end of life support end?
Microsoft ends mainstream GP support (product enhancements, regulatory updates, tax tables, and technical support) on December 31, 2029. Security patches continue until April 30, 2031, but only for critical vulnerabilities at Microsoft's discretion. After 2031, GP receives no updates of any kind.
Is SOAP still a valid choice for NetSuite migration tooling?
Only as a short-term exception. The 2025.2 endpoint is the final planned SOAP release, and Oracle plans to permanently disable all SOAP endpoints in NetSuite 2028.2. Build any new migration integration on REST with OAuth 2.0.