Migrating from Dynamics GP to NetSuite

NetSuite is the most common non-Microsoft destination for GP customers, and the pattern behind those moves is consistent: the company has outgrown what GP was doing for it and wants the replacement to be a bigger step up than a like-for-like swap. Oracle NetSuite now serves roughly 40,000 organizations worldwide, a figure Oracle itself does not publish as an official real-time count; third-party estimates put the range closer to 38,000 to 44,000 depending on when and how you count1. Whichever number you use, the base is large, cloud-native from day one, and squarely aimed at the same mid-market and upper-mid-market companies GP has served for decades. Whether NetSuite is the right landing spot for your GP environment specifically is worth working through honestly, because it is excellent at some things GP shops need and expensive, in ways GP shops are not used to, at others.

Who NetSuite fits

Companies consolidating multiple entities. If you run several GP company databases and close them with intercompany journals, elimination spreadsheets, and a controller who reconciles in Excel every month end, NetSuite OneWorld is a genuine upgrade. Multi-entity, multi-currency, multi-book consolidation is native to the platform: subsidiaries, elimination entities, and consolidated reporting are built into the core data model rather than bolted on through a third-party consolidation add-in the way GP typically requires. This is the single most common reason GP shops choose NetSuite over Business Central, and it is not a marginal difference. GP’s Multicurrency Management module and its intercompany processing were designed for a smaller number of entities than most growth companies now operate; NetSuite was designed for dozens of subsidiaries from the start.

Companies that want one suite, not a stack. NetSuite bundles financials, inventory and order management, CRM, project accounting, and ecommerce into one data model, with one login and one permission system across all of it. If your current landscape is GP for the ledger, a separate CRM the sales team half uses, a bolted-on web store fed by nightly exports, and integration glue holding all three together, collapsing that into one system has real appeal. It also removes an entire category of GP-era maintenance: keeping eConnect or eOne SmartConnect integrations alive between systems that were never designed to talk to each other.

Companies growing out of the SMB bracket. NetSuite’s ceiling is higher than GP’s ever was and higher than Business Central’s in several specific areas. Revenue recognition under ASC 606, subscription and usage-based billing, multi-book accounting for statutory versus management reporting, and advanced approval workflows are all areas where NetSuite is materially more mature. Companies heading toward audit-heavy environments, private equity ownership, or an eventual public filing frequently pick NetSuite specifically for that headroom, even when a smaller system would technically cover today’s requirements.

Companies deliberately leaving Microsoft. Some teams, having watched GP wind down through a multi-year sunset process, do not want their next ERP tied to the roadmap of the same vendor. That is a coherent reason to look at NetSuite rather than Business Central. It deserves to be a considered decision made with eyes open about cost, not a reflex reaction to Microsoft’s GP announcement.

Who it does not fit

If you are a 15-user GP shop with one company database, straightforward distribution or light manufacturing, and a controller who lives in SmartList Builder and Excel, NetSuite is very likely more system and more money than you need. Business Central, or QuickBooks Online for the simplest cases, will cost less and demand less from your team. NetSuite implementations also assume a certain internal capacity: someone inside the company has to own the system on an ongoing basis, tune saved searches, and manage user roles and permissions. “The office manager who also does IT” is not enough for a NetSuite environment the way it sometimes was, barely, for GP.

US and Canadian payroll deserves a specific check before you commit. NetSuite offers SuitePeople payroll for US-based employees; Canadian payroll typically runs through a third-party service integrated into NetSuite rather than a native module. Either way, GP Payroll users are re-implementing payroll somewhere as part of this move, exactly as they would moving to Business Central or anywhere else.

The cloud shift GP shops are walking into

Part of what makes this decision feel unfamiliar to long-time GP administrators is that the whole market moved while GP stayed on-premise. In Panorama Consulting’s 2024 survey of organizations actively replacing an ERP system, 78.6 percent selected a cloud, hosted, or SaaS deployment for their new system, versus 21.4 percent choosing on-premise, up from only about 65 percent choosing cloud the year before2. Narrow that further to true multi-tenant SaaS specifically, and 70.9 percent of that same sample chose SaaS over managed hosting, up from roughly 52 percent the prior year2.

