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? Support status is an important planning constraint. Database condition, customisations and dependencies determine the work needed to move. 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. Support dates differ by release. For example, Dynamics NAV 2017 remains in extended support until January 2027, so check the exact version’s Microsoft lifecycle page rather than treating every earlier release as already unsupported.
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, updated 19 June 2026, 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 documented paths pass through Business Central version 14; older NAV versions need the intermediate NAV upgrades listed above before that stage. 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 can provide a fresh start with an approved data and archive scope. Microsoft also documents a Business Central 14 Reimplementation tool that avoids upgrading beyond version 14, but the tool is currently preview and is not intended for production use. Evaluate it in a sandbox; confirm a production-supported migration method before committing the cutover plan. Verify the exact data and historical-entry coverage for the selected tool version.
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 the scope of data and customisation carried forward. Microsoft’s overview describes a subset of posted historical entries in one section but elsewhere summarises reimplementation as not carrying historical transactions. Verify the current reimplementation tool’s table and entry coverage for the actual source version, and document which history will remain in an accessible archive. 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 retiring an unnecessary customisation after its owner approves the change. 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 Malaysian deployments, identify locally customised tax, statutory-reporting and e-Invoice logic early. 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.
Define the migration acceptance record
Make each dry run repeatable. Record the exact source version and build, localisation, companies, extensions, target version and tool versions. Attach the approved inventory of data to migrate, data to archive and customisations to replace or retire. Resolve the documented history-coverage uncertainty with a sample from the actual source before agreeing the scope.
For each company, compare approved control totals before and after the move: trial balance, open customer and vendor entries, bank balances, and inventory quantities and values where relevant. Keep filters, currency, cut-off and known exclusions with the result. Test at least one normal transaction and one exception through each critical integration and permission role. An unexplained difference needs an owner and a resolution or explicit acceptance; a completed replication job alone is not business acceptance.
The cutover record should state the allowed outage, final transaction cut-off, outstanding exceptions, who can authorise the switch, how users receive access and who handles the first close. Any fallback must be assessed for the actual migration stage; do not assume production can simply be moved back after new transactions are entered.
When a smaller move is the right answer
A smaller NAV estate may justify a narrowly scoped reimplementation rather than a full historical migration. Assess internal capability, reconciliation and archive requirements, and select a production-supported migration method. The preview status of the Business Central 14 Reimplementation tool must be considered separately from the decision to reimplement.
Assess migration effort using customisations, upgrade stages, data volume and quality, integrations, archive requirements and the permitted cutover window.
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.