Migrating from Dynamics GP to Odoo

Every other destination page on this site works hard at neutrality. This one comes with a disclosure instead: when a GP shop asks us where to go and nothing in their situation argues otherwise, we recommend Odoo. Not because we resell it (we do not, and nobody pays us when you choose it), but because of a lesson GP customers just learned the expensive way. You spent decades building on a product, and the vendor ended it anyway. Odoo is the destination where that cannot happen again, and the rest of this page is the honest case for it, including the parts that should push some readers to Business Central or QuickBooks instead.

The argument in one paragraph

Odoo is a full ERP suite (accounting, inventory, purchasing, manufacturing, sales, CRM, projects, HR, and more, activated module by module) built on an open source core. You can run it on your own servers or in any cloud, and the code that runs your business is code you hold. Microsoft could end GP because GP was always Microsoft’s product; nobody can end an open source system you host yourself. For companies that just watched a 30-year product get a termination date, that is not an ideological point. It is risk management. The sections below back that argument with numbers rather than assertions: how widely Odoo is actually used, what the ERP market as a whole is doing with cloud and ownership, and what it costs against the two products GP shops compare it to most.

The numbers behind the recommendation

Three figures frame this decision, and each needs its caveat stated plainly rather than buried in a footnote.

The first number is Odoo’s own claim, stated on its own “About Us” page, and it should be read as exactly that: a vendor-reported figure, not an audited count.1 Odoo does not publish methodology for how it counts a “user,” and independent industry estimates of its actual active install base run considerably lower, commonly placed somewhere in the single-digit to mid-teens millions rather than 28 million. Both things can be true at once: Odoo is genuinely one of the most widely deployed ERP systems in the world, and its own headline number is marketing, not audit. We cite it here because it is the figure Odoo puts in front of every prospect, and you deserve to know where it comes from before you see it in a sales deck.

The second number matters more than it looks. It is not an Odoo statistic at all, it is a snapshot of what every ERP buyer, GP shops included, is doing right now: choosing cloud over on-premise by a wide and growing margin.2 That context sets up the section below, because “cloud” and “vendor lock-in” are not the same thing, and Odoo is one of the few mainstream ERPs where you can have the first without conceding the second.

The third number is the economics argument in miniature, and we expand it with real figures later in this page rather than rounding it off here.

Who Odoo fits, and who it does not

Odoo fits the GP shops that GP actually served: product and services companies that needed solid financials plus real operations (distribution, light manufacturing, projects) and molded their system to fit. It is the strongest candidate when:

• You customized GP heavily and it paid off. Dexterity, Modifier with VBA, eConnect: if those layers encode how your business runs, you need a destination that welcomes that kind of work. Odoo’s framework is built for it, and the result is modules you own rather than scripts trapped in a dying product.
• Your user count makes per-seat Microsoft or Oracle pricing hurt. Subscription ERP pricing compounds, and at 30, 60, 100 users the difference between Odoo and Business Central or NetSuite, compounded over a decade, is serious money. We put real published numbers behind this later in this page; run the comparison on current pricing for your own seat count and the gap will speak for itself.
• You want one system instead of a stack. GP shops often run a bolt-on constellation: CRM here, field service there, an ecommerce bridge, a reporting tool. Odoo’s modules share one database and one data model, which removes a whole category of integration work.
• You never want to be sunset again. Self-hosted or on Odoo’s own hosting, the software is yours to run. Even Odoo Enterprise ships with source code, and the Community core is LGPL. If Odoo the company changed direction tomorrow, your system keeps working and any competent Python team can maintain it.

Odoo fits less well when:

