← Back to Blog ERP Migration

What a Dynamics GP to Odoo Data Migration Actually Looks Like

The Hard Part Isn't Picking the New System

Every GP migration conversation starts the same way. The client has picked Odoo (or is evaluating it). They've seen demos. The modules make sense. The pricing math works out. They're ready to move forward.

Then someone asks: "What happens to our 12 years of GP data?"

This is where most conversations slow down, and for good reason. Moving a decade-plus of financial history, customer records, vendor data, item masters, and transactional detail from Dynamics GP to Odoo is not a CSV export-and-import operation. The data models are different. GP stores transactions differently than Odoo expects them. The chart of accounts in GP has probably accumulated 15 years of "let's just add an account" decisions that don't belong in the new system.

How you handle the data migration determines whether you start in Odoo with clean books or spend the first six months of your new ERP's life trying to reconcile why the numbers don't match.

What Moves Cleanly

Some data transfers from GP to Odoo with minimal transformation. These are the categories you can migrate with structured import files and reasonable validation effort:

Data Category	Status	Notes
Chart of Accounts	Clean — with redesign	GP's account structure maps to Odoo's COA. Migrate as opportunity to clean up years of accumulated accounts.
Customer master records	Clean	Name, address, payment terms, currency. GP's Customer Master (RM00101) exports cleanly. Validate active vs. inactive.
Vendor master records	Clean	Same pattern as customers. Source from PM00200. Deduplicate before migrating.
Open AR balances	Clean	Open invoices with customer, amount, due date, and original invoice date. Migrate as open balance journal entries or individual invoices.
Open AP balances	Clean	Same as AR. Source from PM20000. Validate aging matches GP AP aging report before cutover.
Item master and inventory quantities	Clean	Item numbers, descriptions, UoM, costs. Current on-hand quantities as inventory adjustment at go-live.

What Requires ETL Transformation

This is where the real work is. These data categories exist in GP and need to exist in Odoo — but the structure is different enough that you need ETL scripts, not CSV copy-paste:

Transaction History

GP stores transaction history across dozens of tables with specific posting logic that doesn't map directly to Odoo's journal entry structure. GP's Sales Transaction history (SOP30200, SOP30300) stores header and line detail separately with a link through document number. Odoo expects moves linked to accounts with specific debit/credit structure.

The migration approach for transaction history is to write extraction queries against the GP SQL database — GP runs on SQL Server — that reconstruct the accounting entries from the GP tables, then transform them into Odoo's journal entry import format (account, amount, partner, date, reference). This is SQL-to-SQL ETL work, not file conversion.

Key GP tables for transaction history extraction:

• GL20000 — GL Transaction Work (current year open transactions)
• GL30000 — GL Transaction History (closed periods)
• SOP30200 / SOP30300 — Sales order document history header and line
• POP30300 / POP30310 — Purchase order receipt history
• RM20101 / PM20000 — AR and AP open transactions

Sales Order and Purchase Order History

This category requires a decision before you write a single script: what years of history are worth migrating, and what can be archived in read-only GP?

Migrating 15 years of sales order history into Odoo is technically possible. It's also expensive to validate, produces a large dataset that slows Odoo's reporting in the early months, and often isn't queried by anyone after the first year. A common approach is to migrate 2-3 years of transaction history into Odoo as journal entries (summary level, not line-level detail), and keep GP available in read-only mode for anything older that someone occasionally needs to look up.

Fixed Assets

GP's Fixed Asset module stores depreciation schedules, book values, and asset history in its own table structure (FA tables) that doesn't have a direct Odoo equivalent. Odoo's asset management module uses different depreciation models and different book structure.

The migration approach: extract current book value and accumulated depreciation per asset from GP's FABKDET table, create assets in Odoo with current net book value, and configure depreciation going forward based on the remaining useful life. Don't try to migrate the full historical depreciation schedule — rebuild the forward projection in Odoo correctly.

Plan for manual validation on every asset in the register. Fixed asset discrepancies between GP and Odoo are the most common source of audit questions in the first year after migration.

What Not to Migrate

The most underappreciated data migration decision is what to leave behind:

Closed historical AP and AR detail. Do not migrate individual paid invoices and closed purchase orders from years prior to your cutoff. Migrate the summary balances at cutoff date only. Keep GP in read-only mode for 12-18 months so anyone who needs to look up a specific historical invoice can find it. After 18 months, the lookups will be rare enough that a read-only archived GP database is sufficient.

Custom GP reports. GP's report writer (Dexterity-based) reports don't translate to Odoo's reporting engine. Don't try to replicate them one-for-one. Use the migration as an opportunity to rebuild reports in Odoo's native tools — most of them will be faster and more useful in Odoo than they were in GP.

Inactive customers and vendors with no open balance. Every ERP migration is an opportunity to clean the master data. Customers inactive for 5+ years with no open AR don't need to live in Odoo. Purge them from the migration list and document the decision.

Data Validation Checklist

Before you cut over to Odoo, these numbers need to match between GP and Odoo to the penny:

• AR aging total in Odoo equals AR aging total in GP at cutover date
• AP aging total in Odoo equals AP aging total in GP at cutover date
• Inventory value per category matches GP inventory valuation report
• Beginning balance sheet in Odoo balances (Assets = Liabilities + Equity)
• Trial balance totals in Odoo match GP trial balance at cutover date
• Open purchase order commitments match between systems

Run this validation at least twice before go-live — once in your test migration and once in your final migration with the most recent GP data. Discrepancies found in the test migration are expected and fixable. Discrepancies found after go-live require journal entry corrections and explanations to your auditor.

Timeline for a 50-100 Person Company

Have This Conversation Before You Sign With Any Vendor

Every GP migration proposal includes a line item for "data migration." What's inside that line item varies enormously between vendors. Some include only master data (customers, vendors, items) and expect you to handle transaction history separately. Some include ETL scripts but don't include the validation work. Some include everything but use optimistic assumptions about data quality that fall apart when they actually open the GP database.

Before you sign, ask your implementation vendor to describe their ETL approach for GP transaction history specifically. Ask how they handle COA mapping from GP to Odoo. Ask what they do when they find data quality problems in the GP source. The answers to these three questions will tell you whether they've done a GP migration before or whether you're their first one.