This matters for a GP-specific reason. GP was never a true SaaS product: it was on-premise or partner-hosted software, and there is no cloud-native version to grow into the way there is with Business Central or NetSuite. Every GP shop leaving the platform is, by definition, making this cloud move for the first time, all at once, rather than having eased into it over several product cycles the way companies on continuously-updated platforms did. NetSuite has been multi-tenant SaaS since it launched in 1998, decades before “cloud ERP” was a category; there is no on-premise edition, no version upgrade project, and no server to patch or replace. That is a real operational relief for a team used to GP’s periodic version upgrades and SQL Server maintenance windows. It is also, as the next section covers, part of why the pricing conversation is different from anything GP shops have negotiated before.

The honest case versus Business Central

Two points from that comparison deserve plain numbers, not just qualitative hedging, because this is the area where GP shops most often get surprised.

Cost. NetSuite licensing is modular: a base platform fee plus per-module fees plus per-user fees, none of it published. Typical street ranges reported by NetSuite implementation and reselling partners run about $999 per month for the base platform, plus roughly $129 to $199 per user per month depending on the license tier and modules attached, with implementation as a separate one-time cost typically running $25,000 to $500,000 or more depending on scope, entity count, and data volume3. Those are not vendor-published numbers. Oracle does not release a NetSuite price list; the figures above are partner-aggregated, negotiated, and non-public, assembled from what implementation firms report seeing across live deals, and they should be treated as a planning range rather than a quote. For comparison, Business Central’s published list pricing runs $80 per user per month for Essentials and $110 for Premium, with a $8 per user per month Team Member tier for light users, following a price increase effective November 1, 20254. That gap, a published $80 to $110 per full user against a negotiated $129 to $199 per full user before you have even added the base platform fee, is the single biggest reason GP shops that do not need OneWorld-grade consolidation end up on Business Central instead.

Ecosystem. With Business Central you stay in a world where your Microsoft partner, your Office 365 licenses, and your ERP roadmap pull in the same direction, and Microsoft’s own migration tooling assumes you are coming from GP. With NetSuite you are hiring into the Oracle ecosystem: NetSuite-certified administrators and SuiteScript developers, who are readily available in the market but are not the people who currently support your GP environment. That is not a reason to avoid NetSuite. It is a real transition cost that belongs in the same conversation as the license quote, not discovered six months after go-live.

What changes coming from GP

Customization model. Dexterity customizations, Modifier with VBA changes, and Integration Manager jobs all end at migration, exactly as they would moving to any modern system, because none of them have an equivalent inside another vendor’s platform. In NetSuite, their replacements are SuiteScript (server-side and client-side JavaScript running against the NetSuite record object model), SuiteFlow for workflow automation without code, and SuiteTalk or REST web services for external integration. This is a more accessible, better-documented model than Dexterity ever was, and it draws from a much larger developer pool. It is still a new skill set relative to what supports your GP environment today, and heavily customized GP shops, particularly ones with extensive Modifier/VBA work on the sales order or purchasing screens, should budget real development time to rebuild that logic in SuiteScript rather than assume it ports over.

Reporting. Management Reporter and SmartList Builder are replaced by NetSuite saved searches, standard financial reports, and SuiteAnalytics Workbook for ad hoc analysis. Saved searches are genuinely powerful, closer to a query builder than a canned report list, and they tend to become the daily tool your SmartList power users end up preferring within a quarter or two. Financial statement rebuilds take the usual disciplined effort regardless of destination: inventory what people actually run today out of Management Reporter, rebuild exactly that in NetSuite’s financial report builder, and let the reports nobody has opened in two years quietly die rather than migrating them for their own sake.

