Migrating from Dynamics GP to Microsoft Dynamics 365 Business Central
Here's the thing most GP partners won't tell you upfront: GP and Business Central don't share a data model. They came from entirely different product lines that Microsoft acquired separately, so this isn't an "upgrade" in the way NAV-to-BC is — it's a proper reimplementation. That's not a reason to avoid it. It's a reason to plan it properly, which is exactly what a rushed like-for-like migration usually fails to do.
Book a GP Migration Assessment
Why Dynamics GP customers are looking at Business Central
Microsoft has been steadily signalling that GP is not where its long-term Dynamics investment is going, unlike Business Central, which gets two feature releases a year and native Copilot integration. For businesses still on GP, that means shrinking partner ecosystem, ageing Dexterity skills getting harder to find, and a platform that isn't gaining the cloud, AI or Power Platform capabilities its Microsoft siblings are.
Most GP customers we speak to have been running the same core setup for over a decade, often with Dexterity customisations built by a developer who's long since left the business, and eConnect integrations nobody's fully documented. That's normal. It's also exactly why we treat every GP migration as a proper discovery project rather than assume anything will just carry over.
Why GP-to-BC is a reimplementation, not an upgrade
GP's architecture
Built on Dexterity, with eConnect handling integrations and a table structure that has nothing in common with the NAV/Business Central lineage.
What that means practically
Data has to be mapped and transformed, not copied. Dexterity customisations and eConnect integrations need rebuilding as native BC extensions from scratch — there's no shortcut around this.
We say this upfront because a fair number of businesses get quoted a GP migration as if it were a simple version upgrade, then discover three months in that half the "migrated" customisations don't actually work. Scoping it as a reimplementation from day one avoids that entirely.
What migrates from GP, and what gets rebuilt
What we migrate
Chart of accounts, vendor and customer master data, open transactions and current balances, extracted via eConnect and transformed into BC's data structure.
What gets rebuilt, not migrated
Dexterity customisations, eConnect integrations, and any SmartList or Management Reporter customisations — these are rebuilt natively in BC as AL extensions and native Power BI reports.
The gotchas we check for first
Dexterity customisations nobody can fully explain
Custom scripts written years ago by a developer who's moved on are common. We document what each one actually does functionally before deciding how to replicate it in BC.
SmartLists and Management Reporter as the real reporting layer
If your finance team's actual reporting lives in SmartList views or Management Reporter rather than GP's native screens, that entire reporting layer needs rebuilding in native Power BI.
eConnect integrations to third-party systems
Payroll, EDI, or e-commerce integrations built on eConnect need their own migration plan — they don't carry over by simply "pointing them at BC instead."
A realistic GP-to-BC timeline
Discovery & Customisation Mapping
3–4 weeks documenting every Dexterity script, eConnect integration and reporting workaround currently in use.
Build & Rebuild
6–12 weeks configuring BC and rebuilding customisations as native extensions, scaling with GP's complexity.
UAT, Training & Go-Live
3–4 weeks testing thoroughly given the amount that's been rebuilt, plus role-based training.
What changes on the licensing side
GP licensing was typically a perpetual licence plus an annual enhancement plan, similar to older NAV. Business Central licenses per user, per month. Given that a GP migration is closer to a reimplementation than an upgrade, we'd rather be upfront that the bulk of project cost sits in the rebuild work, not the BC licence itself — anyone quoting otherwise probably hasn't scoped your customisations properly.
The GP customers making this move now
Distribution
Long-standing GP customers with heavy Dexterity customisation around inventory and pricing.
Manufacturing
Businesses whose GP setup was extended years ago for production and now needs a native replacement.
Multi-entity groups
Organisations running multiple GP companies looking for genuine cloud consolidation.
Businesses losing GP expertise
Companies whose internal or partner-side Dexterity knowledge has left, with nobody left who can maintain the system.
Why we won't quote a GP migration off a single call
Given how much of a GP migration is genuine rebuild work rather than data transfer, we insist on a proper discovery phase before quoting a fixed project cost. That means reviewing your Dexterity code, your eConnect integrations, and your actual reporting setup, not just your chart of accounts. It takes a bit longer up front. It avoids the mid-project surprises that make GP migrations expensive elsewhere.
What GP-to-BC migrations typically deliver
Aggregate results from recent NetMonkeys Business Central implementations.
Reporting ROI with native Power BI replacing SmartList and Management Reporter workarounds.
Yearly feature releases automatically applied, instead of ageing GP roadmap uncertainty.
Faster month-end close once manual GP reporting workarounds are retired.
Native Copilot and Power Platform access, unavailable in the legacy GP ecosystem.
Why migrate from GP with NetMonkeys
We Call It What It Is
We scope GP migrations as reimplementations from day one, not a quick upgrade sold short.
Dexterity & eConnect Literate
We know how to read what your existing customisations actually do before rebuilding them.
Microsoft Solutions Partner
Certified across Business Applications, re-verified annually.
UK Consultants
Every consultant and project manager is UK-employed.
Dynamics GP to Business Central: common questions
Is moving from GP to Business Central a straightforward upgrade?
No, and we'd rather tell you that upfront. GP and BC come from different product lines with different data structures, so this is closer to a full reimplementation than an upgrade — your data migrates, but your customisations need rebuilding.
What happens to our Dexterity customisations?
They don't carry over directly. We document what each customisation actually does, then rebuild the equivalent functionality as a native AL extension in Business Central.
Can you migrate our eConnect integrations?
The integrations themselves need rebuilding against Business Central's APIs, but yes — payroll, EDI and e-commerce connections built on eConnect all have a viable BC-side equivalent.
Why does a GP migration cost more than a NAV upgrade?
Because there's genuinely more rebuild work involved — NAV and BC share a data model and customisation approach; GP shares neither. The cost difference reflects real work, not a pricing markup.
How long does a typical GP migration take?
Most run 12–20 weeks from discovery to go-live, longer than a NAV upgrade or Sage migration, scaling with how much Dexterity customisation and eConnect integration is involved.
Still running Dynamics GP?
A free assessment of your GP setup, customisations and integrations, with an honest scope of what moving to Business Central would actually involve.
