NAV 2017 support ends 11 January 2027. The bigger surprise for most teams is not the date, it is that NAV has to land on Business Central on-premises first, then move online, not in one step.
This is the single most common nasty surprise in a NAV migration, and it is almost never disclosed before the statement of work is signed.
"We have watched this catch out project teams mid-migration more than once: the sales conversation covers 'NAV to the cloud' as one step, and the two-hop reality only surfaces once work has started."
How we scope every NAV migration up frontFull inventory of NAV customisations, add-ons, and integrations, and which ones are actually load-bearing.
AI: customisation scanDecide upfront whether hop one lands as a short bridge or a longer-lived step, based on your customisation depth.
AI: gap mappingMigrate master data and required history once, not twice, by planning both hops together from the start.
AI: cleansing & matchingTwo planned cutover events instead of one surprise mid-project, each with its own testing and hypercare.
No. Microsoft's supported path requires landing on a current Business Central codebase before the online move, regardless of partner.
It is priced as one migration with two cutover events, not two separate projects. The bigger risk is a partner who quotes it as one step and finds hop one mid-project.
There is no fixed limit, but staying on BC on-premises long-term forfeits most of the reason to migrate at all.
Some do as extensions, some should be retired. That decision is made explicitly during design, not discovered during testing.
That is a rescue conversation, not a NAV question. Run the situation diagnostic or talk to us directly.
Tell us your NAV version and what's customised. We'll tell you honestly what the two-hop path looks like for your data.
With someone who's run a NAV-to-BC migration before.
Four minutes, no email required to see the result.