• You want the smallest possible change. If GP was doing light financials and the honest answer is a simpler book of record, QuickBooks Online plus a couple of apps is cheaper and faster. Do not implement an ERP suite to replace a general ledger.
• You are all-in on Microsoft 365 and that is a feature. If your team lives in Outlook, Teams, and Power BI and your IT department thinks in Azure and Entra, Business Central’s native integration with that world is real and Odoo does not match it. Odoo connects to Microsoft services; BC is a Microsoft service.
• Your board buys logos. Some organizations need the comfort of a tier-one vendor name on the ERP line item, and no engineering argument changes that. That is a governance reality, not a technical one, but it decides projects.

Why open source still matters even as the market moves to cloud

It would be easy to read that chart and conclude the industry has settled the cloud question, and in one sense it has. But look closer at the same survey: within that cloud majority, 70.9% specifically chose a true multi-tenant SaaS deployment, versus 29.1% choosing a hosted or managed-services model, up from only 52% choosing SaaS the year before.2 That distinction matters, because SaaS and self-hosted-in-the-cloud are not the same commitment. Pure SaaS means the vendor owns the infrastructure, the upgrade schedule, and ultimately the decision about whether your product keeps existing. GP customers just lived through what that means when the vendor decides otherwise.

Odoo is one of the few mainstream ERPs where you do not have to choose between modern cloud convenience and ownership. Odoo Online is genuine SaaS, and Odoo.sh is Odoo’s own managed platform with CI/CD-style staging and production branches, both of which give you the operational ease buyers are voting for in that chart. But because the underlying application is open source under the LGPL, you are never locked into either. You can move to Odoo.sh, move to your own infrastructure, or move to a different hosting partner entirely, and the software keeps running because you hold the code, the database is standard PostgreSQL, and nothing about the license requires a subscription to function. That is the practical difference between “our vendor lets us use the cloud” and “our vendor requires it.”

What actually changes

Three of these deserve emphasis.

Customization is the point, not the risk. On most cloud ERPs, customization advice starts with “try not to.” Odoo inverts that: the entire product is modules built on a documented Python framework, and your customizations are modules of exactly the same kind. This is the closest thing on the market to how GP shops actually used Dexterity, with one crucial upgrade: the code lives in your repository, under version control, portable across hosting. Readers of our custom-software page will recognize the shape. Odoo is the packaged core with custom edges that page recommends, delivered as one platform instead of two systems stitched together.

You keep database access. Business Central online closes the direct SQL door that many GP shops quietly depend on. Self-hosted Odoo leaves it open: it runs on PostgreSQL, and your warehouse jobs, custom views, and reporting tools can read it directly. If losing SQL access was on your list of BC worries, this is the single biggest practical difference.

Editions and hosting are a real decision. Odoo Community is the open source core; Odoo Enterprise adds the full accounting application, more advanced modules, and support, licensed per user. Most GP replacements land on Enterprise because full accounting matters, and Enterprise still permits self-hosting with source access. Hosting comes in three flavors: Odoo Online (simplest, but no custom code modules, so usually wrong for ex-GP shops), Odoo.sh (Odoo’s managed platform, custom modules allowed, with staging branches and automated testing pipelines built in), and self-hosted (maximum control, your infrastructure responsibility). Companies that expect to iterate on custom modules frequently tend to prefer Odoo.sh early and consider migrating to fully self-hosted once the module set stabilizes. Choose deliberately in design, not by default.

The economics: seat pricing at scale

Put real numbers on the three products GP shops compare most, and the pattern that shows up in nearly every comparison holds. Microsoft prices Dynamics 365 Business Central at $80 per user per month for Essentials and $110 per user per month for Premium, with a lighter $8 per user per month “Team Member” tier for light users, list pricing effective November 1, 2025.3 Oracle does not publish a NetSuite price list at all; every contract is individually negotiated, but aggregated figures from NetSuite implementation partners consistently land in the $129 to $199 per user per month range for full users, on top of a base platform fee of roughly $999 per month, with implementation itself typically running $25,000 to $500,000 or more as a separate one-time cost.4

