If you still run Dynamics NAV, moving to Business Central is not one decision but three: which route to take, what to do with your customizations, and how to move your data. This article compares the realistic routes and the questions that separate them.
Why the customization question comes first
Business Central and NAV share history, and much of the data model is familiar. What is different is how customizations are built. NAV customizations were written in C/AL, often by modifying base objects directly. Business Central requires those changes to be rebuilt as AL extensions, using extension objects and events. That rebuild, not the data, is usually the largest variable in cost and time.
So before choosing a route, inventory the customizations: which objects were modified, which are still used, which have standard Business Central equivalents now, and which were workarounds for problems that no longer exist. It is common to find that a large share can be dropped.
Route 1: Technical upgrade
The database and application are upgraded through Microsoft's defined upgrade paths, with intermediate versions where the path requires them. History and transactions carry over. Customizations are converted or rebuilt as extensions. Tools such as txt2al convert C/AL text exports into AL syntax, but they do not turn base-object modifications into clean extensions; that redesign is still developer work.
Suits: systems on a supported upgrade path with modest customization and good data, where full history is needed in the system.
Route 2: Fresh implementation with data migration
You implement Business Central as a new system, apply what you have learned about your processes, and migrate selected data: master data, opening balances, open documents and, if needed, summarized or archived history.
Suits: heavily customized systems, poor data quality, changed processes, or organizations that want to leave old complexity behind. It is often faster than expected, because you are not converting everything.
Route 3: Cloud migration
If you are already on on-premises Business Central and want SaaS, Microsoft provides cloud migration tooling that moves data to an online environment. Extensions and integrations must be checked against SaaS restrictions. This route is about deployment model rather than leaving NAV, but it is often the second step after an upgrade. See SaaS vs on-premises for that decision.
Deciding between the routes
| Question | Points toward upgrade | Points toward fresh start |
|---|---|---|
| How customized is the system? | Lightly | Heavily, or with base-code changes everywhere |
| How clean is the data? | Consistent and well maintained | Duplicates, obsolete records, inconsistent setup |
| Are processes changing? | No | Yes: new entities, products or channels |
| Do you need full transaction history online? | Yes | Opening balances plus archive are acceptable |
| Which NAV version are you on? | On a supported upgrade path | Old version needing many intermediate steps |
Confirm supported upgrade paths for your exact NAV version in Microsoft's documentation, because they differ by version and change over time.
Handling historical data
There are three common patterns: migrate full history; migrate opening balances and open entries only, keeping the old system read-only for a defined period; or export history to a reporting database. The right pattern depends on audit obligations, reporting needs and how often people look back. Decide with finance and your auditors, not just IT.
A migration checklist
- Inventory customizations, integrations, reports and scheduled jobs.
- Classify each: retire, replace with standard, rebuild as extension.
- Assess data quality and agree cleansing rules.
- Choose the route and document why.
- Run a first migration into a sandbox and reconcile: trial balance, aged receivables and payables, inventory quantities and values.
- Repeat until reconciliation is clean and fast.
- Test end-to-end processes with real users.
- Plan cutover with a rollback point, then support the first month-end close.
Migrating from other systems
The same approach works for Tally, older on-premises ERPs and spreadsheet-driven businesses: map source data to Business Central structures, load through repeatable runs and reconcile against the source. Our migration service covers all of these, and upgrade services handle version-to-version moves. If you want to talk it through, you can discuss your migration with us.
Key takeaways
- C/AL customizations must be rebuilt as AL extensions, so audit them before choosing a route.
- A fresh implementation with data migration is often cleaner than a technical upgrade for heavily customized systems.
- Confirm the supported upgrade path for your exact NAV version with Microsoft's documentation.
- Rehearse the migration and reconcile balances before cutover.
Central Era TechnologiesWritten by the consultants and developers at Central Era Technologies, who work with Business Central, Dynamics 365 Finance and Operations, Power Platform and Azure. To credit a named author, add one here.