Dynamics GP to Odoo: A Step-by-Step Migration Guide
You've decided to move off Dynamics GP. Maybe it was the December 2029 end-of-support deadline, the per-user licensing sticker shock when you ran the Business Central quote, or the realization that GP hasn't shipped a meaningful feature in years. The decision is made. Now comes the part nobody writes about clearly: how do you actually do it?
This guide covers the full migration from GP to Odoo — the phases, the data work, the decisions that trip people up, and the first 90 days after go-live. It's written for COOs, IT Directors, and finance leaders who need to understand what they're signing up for, not a sales pitch for why you should migrate.
Before You Start: Set Expectations Correctly
A GP-to-Odoo migration is not a data export and import. It's a business transformation that happens to involve software. Two things will determine whether it succeeds or fails more than any technical factor:
Executive sponsorship with teeth. Someone in the C-suite needs to own this project, make decisions when departments disagree, and protect the timeline from scope creep. Every ERP migration that drifts 12 months past schedule has the same root cause: nobody had the authority to say no.
Internal project ownership. You need one internal person — not the consultant, not the IT vendor — whose job it is to drive this migration. They coordinate department leads, gather requirements, manage UAT, and own the cutover checklist. The best consulting team in the world can't compensate for no internal owner.
Scope it before you start: The three most common scope creep triggers in GP migrations are (1) "while we're at it" requests from departments that weren't in the original requirements, (2) custom GP reports that nobody documented but everyone depends on, and (3) third-party integrations that GP was talking to that nobody mentioned during scoping. Surface all three before Phase 1 begins.
The Five Phases
This is the phase most companies skip or compress. Don't. Decisions made here determine whether every downstream phase runs on schedule.
Data audit: Pull a full inventory of what's in GP. Chart of accounts, vendors, customers, open purchase orders, open sales orders, inventory items, historical transactions (how many years back?), and any customizations baked into GP reports or SmartLists.
Module mapping: Which GP modules are you using? General Ledger, Payables, Receivables, Inventory, Purchase Order, Sales Order, Fixed Assets, Payroll? Each one maps to specific Odoo modules. The mapping determines implementation scope and cost.
Integration inventory: What is GP talking to? Payroll processors, e-commerce platforms, shipping systems, industry-specific software, EDI trading partners, banks for ACH/EFT? Every integration needs a migration plan.
Clean-up decision: Should you migrate historical data or just open transactions? This is a cost and risk tradeoff. Historical transaction migration is expensive and error-prone. Most companies migrate open AP, open AR, open POs, current inventory, and chart of accounts — and archive GP for historical lookup.
With scope defined, the implementation team stands up the Odoo environment and configures the base system before any data migration begins.
Hosting decision: Odoo.sh (Odoo's managed cloud), Odoo Online (SaaS), or self-hosted on your infrastructure or a cloud provider. Most mid-market GP migrations land on Odoo.sh — managed infrastructure without full SaaS constraints.
Module activation and base configuration:
- Chart of accounts — import and validate against GP structure
- Tax configuration (US sales tax, if applicable)
- Fiscal years, currencies, company settings
- User roles and access rights mapped to GP user groups
- Warehouse and inventory locations if relevant
Custom development scoping: Any GP customizations (VBA macros, Modifier/Report Writer customizations, third-party add-ons) that need to be replicated in Odoo get scoped and estimated here. This is typically where budget surprises emerge — surface it early.
The most technically complex phase. GP stores data in SQL Server — that's the one advantage. The data is accessible, structured, and queryable. The work is transformation, not extraction.
What to Migrate
- Master data: Chart of accounts, vendors (with payment terms, bank accounts), customers (with credit limits, payment terms), inventory items (with unit of measure, cost, reorder points)
- Open transactions: Open AP invoices and vendor credits, open AR invoices and customer credits, open POs and SOs, current inventory quantities and valuation
- Beginning balances: GL account balances as of cutover date
What to Leave Behind
- Closed/paid transactions (archive in GP or export to Excel)
- Historical transaction detail beyond open balances
- GP-specific configuration tables that don't map to Odoo
The vendor/customer duplicate problem: GP databases accumulate years of duplicate and inactive records — vendors with three slightly different name variants, customers from acquisitions with overlapping account numbers, items that were "inactivated" but never cleaned up. Before migrating, run de-duplication against your GP master data. Migrating dirty data into Odoo doesn't fix it — it embeds it.
Migration Tooling
There is no single GP-to-Odoo migration tool. The standard approach is SQL extraction scripts (GP's schema is well-documented) combined with Odoo's import framework or XML-RPC/JSON-RPC API for programmatic loading. Custom transformation scripts handle the mapping between GP's data model and Odoo's. Plan for 2–3 migration test runs before the production cutover.
While the data migration team is cleaning and transforming data, the functional configuration team is building out the Odoo environment.
Workflow configuration: AP approval workflows, PO approval limits, AR dunning sequences, inventory reorder automation. These replace manual processes that GP users handled outside the system (usually in email).
Report development: GP's built-in reports and SmartLists need Odoo equivalents. Odoo's reporting engine handles most standard financial reports natively. Custom reports (operational dashboards, industry-specific formats) require development time. Audit which GP reports are actually used weekly vs. monthly vs. "we ran it once in 2019."
Integration development: Third-party integrations built during this phase. Priority order: payroll, banking/ACH, then operational integrations. Odoo has a REST API and webhook framework — most modern systems can integrate without middleware. Legacy systems may need an integration layer.
User training preparation: Build training materials from actual configured workflows, not vendor demos. GP users will find Odoo's UI more intuitive in most areas, but the mental model shift from GP's document-centric approach to Odoo's object-centric approach takes time.
User acceptance testing is where you find the requirements you didn't know you had. Budget for it generously.
UAT structure: Each department lead runs their end-to-end processes in Odoo against the test environment. Finance processes a full AP cycle. Operations runs a PO-to-receipt-to-invoice cycle. Sales runs a quote-to-order-to-invoice cycle. Document every exception — don't resolve them verbally in a meeting.
Parallel run decision: Running GP and Odoo simultaneously for 2–4 weeks before cutover is the lowest-risk approach. It's also the highest-cost in terms of user time. For most mid-market companies, a single cutover with a 48-hour validation window is more practical than a true parallel run. Reserve parallel runs for companies with complex intercompany transactions or tight regulatory requirements.
Cutover rehearsal: Run the full cutover sequence at least once in a staging environment before production. The cutover checklist should be detailed enough that any trained team member could execute it. Every step timed. Every dependency documented.
The cutover window is typically a weekend. GP is frozen as of end-of-business Friday. The cutover team loads final open transaction balances into Odoo on Saturday. Validation runs Sunday. Monday morning, users are on Odoo.
Cutover sequence:
- GP freeze — no new transactions after cutover date
- Final data extract — open AP, open AR, open POs/SOs, inventory counts
- Load and validate in Odoo production environment
- GL beginning balance entry and trial balance reconciliation
- Integration smoke tests — payroll, banking, key third parties
- User access validation — every role, every module
- Go/no-go decision by project owner (not the consulting team)
- Go-live communication to all users
Keep GP accessible read-only for 90 days post-cutover. You will need it for historical lookups, audit questions, and the inevitable "wait, what was that transaction in November?" request.
The First 90 Days Post Go-Live
Most ERP migrations are declared successful at go-live. That's the wrong milestone. The real test is whether the business runs smoothly 90 days later without the implementation team on speed dial.
Days 1–30: Stabilization. The implementation team should be on high availability. Expect 2–3x the normal support volume. Common issues: users hitting permission errors for edge-case workflows, reports that weren't validated in UAT, AP/AR processes that have exceptions nobody documented. Triage everything, fix critical issues within 24 hours, schedule non-critical issues for week 4.
Days 30–60: Optimization. Now that the team is familiar with Odoo, they start identifying ways to work better — not just replicate GP processes. Automate the vendor invoice email-to-draft workflow. Set up automated AR aging reports. Configure inventory reorder rules. This is where the investment starts returning ROI.
Days 60–90: Independence. The internal Odoo admin should be handling routine configuration changes without consulting support. New users should be onboarded from internal training materials, not from the implementation team. Schedule a 90-day retrospective: what worked, what was missed, what comes next in the roadmap.
The Five Mistakes That Derail GP Migrations
1. Migrating too much historical data. Every year of historical transaction detail you migrate adds weeks to the project and something to break. Migrate open balances and archive the rest. GP stays available read-only for lookups.
2. Under-scoping the integration work. "We just have a payroll integration" is almost never true. There's also the bank feed, the expense management tool, the industry-specific add-on, and the Excel macro that someone runs every Friday that technically counts as an integration.
3. Training users on GP workflows instead of Odoo workflows. The temptation is to replicate every GP process exactly in Odoo. Resist it. Odoo was designed differently — its workflows are often simpler and more automated. Train users on the Odoo way, not the GP way wrapped in Odoo skin.
4. No internal project owner. Consulting teams can execute. They can't own. Someone on your team needs to own the cutover checklist, escalate blockers to the C-suite, and make scope decisions. Without that person, scope creep and timeline drift are inevitable.
5. Going live at month-end or during close. Pick a go-live date two weeks before month-end. Your finance team needs time to learn the close process in Odoo before they're under deadline pressure. Going live on the last Friday of the month is a stress test nobody needs.
What This Takes in Time and Budget
For a company with 50–200 users, moving standard GP modules (GL, AP, AR, Inventory, PO, SO) to Odoo:
- Timeline: 6–9 months for a clean migration; 9–12 months with heavy customization or complex integrations
- Implementation cost: $60,000–$150,000 depending on scope, integrations, and data complexity
- Internal time commitment: Project owner at 25–40% of capacity during active phases; department leads at 10–20% during UAT
- Odoo licensing after go-live: $24–36/user/month for Enterprise (vs. the Business Central quote you likely have sitting somewhere)
The planning window is now: Companies that start planning in 2026 choose their implementation partner, run a structured migration, and go live with time to stabilize before GP's December 2029 EOL. Companies that wait until 2028 compete with 28,000 other GP shops for implementation slots and either rush the migration or pay premium rates for whatever capacity remains.
Talk to Someone Who's Done This
We've migrated GP environments to Odoo. We know where the data bodies are buried and which integrations always surprise people. If you're planning a migration, a free scoping call is the right first step — not a demo.
Schedule a Free Migration Assessment