Odoo does not have an equivalent single published number, and we are not going to invent one here. What we can say honestly, from running these comparisons for actual GP shops, is that Odoo Enterprise per-user pricing consistently comes in well below Business Central Premium and further still below NetSuite for a comparable set of modules, and the gap widens rather than narrows as seat count grows. That happens for a structural reason, not a promotional one: Business Central and NetSuite both price linearly per user with little relief at scale, while a meaningful share of Odoo’s cost (self-hosted infrastructure, or a flat Odoo.sh plan tier) does not scale one-for-one with headcount the same way. A 20-user company will feel a moderate gap. A 100-user company usually finds it decisive.

None of this replaces a real quote. List prices are a starting point, not a street price. Microsoft partners and CSPs routinely discount Business Central from list, NetSuite pricing is explicitly negotiated deal by deal, and Odoo pricing depends on which modules you actually license and who implements them. Treat the figure above as a reason to run the numbers for your own seat count, not as a number to quote back to a board.

How the migration actually runs

The playbook mirrors any competent GP exit, with one Odoo-specific advantage in the data step:

1. Inventory. Catalogue companies, modules, Dexterity and Modifier customizations, Integration Manager and eConnect jobs, ISV add-ons, reports, and integrations. Get specific about the tables underneath the GP screens you rely on: customer and vendor masters (RM00101, PM00200), the account master (GL00100), item cards (IV00101), and open sales and purchase order tables (SOP10100, POP10100) are the ones most GP shops end up querying directly at some point, and knowing which reports or exports already reach into them changes your integration count. A week or two that determines everything else.
2. Design. New chart of accounts with analytic structure, module selection (turn on only what you use), a decision on each customization (rebuild as a module, replace with a standard app, or drop), edition and hosting choice, payroll approach, and a data-history policy.
3. Data migration. Masters and open transactions first, cleaned before they move. Because Odoo exposes its data model through the ORM and XML-RPC, and because its import wizard accepts structured CSV or Excel loads out of the box, an engineering team can script and re-run loads from the GP tables identified in step one rather than working through a closed vendor import tool. That also makes bringing extra history more feasible here than on most cloud ERPs. It still costs effort; decide how much history earns its keep and archive the rest read-only.
4. Build and integrate. Custom modules for the workflows that justified them, standard apps for everything else, integrations over Odoo’s APIs, rebuilt reports.
5. Parallel testing and cutover. At least one full close in both systems, reconciled to the penny, users trained on real data, cutover at a month or quarter boundary. GP keeps working through December 31, 2029 for support and tax purposes, so use the runway and never big-bang.

The honest tradeoffs

The partner point deserves a plain sentence, because it is the one that bites hardest. Odoo’s flexibility means outcomes depend on who builds it more than the product itself. The same platform that gives an engineering team room to do excellent work gives a careless one room to do damage, and the Odoo channel has both. Whoever you hire, apply the same tests we give for custom software: written specifications, code in your repository, and a continuity plan.

How Webisoft thinks about it

We are engineers, and Odoo is the destination where engineering is the product. We implement and extend it; we do not resell subscriptions, so our recommendation does not earn us a commission either way. When a GP shop comes to us, Odoo is our default recommendation, and the reasons are the ones above: it keeps the moldability that made GP worth keeping for 30 years, it consolidates the bolt-on stack, its economics favor real user counts, and it is the one path where the next end-of-life announcement cannot be aimed at you.

Default does not mean universal. We send Microsoft-stack shops to Business Central and downsizing shops to QuickBooks, and we say so in writing on those pages. Odoo’s own reported 28 million user figure is marketing, the industry’s swing to cloud does not require giving up ownership, and its seat pricing advantage only holds up once you have an actual quote in hand, but none of those caveats change the bottom line for the shops this page is written for. If you loved what GP let you build and hated how it ended, Odoo is the migration that fixes both. The cheap next step is the same as ever: a short technical review of your GP environment, mapping what you actually use to Odoo modules and surfacing the customizations that need real design. That produces a scoped plan and a defensible decision, whichever way it lands.