Migrating from Dynamics GP to QuickBooks Online

Nobody likes admitting they were over-served by their ERP. But a meaningful share of the Dynamics GP install base is running a full mid-market ERP to do what is, today, a small company’s accounting. If that is you, moving to QuickBooks Online (QBO) is not a step backward. It is right-sizing, and it is usually the cheapest and fastest way off GP before Microsoft’s support and tax-update deadline on December 31, 20291.

The alternative, buying and implementing a full ERP you do not actually need, is expensive by any measure. The median ERP project in 2024 cost $450,000 and took 15.5 months to reach go-live2, and even among organizations that planned for it, only 55% landed on budget and only 58% landed on schedule2. If your real requirement is a clean general ledger, working AR and AP, and financials your auditor trusts, that is not a bill you should be paying. This page is the honest version of both sides: where QBO is genuinely the right, cheaper answer, and where it is not.

Who QBO genuinely fits

QBO is a good landing spot when most of the following are true:

• You are a single legal entity, or two at most, and you do not need automated intercompany eliminations.
• Your chart of accounts and reporting needs are simple. You are not slicing the P&L by department, project, location, and product line all at once.
• Transaction volume is modest: hundreds of invoices a month, not tens of thousands.
• Inventory is light or nonexistent. You are a services firm, a holding company, or you sell a small catalog without lot tracking, serial numbers, or multi-warehouse logic.
• Your GP customizations were about GP, not about your business. If your Dexterity mods and Integration Manager jobs existed mainly to work around GP’s age, you will not miss them.
• Payroll is either outsourced already or small enough to hand to a payroll service. GP payroll users face the hardest deadline, since tax-table updates stop after 2029, and QBO Payroll or an outside bureau solves that cleanly for small headcounts.

A common profile: a company that was 120 people when it bought Great Plains, is 25 people now, and runs GP as an expensive general ledger. Under the hood that usually looks like a thin GL20000/GL30000 pair (open-year and historical transactions), a Receivables Management module handling a few hundred invoices a month out of RM00101 and RM20101, and a Payables Management module doing the same for a short vendor list in PM00200 and PM20000. None of that needs an ERP’s worth of machinery underneath it. QBO plus a good payroll bureau will cost a fraction of a Business Central or NetSuite implementation and take weeks, not months.

General ledger, or ERP: the question that actually matters

Every GP shop starts by asking “what do we replace GP with.” The better question is narrower: were you ever running GP as an ERP, or were you running it as an accounting system that happened to ship inside ERP packaging?

An ERP earns its cost and complexity by coordinating operations, not just recording them after the fact: inventory that moves through warehouses, purchase orders that turn into receipts that turn into payables, projects with allocations and revenue recognition, manufacturing orders with routings and bills of material, multiple legal entities that need to consolidate on close. If none of that describes your business today, and none of it is on a credible two-year roadmap, you do not have an ERP requirement. You have a general ledger requirement with an AR clerk and an AP clerk attached, and that is exactly what QBO was built to serve well. Paying $450,000 and waiting 15.5 months to re-platform a general ledger is not diligence, it is inertia dressed up as caution.

You will outgrow QBO if…

Be honest with yourself before you commit, because a second migration in three years is the most expensive outcome on this whole site.

You will outgrow QBO if:

• You have, or plan to have, three or more entities. QBO has no native consolidation. Each entity is a separate subscription, and you consolidate in spreadsheets or a bolt-on.
• You rely on GP’s analytical structure. QBO gives you Classes and Locations, and Advanced adds custom fields. That is two working dimensions. If your Management Reporter trees slice by four segments today, or you lean on GP’s Analytical Accounting module for multi-dimensional coding, QBO cannot reproduce that reporting.
• Inventory is core to the business. Landed cost, lot and serial tracking, multiple warehouses, assembly or light manufacturing: QBO handles none of this well, even on the Advanced tier.
• You process high volume. QBO Advanced has hard usage limits and practical performance limits. Companies posting thousands of lines a day through SOP or POP feel it.
• You need real approval workflows, commitment accounting, encumbrances, or revenue recognition beyond the basics.
• Auditors or lenders expect ERP-grade controls: field-level security, granular audit trails, posting controls comparable to GP’s batch posting discipline.
• You run GP’s Multicurrency Management module across several active currencies with revaluation and realized/unrealized gain and loss tracking. QBO’s multicurrency handles the basics but not the depth GP shops with real treasury operations expect.

If two or more of these describe you, look at Business Central or NetSuite instead, or Odoo if you also need operational modules beyond finance. Paying more once beats paying twice.

What you lose versus GP

It helps to name the losses explicitly, because your accounting team will feel them on day one.

The batch posting point deserves emphasis. GP-trained controllers rely on unposted batches as a review gate before anything hits the ledger. QBO has no equivalent; entries hit the ledger the moment they are saved. Your close process needs a new review discipline, usually a combination of user permissions and a month-end checklist rather than a batch-and-release workflow.

The cloud shift already happened, and it cuts both ways

