Treat GP to Acumatica as a model conversion, not a file import. Decompose segmented accounts into subaccounts, manage API rate limits, and validate the trial balance at every step.
Migrating from Dynamics GP to Acumatica has no native one-click migration path; GP's on-premise SQL Server database with segmented account strings must be decomposed and remapped into Acumatica's cloud-native dimensional accounting model using separate natural accounts and subaccount segmented keys. The fundamental challenge is transforming GP's concatenated account segments (e.g., 1200-100-00) into Acumatica's distinct Account and SUBACCOUNT structure without breaking the trial balance or financial reporting. Custom transformation logic is required for account decomposition, branch mapping, and subledger detail handling, whether implemented via the Contract-Based REST API, custom ETL pipelines, or a managed migration service.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Do not map a GP branch or company segment into an Acumatica subaccount segment by default
Acumatica's multibranch documentation explicitly says not to create a subaccount segment for branches. Keep branch as Branch, and use subaccount segments for reporting dimensions like department, product line, or region. (help.acumatica.com)
Once a subaccount has transactions posted against it, you cannot delete or restructure its segments
Get the subaccount structure right in sandbox before loading any financial data.
Migration mode is the cleanest way to move open AR and AP into Acumatica without
Migration mode is the cleanest way to move open AR and AP into Acumatica without restating the new ledger. It is not a shortcut for history. Auto-application of payments to outstanding documents is not supported while migration mode is active. (help.acumatica.com)
Acumatica requires all field values to be wrapped in {"value"
"..."} objects. Sending flat key-value pairs returns 400 errors.
Always test API scripts in a sandbox environment first
Acumatica will delay requests if you hit 50% of your per-minute limit and will decline requests outright once the internal queue exceeds 20. Exponential backoff logic is required for production loads.
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 Acumatica 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.
Dynamics GP → Acumatica specifics
- Summary history only, limited engineering bandwidth
- Use Import Scenarios for master data and a small set of open documents.
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
Dynamics GP → Acumatica specifics
- Detailed GL history, inventory complexity, multi-branch redesign
- Use custom ETL or a managed migration service.
- Chart of Accounts
- Export from GL00100 and GL00105. Identify inactive accounts, duplicate descriptions, and segments that no longer map to active business units.
- Vendor Master
- Query PM00200. Flag vendors with no activity in the last 24 months.
- Customer Master
- Query RM00101. Identify duplicates by tax ID or address.
- Historical GL
- Decide how many years of detail to migrate. Most teams migrate 2 to 3 years of summary and archive detail in a read-only GP instance.
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 → Acumatica field pair -
Map dimensions, cost centres and analysis codes
ERPs differ structurally here: segments, dimensions, tracking categories and classes are not interchangeable. Confirm how Acumatica 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 Acumatica 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 Acumatica, 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.
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 Acumatica, 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 Acumatica 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 Acumatica 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 Acumatica 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.
Dynamics GP → Acumatica specifics
- Need ongoing coexistence after go-live
- Use iPaaS after the migration, not as the primary historical loader.
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 Acumatica record-for-record -
Reproduce the financial statements
Generate balance sheet, P&L and cash flow in Acumatica 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 Acumatica 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 Acumatica, 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 Acumatica. 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 Acumatica to prevent any user from posting into migrated periods.
-
Rebuild reporting
with Generic Inquiries, dashboards, and any external BI models that depended on GP account strings.
Dynamics GP → Acumatica specifics
- Turn off migration mode
- when open document loading is complete. Acumatica's own migration walkthroughs show migration mode being cleared after imported AP review. (help.acumatica.com)
- Train the finance team
- on Acumatica's subaccount structure, Generic Inquiries, and financial reporting. The shift from segmented accounts to dimensional reporting requires a mindset change, not just button clicks.
- Maintain a read-only GP instance
- for historical audit purposes if detail data was left behind.
Don't move on until
- Financial statements match the pre-migration position
- First period-end close completed and reviewed in Acumatica
- 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 Purpose in GP
| Dynamics GP field | Acumatica field | Notes |
|---|---|---|
| GL00100 | Account Master | Split segments during transform |
| GL00105 | Account Index | Index to segment crosswalk |
| GL20000 | Current year GL transactions | Use detail only if required |
| GL30000 | Historical GL transactions | Often summarized for mid-market |
| RM00101 | Customer Master | Map default location, terms, customer class |
| PM00200 | Vendor Master | Review payment method and 1099 behavior |
| IV00101 | Item Master | Carry valuation method and item class |
| IV00102 | Item quantity/site settings | Warehouse-specific overrides |
| PM20000 | Open AP Transactions | Open invoices only, use migration mode |
| RM20101 | Open AR Transactions | Open invoices only, use migration mode |
| SOP10100 / POP10100 | Open Sales/Purchase Orders | Partially received POs need special handling |
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 Acumatica natural accounts and subaccount keys—the most critical transformation in the migration, where errors corrupt all financial reporting. |
| General Ledger History | high | Migrating years of detail-level GL transactions from GL20000/GL30000 involves millions of rows constrained by API rate limits, and the trial balance must reconcile exactly after the account structure transformation. |
| Open Accounts Payable | high | Unpaid invoices from PM20000 must be migrated at the document level with correct vendor linkage and reconciled against the AP aging report to ensure payable balances are accurate at cutover. |
| Open Accounts Receivable | high | Outstanding invoices from RM20101 must transfer with correct customer associations and payment terms, and any mismatch against the AR aging report creates reconciliation issues post-go-live. |
| Customer Master | medium | Duplicate customers identified by tax ID or address in RM00101 must be deduplicated and cleaned before migration to prevent data quality issues in Acumatica. |
| Vendor Master | medium | Inactive vendors with no activity in 24+ months in PM00200 should be flagged and purged, but active vendor records require accurate remapping of payment terms and classification fields. |
| Inventory Items | medium | Item classes, units of measure, and valuation methods from IV00101 must be mapped to Acumatica's inventory structure, with mismatches in valuation method causing costing discrepancies. |
| Branch and Company Structure | high | GP branch or company segments must be mapped to Acumatica's Branch entity rather than subaccount segments, requiring a deliberate finance architecture redesign before any data loading begins. |
| Subaccount Segments | medium | GP reporting dimensions like department, product line, and region must be configured as Acumatica subaccount segments on CS202000, with segment length and ordering decisions impacting all downstream reporting. |
| Custom Fields and Extensions | medium | GP customizations stored in extended tables or Extender windows have no automatic mapping to Acumatica and require custom user-defined fields or generic inquiries to be built before data can be loaded. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Account Segment Decomposition
GP's concatenated segmented account strings must be split into separate Acumatica natural accounts and subaccount segmented keys, and incorrect mapping breaks every financial report in the target system.
Branch vs. Subaccount Mapping
GP company or branch segments must not be mapped into Acumatica subaccount segments, as Acumatica's multi-branch architecture requires branches to remain as a separate Branch entity.
API Rate Limits and Throughput
Acumatica's Contract-Based REST API enforces license-tier-dependent rate limits (50–300 requests per minute, 2,500–100,000 import records per day), creating bottlenecks for high-volume historical data loads.
GL History Volume Decisions
Migrating detailed GL transaction history from GP's GL20000/GL30000 tables at full granularity can mean millions of rows, so teams must decide what moves as summary versus detail versus archived in a read-only GP instance.
Open Subledger Reconciliation
Open AP and AR documents from GP's PM20000 and RM20101 tables must be migrated at the individual document level and reconciled against aging reports to ensure the target subledgers balance correctly.
Import Scenario Reliability
Acumatica's native Import Scenarios run through the UI layer triggering all business logic, which causes timeouts and silent mismatches between processed flags and actually imported records on large data sets.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
How do you map Dynamics GP segmented accounts to Acumatica subaccounts?
GP encodes department, division, and location as segments within a single account string. In Acumatica, the natural account is stored separately, company or location segments map to Branch, and reporting segments become part of the SUBACCOUNT segmented key (up to 30 characters). You must configure segment rules using the Segmented Keys screen (CS202000) and define allowed values on the Segment Values screen (CS203000) before migrating any transactional data. Do not create a subaccount segment for branches — Acumatica's multibranch documentation explicitly advises against it.
What are the Acumatica API rate limits for data migration?
Rate limits depend on your license tier. The 2026 Acumatica licensing guide lists Web API connections from 5 to 60, requests per minute from 50 to 300, API concurrency from 5 to 40, and import records per day from 2,500 to 100,000. Once 50% of the per-minute limit is reached, requests are delayed. If the internal queue exceeds 20 requests, additional requests are declined. These limits cannot be self-configured — check your limits on the License Monitoring Console (SM604000).
How much GL history should I migrate from GP to Acumatica?
Most mid-market organizations migrate opening balances plus 2 to 3 years of monthly summary journal entries. Full detail-level GL history for 10+ years means millions of rows pushed through rate-limited APIs, which is rarely practical. Maintain a read-only GP instance for audit access to historical detail that is not migrated.
When does Dynamics GP end of life support end?
Microsoft will end product enhancements, regulatory updates, and technical support for Dynamics GP on December 31, 2029. Security patches will be available until April 30, 2031, but only for critical vulnerabilities at Microsoft's discretion. New perpetual license sales ended April 1, 2025, and new subscription sales end April 1, 2026.
What is the safest way to migrate open AR and AP from Dynamics GP to Acumatica?
Use Acumatica migration mode for the AR and AP subledgers. Load each open document with its original amount, document date, currency, exchange rate, and remaining open balance. Migration mode updates customer and vendor balances without posting to the new general ledger. Auto-application of payments is not supported while migration mode is active.