Migrating GP to Intacct requires restructuring segmented accounts into dimensions, managing API rate limits by tier, and validating trial balances to the penny.
There is no native migration path from Dynamics GP to Sage Intacct. The fundamental challenge is a structural transformation from GP's segmented chart of accounts stored in on-premise SQL Server tables to Intacct's cloud-native dimensional accounting model, where each account segment must be decomposed into separate GL accounts and independent dimensions (Location, Department, Project, etc.). Every historical transaction must be parsed, split, remapped, and loaded via the Sage Intacct XML Web Services API, requiring significant custom transformation logic, dependency-ordered loading, and full trial balance reconciliation.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Normalize dates and currency values before your first mock load
GP SmartLists can export currency values with five decimal places, and Intacct import rejects Excel date formats that begin with *. (learn.microsoft.com)
Most Intacct implementations only require 2 to 3 years of historical GL detail
Older history can be migrated as annual summary journal entries by account. Keep a read-only GP instance or SQL backup for audit access to older detail. Talk to your auditors about what they actually need before deciding scope.
If you are on Performance Tier 1 (the default), 100,000 monthly transactions is not a lot
If you are on Performance Tier 1 (the default), 100,000 monthly transactions is not a lot for a migration that touches GL, AP, AR, vendors, customers, and items. Coordinate with Sage to temporarily upgrade your tier or schedule the migration during a low-usage window.
Never migrate historical data and open balances in the same pass without offsetting your
Never migrate historical data and open balances in the same pass without offsetting your control accounts. Failure to do this will double-count your AP and AR balances in the general ledger.
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 Sage Intacct 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
for every migrated object — vendors, customers, GL accounts, open invoices. If you extracted 4,500 vendors from GP, query the Intacct API to confirm exactly 4,500 vendors exist.
Dynamics GP → Sage Intacct specifics
- Multi-entity consolidation
- GP treats each company database as isolated. Intacct provides native multi-entity consolidation with intercompany eliminations.
- Dimensional accounting
- GP forces reporting dimensions into account segments. Intacct separates them into true dimensions — Location, Department, Project, and custom dimensions — that can be combined independently.
- Cloud-native architecture
- No more SQL Server patching, VPN dependencies, or on-premise hosting costs.
- Summary history and open balances only
- Native CSV templates or ETL to summary journals, then keep GP read-only.
- Low engineering bandwidth
- Third-party service or managed migration.
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 → Sage Intacct field pair -
Map dimensions, cost centres and analysis codes
ERPs differ structurally here: segments, dimensions, tracking categories and classes are not interchangeable. Confirm how Sage Intacct 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 Sage Intacct 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 Sage Intacct, 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 → Sage Intacct specifics
- Trial balance tie-out
- at the cutover date. Non-negotiable. Match to the penny by account, entity, and department.
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 Sage Intacct, 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 Sage Intacct 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 Sage Intacct 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 Sage Intacct 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 → Sage Intacct specifics
- Fast, finance-grade cutover
- Managed service is usually the lowest-risk route.
- Cutover model
- Big-bang over a weekend is standard for financial systems to prevent dual-entry errors.
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 Sage Intacct record-for-record -
Reproduce the financial statements
Generate balance sheet, P&L and cash flow in Sage Intacct 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 Sage Intacct 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 Sage Intacct, 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 Sage Intacct. 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 Sage Intacct to prevent users from accidentally posting into closed years.
-
Set up reporting dashboards
in Intacct to replace GP Management Reporter layouts and SmartLists.
-
Monitor downstream integrations
that read customer, vendor, item, or GL identifiers. Any system connected to GP needs to be repointed.
Dynamics GP → Sage Intacct specifics
- Hash totals
- for key amount fields as a secondary check.
- Spot-check individual transactions
- Pick 20 random AP bills and 20 random AR invoices and verify amounts, dates, and dimensions match.
- UAT with the finance team
- in an Intacct sandbox environment before touching production. They will catch mapping errors that automated validation misses.
- Train the finance team
- on dimensional reporting — filtering by Location, Department, and Project instead of segment-based filtering.
- Maintain a GP read-only instance
- for at least one full audit cycle. If detail history was left behind, this is the original audit system of record.
Don't move on until
- Financial statements match the pre-migration position
- First period-end close completed and reviewed in Sage Intacct
- 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 Description
| Dynamics GP field | Sage Intacct field | Notes |
|---|---|---|
| GL00100 | Account Master | Split segments into dimensions |
| GL00105 | Account Index Master | Resolve ACTINDX to formatted values before load |
| GL20000 | Open Year GL Transactions | Current year journal entries |
| GL30000 | Historical GL Transactions | Often summarized by period |
| RM00101 | Customer Master | Load before open AR |
| RM20101 | Open Receivables | Preserve document numbers and due dates |
| PM00200 | Vendor Master | Load before open AP; map 1099 type |
| PM20000 | Open Payables | Must reference existing vendor IDs |
| IV00101 | Item Master | Only if Intacct modules will use items |
| POP10100 | Purchase Order Work | Only migrate open POs |
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 structure must be fully decomposed into Intacct's natural account plus independent dimensions, requiring every account string to be parsed and remapped without breaking the trial balance. |
| General Ledger History | high | Historical journal entries contain embedded segment data that must be split into dimensional tags, and any transformation error can produce unbalanced ledgers where debits and credits do not reconcile. |
| Accounts Payable (Open) | high | Partially applied payments, vendor credit memos, and multi-currency AP transactions require precise reconstruction to maintain accurate aging reports and vendor balance integrity. |
| Accounts Receivable (Open) | high | Open AR invoices with partial payments and applied credits must be migrated with exact balances and customer references intact, or aging reports will disagree with source data. |
| Vendor Master | medium | Duplicate vendors, inactive records, and missing tax IDs in GP's PM00200 table require cleanup before migration to avoid broken references in imported AP transactions. |
| Customer Master | medium | Customer records must be deduplicated and validated before loading, as Intacct AR transactions will fail if they reference customer IDs that were not imported or were mapped incorrectly. |
| Dimensions (Locations/Departments) | medium | New Intacct dimension values must be created from GP segment values before any transactional data is loaded, and the crosswalk mapping must be complete and consistent across all entities. |
| Custom Fields and Analytical Accounting | high | GP custom tables and Analytical Accounting dimensions have no standard Intacct counterpart, requiring custom dimension creation and bespoke transformation logic for each field. |
| Multi-Currency Transactions | medium | Currency revaluations and realized/unrealized gain-loss entries in GP must be carefully mapped to Intacct's multi-currency framework to avoid balance discrepancies. |
| Opening Balances | low | Summary opening balances are the simplest data to migrate via CSV or journal entry, provided the trial balance is validated against GP before and after the load. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Segment-to-Dimension Restructuring
GP's segmented account strings (e.g., 100-5010-300) must be decomposed into a standalone GL Account ID and separate Intacct dimensions for Location, Department, and other reporting attributes, which is a fundamental data model transformation rather than a simple remapping.
API Concurrency and Rate Limits
Sage Intacct's XML Web Services API enforces concurrency rules, 15-minute sender timeouts, and recommended limits of under 1,000 records per query and 100 records per write, requiring careful batching and session management for large GP datasets.
Dependency-Ordered Data Loading
Intacct imports must follow a strict dependency order—dimensions, vendors, customers, and GL accounts must exist before referencing transactions can be loaded—or the entire import batch will fail.
Multi-Entity Consolidation Mapping
GP treats each company as an isolated database, so migrating to Intacct's native multi-entity structure requires redesigning intercompany relationships, elimination entries, and consolidated reporting hierarchies.
Partial Payment and Subledger Complexity
Edge cases like partially applied AP payments, multi-currency revaluations, and open AR/AP detail require precise reconstruction in Intacct to preserve aging accuracy and audit trail integrity.
Historical Data Scope Decisions
Teams must determine what migrates as live subledger detail, what becomes summarized journal history, and what remains archived in read-only GP, as full transactional reconstruction is cost-prohibitive for most organizations.
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
When is the Microsoft Dynamics GP end of life?
Microsoft Dynamics GP support for product enhancements, regulatory updates, and technical support ends December 31, 2029. Security updates continue until April 30, 2031. After 2029, there will be no more payroll updates, tax table changes, or new features from Microsoft.
What are the Sage Intacct API rate limits for data migration?
Sage Intacct uses performance tiers. The default Tier 1 allows 100,000 API transactions per month and one concurrent offline process. Higher tiers scale up significantly. Some secondary sources cite 1,296,000 requests per day and 150 concurrent requests, but the official tier documentation should be your source of truth. Exceeding your tier limit triggers a 429 error. Coordinate with Sage about a temporary tier upgrade before a large migration.
How do you map Dynamics GP segments to Sage Intacct dimensions?
GP account segments like Division-Account-Department in format 100-5010-300 must be split apart. The natural account segment becomes the Intacct GL Account ID. Other segments like division and department become Intacct dimensions such as Location, Department, Project, or custom dimensions. This is a structural transformation, not a one-to-one rename.
How long does a Dynamics GP to Sage Intacct migration take?
It depends on data volume and complexity. A migration with summary historical GL, under 500 vendors and customers, and no multi-currency can be completed in 1 to 2 weeks. Complex migrations with detail-level GL history, multi-entity consolidation, and open AP/AR typically take 3 to 6 weeks including testing and validation.
Should I migrate all historical GL data from Dynamics GP to Sage Intacct?
Usually no. Most implementations migrate 2 to 3 years of detail-level journal entries. Older history is best brought over as summary annual journal entries by account. Keep a read-only GP instance or SQL backup so auditors can still access full historical detail.