It is worth naming the market context, because it argues for QBO and against it at the same time. Among organizations that replaced an ERP system in 2024, 78.6% chose a cloud or SaaS platform over on-premise, up from 65% choosing cloud the year before2, and 70.9% of those specifically chose a true multi-tenant SaaS deployment rather than a hosted or managed model, up from 52% the prior year2. GP has no SaaS version of its own; whatever replaces it, the market has already voted for cloud.

QBO is cloud-native, so on that count it is aligned with where every peer company is heading, and that is part of why it is a defensible choice for a GP shop that only ever needed a ledger. But read the same data the other way: the organizations driving that 78.6% figure were mostly replacing one ERP with another, not downsizing into small-business accounting software. If your real requirement is ERP-grade operations, the cloud shift argues for a cloud ERP such as Business Central, NetSuite, or Odoo, not for stretching QBO past its design center. The trend favors cloud. It does not favor understaffing your systems to match.

It is also worth noting plainly what this stat bank does not contain: a verified count of QBO’s own subscriber base. Intuit publishes marketing figures from time to time, but none met the bar for a sourced, independently checked number here, so none appears on this page. What is verifiable, and what actually matters for a GP shop’s decision, is the cost and risk of the alternative shown above.

None of this is theoretical if you sit on your hands. Microsoft stopped selling new perpetual Dynamics GP licenses on April 1, 2025, and will end all new subscription-license sales on April 1, 20263. Whichever way you go, QBO or a full ERP, it will not be more GP: that product line is closed to new purchases regardless of what you decide here.

The data migration reality

This is where expectations most often go wrong, so here it is plainly: you will not bring your full GP history into QBO, and you should not try.

What works well:

• Master records: customers (RM00101), vendors (PM00200), items in simplified form (IV00101), and a rationalized chart of accounts. This is also your once-a-decade chance to kill the accounts that have not moved in years.
• Opening balances: trial balance as of cutover, pulled from GL20000, ideally at a clean month or year end.
• Open transactions: open AR invoices out of RM20101, open AP bills out of PM20000, open credits, and unreconciled bank items. These re-key or import cleanly and give you working subledgers on day one.

What does not:

• Historical posted transactions. Ten or twenty years of GP detail sitting in GL30000, RM30101, PM30200, and SOP30200 has no realistic home in QBO. Import tools that promise “full history” typically bring summarized journal entries that satisfy nobody and clutter the new file.
• Payroll history. Employee year-to-date detail, W-2 and T4 history, and old tax filings stay in GP or move into your payroll provider’s onboarding process, not into QBO.

Data migration is also where ERP-scale projects go wrong industry-wide, which is exactly why this page recommends not attempting a heavier lift than QBO needs. Gartner has found that 83% of data migration projects either fail outright or exceed their planned budget and schedule4, and in Panorama’s 2024 sample, data issues were named as a contributing cause by 34.9% of organizations that went over budget and 46.3% of those that went over schedule2. A QBO cutover that sticks to master data plus opening and open balances sidesteps almost all of that risk, because it never attempts the heavy historical conversion that causes it.

The standard answer for history is an archive: keep a read-only copy of the GP SQL databases, or extract the key tables (GL30000, RM30101, PM30200, SOP30200, and the UPR payroll history tables if applicable) into a reporting database, so you can answer audits and customer disputes without keeping GP itself running. Budget for this; it is cheap compared to any attempt to force history into QBO. Do it before April 30, 2031, when security updates end and the system is frozen, and preferably years before1.

One practical note on timing: clear or post every unposted batch before you extract balances. An unposted batch sitting in GP at cutover is the classic source of a trial balance that will not tie, and it is much cheaper to resolve while GP is still live than to reconstruct after the fact.

QBO plus bolt-ons, or a real ERP?

QBO’s marketplace can stretch it: Fathom or Reach Reporting for consolidated financials, SOS Inventory or Katana for inventory, Ramp or Bill for AP workflow, a payroll bureau for Canadian payroll. For a company just over QBO’s natural line, one or two bolt-ons is a fine, cheap answer, and it is often less total cost than jumping straight to an ERP.

But there is a tipping point. When you are stacking three or more apps to recreate what an ERP does natively, you have rebuilt an ERP out of duct tape: more vendors, more sync failures, more monthly fees, and reconciliation gaps between systems that did not exist inside a single GP database. At that point, the honest move is to stop stretching QBO and buy the system that already does the job.

How to decide quickly

A useful shortcut: list every SmartList, Management Reporter report, Integration Manager job, and ISV module you actually used in the last 12 months. If the list is short and generic, you are a QBO candidate. If it is long and specific to how your business runs, you are not, and no discount on QBO subscriptions will change that.

A second shortcut, cruder but effective: add up what you would spend on QBO plus bolt-ons for three years, and compare it honestly to the $450,000 median and 15.5-month median for a full ERP project2. If the bolt-on stack costs a fraction of that and covers everything you actually do, the math itself is telling you the ERP was always more than you needed. If the bolt-on stack is creeping toward ERP pricing without delivering ERP capability, the math is telling you the opposite.

If you want a second opinion on which side of the line you are on, that is exactly the kind of question a short assessment call settles. Webisoft does the migrations either way, to QBO or to a full ERP, so we have no stake in selling you the bigger system.