Implementation partners. NetSuite sells both direct through Oracle and through a large network of solution provider partners, and implementation quality varies widely across both channels. For a GP migration specifically, insist on a team that has moved companies off GP before and can talk fluently about GP’s data model, not just NetSuite’s side of the project. A partner who can explain, unprompted, how GP’s RM00101 customer master and PM00200 vendor master map into NetSuite’s customer and vendor records, or how SOP10100 open sales order data becomes an open sales order import, is a partner who has done this specific migration before. The partner decision predicts project success more reliably than any feature comparison does, and it is worth more diligence than the software selection itself.

Data migration considerations

The mechanics resemble any GP exit, with a few NetSuite-specific wrinkles worth planning around before anyone writes an import script.

• Masters and open transactions move; deep history is a decision, not a default. Customers and vendors from GP’s RM00101 and PM00200 master tables, items from IV00101, the chart of accounts, open AR and AP balances, and open purchase orders all come across cleanly through CSV imports or integration tooling such as SmartConnect or Celigo. Full posted history from GP’s GL20000 and GL30000 transaction tables is expensive to transform between two structurally different data models and rarely gets used once it lands. The pragmatic pattern most successful projects land on: bring open transactions plus monthly summary trial balances for two to three years, and keep the old GP database live and read-only for the handful of times a year someone needs to trace a transaction from 2021.
• Clean up in GP first, not during the migration. Post or clear unposted batches sitting in GL20000, resolve stale open transactions that have been sitting unreconciled for years, and deduplicate customer and vendor records before anyone maps a single field. Multi-company GP databases need a full entity-mapping exercise into NetSuite OneWorld subsidiaries before import scripts are written, because the subsidiary structure you choose in NetSuite determines how consolidation and eliminations behave for years afterward.
• Redesign the chart of accounts rather than transliterating it. NetSuite separates the account itself from segments such as department, class, location, and any custom segments you define, a materially different shape from a GP account string that often encoded location or department directly into the account number. This is the moment to simplify a chart of accounts that has accreted exceptions for a decade, not to recreate GP’s account structure inside a system built for a cleaner one.
• Reconcile like an auditor, in writing, before go-live. Trial balance by entity and by period, open AR and AP agings, and inventory valuation should tie between GP and NetSuite to the penny before cutover, with the reconciliation documented and signed off, not eyeballed. Given that Panorama’s 2024 survey found data issues cited as a contributing cause by 34.9 percent of ERP projects that went over budget and 46.3 percent that went over schedule, this reconciliation step is where GP-to-NetSuite projects most often lose the time and money they had planned to spend elsewhere.

A short decision framework

Before signing anything, three questions tend to separate genuine NetSuite fits from GP shops chasing a bigger system than they need.

1. Do you actually run multiple entities that need consolidation today, or might you within 18 months? If the honest answer is one company database and no near-term acquisition or subsidiary plan, OneWorld’s core advantage does not apply to you yet, and you are paying for headroom you may never use.
2. Can you name who inside the company will own NetSuite administration after go-live? Not the implementation partner, an internal owner. If that person does not exist yet, factor their hiring or training into the project timeline and cost before you sign, not after.
3. Have you modeled the renewal-year invoice, not just the first-year quote? Ask your NetSuite partner directly what typical renewal increases have looked like on comparable accounts, and put a cap in the contract rather than trusting goodwill three years from now.

The bottom line

Choose NetSuite when the destination is genuinely the point: you want stronger multi-entity consolidation, a single cloud suite instead of a systems stack, and headroom you have real reason to expect you will grow into, and you are willing to pay Oracle’s negotiated prices and adopt Oracle’s ecosystem to get all of that. Choose something else, likely Business Central, if you are moving primarily because GP is ending and your operational needs are what they have always been; in that case you would be buying capability you will not use with money you did not need to spend, at a price you cannot look up in advance. Either answer is respectable, and NetSuite is a genuinely strong product for the company it fits. The mistake is signing a negotiated, non-public contract without having done the arithmetic on the renewal year first.