SCSB is asked a version of the same question by Malaysian organisations still running Dynamics NAV: the system works, so how long can it be left alone? In our experience the support date is the least useful input to that decision. What actually sets the cost, duration and risk of moving to Dynamics 365 Business Central is the condition of the existing database and the volume of custom code inside it — and both can be established now, before any budget is committed.
Read the lifecycle date as a planning trigger, not a deadline
Microsoft's Lifecycle page for Dynamics NAV 2018 records mainstream support as having ended on 10 January 2023, with extended support ending on 11 January 2028. Earlier Dynamics NAV releases have passed both dates already.
A date of that kind justifies starting a considered assessment. It does not justify a fixed migration timetable announced before anyone has opened the database. SCSB would treat a proposal that offered a firm timetable at that stage as a warning sign rather than a reassurance, because the work that sets the timetable — code conversion, data remediation, localisation checks — is discovered during assessment, not before it.
The supported route is longer than most organisations expect
This is the single point that most often changes a budget expectation. Microsoft's guidance on migrating Dynamics NAV to Business Central online states that Dynamics NAV versions before Business Central version 14 cannot migrate directly to the cloud, so an on-premises upgrade comes first. The documented routes are staged:
- Dynamics NAV 2015 through 2018 — Business Central version 14 on-premises, then Business Central on-premises version 25 or later, then Business Central online.
- Dynamics NAV 2013 and 2013 R2 — Dynamics NAV 2018 first, then that same three-step sequence.
- Dynamics NAV 2009 SP1 and 2009 R2 — Dynamics NAV 2013 or 2015, then Dynamics NAV 2018, then that same three-step sequence.
Microsoft states that both migration paths require reaching Business Central version 14 as the first step. An organisation still on Dynamics NAV 2009 is therefore looking at a five-stage route, each stage with its own data upgrade and its own opportunity for something to break. The implication SCSB draws is simple: for older estates, the word "migration" describes a sequence of technical upgrades that precede the cloud move, and a plan that shows a single arrow from the current system to Business Central online is not describing the supported path.
Full migration and reimplementation answer different questions
Microsoft documents two destinations for that effort. A full migration carries all data and customisations forward, and requires converting C/AL customisations to AL extensions and upgrading to the latest version. Reimplementation, using the Business Central 14 reimplementation tool, migrates only essential business data — master data, opening balances, a subset of posted historical entries and setup — and Microsoft notes it does not require extension conversion or upgrading beyond version 14.
SCSB's view is that reimplementation is routinely mischaracterised as the lesser option. It is a different decision, not a cheaper version of the same one. Where an organisation wants standardised processes, and where the legacy customisations encode habits that nobody in the business will now defend, reimplementation removes work rather than deferring it. Microsoft itself frames it as the route for organisations that want a fresh start and want to avoid migrating legacy customisations and historical data.
The trade-off is history, and it should be stated plainly: the reimplementation route does not carry forward historical transactions or legacy customisations. So the question to answer honestly is how much posted history the business genuinely needs inside the live system, as distinct from in an archive it can query when it needs to. In our experience organisations answer that far too quickly in favour of "all of it", and then pay for the conversion of history nobody subsequently opens.
Custom code is the decision that shapes everything else
Microsoft is explicit that data from tables with code customisations cannot be carried forward from Dynamics NAV unless those customisations are handled by extensions installed on both the on-premises and the online environment. That last part is the detail most often missed: the extension has to exist on both sides, not only on the target.
The discovery work SCSB would expect before any commitment is an inventory of every customised object, with each one classified into one of three outcomes:
- Reproduce as an AL extension — the customisation encodes a requirement that is still genuine and still unmet by standard functionality.
- Satisfy with standard functionality — the requirement is real, but Business Central now covers it natively.
- Retire — the customisation supports a process that has changed, or a report nobody reads.
The middle category is usually larger than the organisation expects, because many Dynamics NAV customisations were written before standard functionality caught up with them. Establishing that early is what makes the difference between converting code and quietly deleting it. Microsoft also records reimplementation as the alternative where converting customisations to extensions is not practical, which is a decision point worth reaching deliberately rather than after conversion has already been attempted and abandoned.
Prepare the database, then understand the mechanism
Microsoft recommends treating the migration as an opportunity to reduce technical debt: archive obsolete history, shrink oversized transaction and log tables where appropriate, validate that schema changes are intentional, and confirm the Microsoft SQL Server version and compatibility level, which the guidance states should be 130 or higher. Where several companies are in scope, Microsoft advises designing the batches early so that timing and validation can be repeated consistently.
SCSB sequences this ahead of detailed planning rather than alongside it, for a practical reason: the database will be replicated repeatedly through testing and dry runs, so every gigabyte of obsolete history is a cost paid on each pass, not once.
Microsoft describes the end-to-end migration in six phases: preparation, the Business Central on-premises upgrade, cloud migration setup, data replication, data upgrade and completion, and post-migration follow-up. The cloud migration itself replicates data from the on-premises database to the online tenant through Azure Data Factory, with an Integration Runtime installed and a replication schedule configured, and Microsoft documents both initial and delta replication.
Two points in that sequence deserve more attention than they usually get. Delta replication means cutover need not be a single long outage, which changes what is realistic to plan around a month end. And post-migration follow-up — enabling users, reconnecting integrations, monitoring the environment and addressing performance — is genuine work that SCSB budgets for explicitly, rather than treating go-live as the finish line.
Microsoft recommends performing at least one dry run of the full migration in a sandbox environment before the production cutover, to identify issues, measure timing and validate results with business users. We would treat a plan without one as incomplete, whatever the schedule pressure.
Keep localisation and Malaysian obligations in a separate workstream
Country and region-specific functionality in Dynamics NAV is delivered through localisation apps in Business Central online. Microsoft advises verifying that the required localisation apps are available for the target country or region, and confirming that any locally customised tax, regulatory or reporting logic has been converted to AL extensions compatible with the online localisation.
For a Malaysian organisation this is where a Dynamics NAV migration most often goes quiet and then loud. Tax, statutory reporting and electronic invoicing logic accumulated in a Dynamics NAV database over a decade is precisely the category Microsoft is describing, and it rarely sits in one tidy object. SCSB runs this as its own workstream with its own owner and its own test evidence.
It is worth being direct about the boundary. A supported Microsoft migration route confirms nothing about whether an organisation's obligations to LHDN or any other authority are met. Those requirements are set by the authority, should be confirmed against its current published guidance and the organisation's own advisers, and should then be tested against the configured system — in that order.
A decision record before a project plan
- Inventory the current environment. Version, companies, customised objects, integrations, reports, database size and condition, and the processes the business cannot operate without.
- Confirm the supported route for your starting version and the intermediate steps it requires, rather than assuming a direct move.
- Classify every customisation as convert, replace with standard functionality, or retire — with a named owner for each decision.
- Decide full migration or reimplementation on the basis of the history and customisation the business will actually use, not on which sounds more thorough.
- Run a sandbox dry run covering conversion, reconciliation, integrations, permissions and business acceptance.
- Plan cutover and the weeks after it, including data validation, communications, training and who owns post-go-live issues.
When a smaller move is the right answer
Not every organisation running Dynamics NAV needs a migration programme. A single company on Dynamics NAV 2018, with light customisation, modest history and no complex integrations, may find the reimplementation route to be a contained project that its own finance and IT people can largely run with limited external help. That is a legitimate outcome and SCSB will say so.
The honest test is not the size of the organisation. It is the number of customised tables carrying data that must survive, multiplied by the number of intermediate upgrade steps the starting version requires. Where both numbers are small, the work is smaller than the market noise around end-of-support dates suggests. Where either is large, no amount of optimism in a plan will make it small.
Where SCSB's implementation support fits
Where an organisation has completed its assessment and defined an agreed scope, SCSB's Business Central implementation service can be discussed. Timing, sequence and acceptance criteria remain dependent on the current environment and on decisions that belong to the organisation.
This article is general information about Microsoft product documentation and implementation practice. It is not advice on any organisation's particular circumstances, and it does not determine any tax, accounting or regulatory position. Microsoft's product documentation, supported paths and lifecycle dates change over time; confirm the current position against Microsoft's own published material.
Azure Data Factory, Dynamics 365 Business Central, Dynamics NAV, Microsoft and Microsoft SQL Server are trademarks of the Microsoft group of companies.