Your upgrade path, mapped out honestly.
If you are running Dynamics NAV or Dynamics GP, you already know a move is coming. What is usually missing is a clear view of how much runway you actually have, which of the two routes forward suits your environment, and what the work genuinely involves, including the parts most partners leave out of the first conversation.
MicroCloud 360 has been migrating Microsoft ERP systems across Sri Lanka, Australia, Canada and the United States. This is the same briefing we give clients in a discovery call.
Where does your version stand?
Extended support ends
14 January 2025
What remains is extended support: security patches only, with no new features, no regulatory updates and no functional fixes.
Where you stand today
Two products, two timelines, one destination.
Dynamics NAV
Every NAV version has left mainstream support. What remains is extended support: security patches only, with no new features, no regulatory updates and no functional fixes.
Microsoft no longer sells new NAV licences, and there is no successor tier within the NAV product line. Business Central is the only supported forward path.
Extended support
| Version | Status | Support ends |
|---|---|---|
| NAV 2015 and earlier | Out of support | 14 January 2025 |
| NAV 2016 | Out of support | 14 April 2026 |
| NAV 2017 | Under six months remaining | 11 January 2027 |
| NAV 2018 (final release) | Supported | 11 January 2028 |
What makes a NAV move distinctive
Your customisations were written in C/AL, which Business Central online does not run. They have to be rebuilt as AL extensions, and the volume of that work is the largest single variable in any NAV project, far more so than data volume or company size.
Dynamics GP
GP runs on a longer timeline than NAV, but the direction is equally settled.
The GP timeline
New perpetual licences discontinued
1 April 2025 (already passed)
New subscription licences discontinued
1 April 2026 (already passed)
Enhancements, regulatory and tax updates, technical support end
31 December 2029
Final security updates
30 April 2031
What makes a GP move distinctive
- Your account structure has to be redesigned, not mapped.
- GP uses segmented account numbers; Business Central uses a main account plus dimensions. This is a design exercise rather than a translation, and it is worth treating as an opportunity: most organisations have carried segment structures for a decade longer than the reporting they were built for.
- GP customisations don't convert.
- Dexterity modifications, VBA and Modifier changes, Integration Manager routines and eConnect integrations have no equivalent in Business Central. Each needs a decision: rebuild as an AL extension, replace with standard functionality, or retire. A good proportion turn out to be retirable.
- Payroll needs its own answer.
- Business Central does not include US or Canadian payroll in the way GP does. Payroll typically moves to a dedicated payroll service or an ISV solution, integrated back into Business Central. This is entirely workable, but it is a separate decision and should be scoped early rather than discovered late.
- History is the big question.
- The GP migration path brings across master records and balances rather than full transactional history, so the archive strategy carries more weight here than it does on the NAV side.
You are seeing the Dynamics NAV path. Running Dynamics GP as well?
You are seeing the Dynamics GP path. Running Dynamics NAV as well?
What "out of support" actually means
Once support ends, Microsoft permanently stops issuing security patches, regulatory updates and critical fixes for that version. An unpatched system sitting at the centre of your financial data, banking connections and payroll becomes an exposure that grows every month, and one that increasingly complicates audits, insurance renewals, and certification under frameworks such as ISO 27001 and PCI-DSS.
The system will keep running. The risk of running it is what changes.
Why the destination is worth the journey
Support deadlines explain why you have to move. They don't explain why you would want to. These are the reasons clients give us afterwards.
Updates stop being projects
Microsoft ships Business Central twice a year and your extensions carry forward automatically. The version anxiety that governed NAV and GP planning for years simply ends: no upgrade budget cycle, no deciding whether this is the year you can afford to move.
There is no infrastructure left to maintain
No server refresh cycle. No SQL licensing. No patching weekend. No disaster recovery plan you have never quite got around to testing. For most organisations this removes an entire category of cost and an entire category of risk at the same time.
Copilot and AI are cloud-only
Reconciliation suggestions, cash flow and demand forecasting, and natural-language reporting are not coming to on-premises NAV or GP. They exist only in Business Central online, and the gap widens with every release.
A living ecosystem sits around it
Thousands of extensions on AppSource, deep integration with Teams, Outlook, Excel and Power BI, and functionality that once required a custom modification now arriving as standard. Much of what your team currently works around has quietly been solved.
Your data becomes usable
Business Central online connects natively to Power BI and Microsoft Fabric. The reporting most NAV and GP sites still assemble in Excel each month becomes a dashboard that refreshes on its own.
Two routes forward
Carry it across, or start fresh.
There is no single upgrade path. There are two, and the right one depends on how heavily customised your environment is and whether you want to preserve your current processes or take the opportunity to redesign them. This applies equally to NAV and GP.
Route A
Technical upgrade
- Moves your existing data, chart of accounts and configuration across into Business Central largely as they stand
- Preserves what already works and keeps disruption to a minimum
- Best suited to lightly customised environments on recent versions
- Custom code still has to be converted to the modern extension model, and this is almost always the largest variable in both timeline and cost
- Carries forward any accumulated workarounds along with the good parts
Route B
Reimplementation
- Rebuilds the system around how the business runs today rather than how it ran when the original configuration was written
- Master records, opening balances and open transactions migrate across; older history is archived separately for audit and reference
- Best suited to heavily customised environments, older versions, or businesses that have simply outgrown their original design
- Clears accumulated technical debt instead of paying to move it
- Requires more of your team's time, and delivers correspondingly more
Historical data
- Technical upgrade
- Migrated in full
- Reimplementation
- Core data migrated, history archived
Customisations
- Technical upgrade
- Converted to extensions
- Reimplementation
- Rebuilt only where still justified
Process redesign
- Technical upgrade
- Minimal
- Reimplementation
- Substantial opportunity
Best suited to
- Technical upgrade
- Light customisation, recent versions
- Reimplementation
- Heavy customisation, older versions
Business time required
- Technical upgrade
- Lower
- Reimplementation
- Higher
We will tell you which one we think fits after the assessment, with the trade-offs written down. If a technical upgrade is genuinely the better answer for you, we will say so: it is the smaller engagement.
How the migration actually works
The parts that decide your timeline, before you commit to one.
What is true for both
- The technical prerequisites.
- Your source database must be on SQL Server 2016 or later with a compatibility level of 130 or higher. Older environments need a database upgrade before migration can begin. Data movement itself is handled by Azure Data Factory, running as part of the Business Central online service.
- Your live system stays live.
- While replication runs, the online environment is configured with read-only access so your team can preview and validate data without creating conflicts. Your existing system remains the system of record until you explicitly cut over. There is no period where the business is without a working ERP.
- Customisations must match the online schema.
- Custom fields, tables and ISV add-ons need to exist as extensions matching Business Central online's schema. Anything that doesn't match will fail to replicate, sometimes without an obvious error. We inventory this at assessment rather than discovering it mid-migration.
- How much history to carry.
- Every additional year of transactional history lengthens replication and increases the reconciliation burden. Most organisations bring forward two to three years of active history and archive the remainder in an accessible form for audit and reporting. Moving everything by default is the most common avoidable cost in these projects.
The NAV path
NAV does not migrate directly to the cloud. Microsoft's cloud migration tool supports Business Central on-premises and Dynamics GP 2015 or later as sources. Dynamics NAV is not a supported source. A NAV environment has to be upgraded to Business Central on-premises first, and only then migrated to Business Central online.
For most NAV environments that intermediate step is Business Central version 14, the last release supporting both the legacy C/AL development environment and modern AL. It is the bridge between the way your system was written and the way Business Central online expects it to be written, and it is the single most commonly underestimated element of a NAV project.
We scope this explicitly in the assessment, because a timeline that ignores it is not a timeline.
The GP path
GP migrates directly, from GP 2015 or later. Older GP versions need an intermediate GP upgrade before the migration tool will run at all.
There is a preparation list to work through first.
- All batches posted.
- Sub-ledgers reconciled to the general ledger.
- The main account segment defined in General Ledger Setup.
- Activity tracking enabled across all companies.
- Check links run to clear errant data.
- Item codes brought within Business Central's twenty-character limit.
- Default posting accounts configured.
- Periods closed up to the open fiscal year.
None of this is difficult, but all of it takes time, and a migration attempted before it is finished will fail partway through. We work through the list with your team during assessment rather than discovering it on migration weekend.
Master data and balances migrate; detailed history does not. This makes the archive decision a design question rather than an afterthought. We usually recommend keeping a read-only GP environment or a reporting archive available for the statutory retention period, so nobody has to make a difficult choice between a clean new system and access to old detail.
You are seeing the Dynamics NAV path. Running Dynamics GP as well?
You are seeing the Dynamics GP path. Running Dynamics NAV as well?
How we run it: four stages, and a written answer at the end of the first.
- 01
Assess
We inventory your version, customisations, ISV add-ons, integrations and data volume, and confirm what a supported path actually looks like for your environment. You receive a written assessment whether or not you proceed with us.
- 02
Decide
We recommend a route with the trade-offs, timeline and cost set out plainly, and agree how much history moves and what gets archived.
- 03
Build and migrate
Extensions are rebuilt or converted, data is cleansed and scoped, and migration runs into a sandbox environment first. Nothing reaches production untested.
- 04
Test, train, cut over
User acceptance testing on your own data, role-based training, then a rehearsed cutover, followed by hypercare in the weeks that follow, when the questions actually arrive.
Frequently asked
The questions that come up first.
General
Will we lose access during migration?
No. Your existing system stays fully operational as the system of record throughout. You cut over only once data has been validated and your team is trained.
Do we need new hardware?
No. Business Central online is a fully managed service, so there is no server, database or infrastructure for your team to maintain afterwards.
Can we keep all our historical data?
You can, but we would usually advise against moving all of it automatically. Most clients migrate two to three years of active history and keep older records archived and accessible, which keeps the new system fast and the reconciliation manageable.
What if our ISV add-ons aren't available for Business Central?
We check this early. Many ISV vendors offer Business Central-compatible versions; where one doesn't exist, we scope a replacement using standard functionality or a purpose-built extension. Discovering this at assessment is inexpensive. Discovering it mid-migration is not.
We're already on Business Central but it isn't working well. Is this the right page?
No, that's a different engagement. If the platform is right and the configuration isn't, see our Business Central health check, which reviews an existing environment and returns a costed remediation plan. This page is for organisations still running NAV or GP.
Dynamics NAV
What happens to our existing customisations?
They are converted to Business Central's modern extension model; legacy C/AL modifications are not compatible with Business Central online. Encouragingly, a good proportion of what once needed a modification is now standard functionality, which reduces how much has to be rebuilt. The assessment tells you what falls into each category.
Our NAV was heavily customised. Is that a problem?
It's the main thing that determines which route suits you, and how long the project takes. Heavy customisation usually points toward reimplementation, because rebuilding around current requirements often costs less than converting fifteen years of accumulated modifications, many of which are no longer used.
Why does NAV need an intermediate step when GP doesn't?
Because Microsoft's migration tooling was built for Business Central and GP, not NAV. The intermediate Business Central on-premises version acts as the translation layer for both the data schema and the customisation model. It is an extra stage in the plan, not an extra project.
Dynamics GP
Our GP version is older than 2015. What then?
You need an intermediate GP upgrade before the migration tooling will run. We include this in the assessment and the timeline; it is routine, but it is not free.
What happens to our GP payroll?
Business Central doesn't replicate GP's payroll module. Most organisations move to a dedicated payroll service or an ISV payroll solution integrated back into Business Central. We scope this in the assessment, because it affects both timeline and licensing.
Will our SmartLists and Report Writer reports survive?
Not directly, and in most cases you won't miss them. Their equivalents in Business Central are standard list views, saved filters and Power BI, which generally produce better results with less maintenance. We identify which reports are genuinely in use, usually a fraction of the total, and rebuild those.
2029 feels a long way off. Should we wait?
Not indefinitely. A considered move takes nine to eighteen months from decision to go-live once evaluation, migration, testing and training are counted. Starting now means choosing your own timeline. Starting in 2028 means accepting whatever the market's capacity allows.
Start here
Not sure where your version stands?
Send us your NAV or GP version and roughly how customised it is. We'll tell you honestly how much runway you have, which route fits, and what the work would involve, as a written assessment, not a sales call.