- Clarify whether the business is upgrading from Dynamics NAV, moving from spreadsheets, or replacing another ERP system.
- Decide which finance and operations processes must be standardised before configuration begins.
- Clean core data early, especially vendors, customers, chart of accounts, posting groups, and dimensions.
- Use a sandbox first, then move to production only after users have tested realistic transactions.
Microsoft Dynamics 365 Business Central, still often called Navision or NAV by long-time users, is an ERP platform where finance, operations, reporting, and governance come together. That makes readiness work important: a successful adoption depends less on knowing every screen and more on understanding how the system will control real business processes after go-live.
Navision began as an ERP product for small and mid-sized businesses and later became Microsoft Dynamics NAV. Microsoft Dynamics 365 Business Central is its modern successor, with a cloud-first operating model, regular release waves, tighter Microsoft 365 integration, and an extension-based approach to customisation. Older NAV environments often relied on code modifications inside the core application; Business Central encourages extensions built with AL and event-driven patterns, which helps reduce upgrade friction when Microsoft releases new functionality.
Why the Navision name still matters
The word Navision has not disappeared from business conversations because many organisations still run NAV, employ people who learned the older product, or use partner-built solutions that began in the NAV era. For clarity, current adoption and skills planning should use the Business Central name, while recognising that users may describe the same product family as Navision, NAV, or Dynamics 365 Business Central.
The distinction is more than branding. Business Central is designed around cloud operations, scheduled updates, Microsoft 365 connectivity, Power Platform integration, and AppSource extensions. On-premises deployments still exist for some scenarios, but project teams should treat the cloud service as the reference model unless there is a clear regulatory, integration, or operational reason to do otherwise.
This shift changes project planning. Classic NAV projects often accepted deep code changes as a normal way to meet local requirements. Business Central projects should first test whether standard setup, dimensions, workflows, permissions, or approved extensions can solve the requirement. Custom development still has a place, but it should be treated as a governed design decision because every extension must survive release waves, testing cycles, and future process changes.
What Business Central actually does
Business Central is an ERP system for managing finance, sales, purchasing, inventory, projects, service operations, and reporting in one connected application. Its finance capabilities usually form the core of an implementation because the chart of accounts, posting groups, tax setup, dimensions, currencies, and approval policies shape how transactions are recorded across the organisation.
Microsoft Learn describes Business Central as a business management solution for small and mid-sized organisations, and that positioning is useful. It is broad enough to support finance-led operational control, but it is not intended to make every company process unique. The strongest implementations tend to simplify processes before configuration, rather than reproducing every spreadsheet, exception, and legacy workaround inside the new system.
Dimensions are a good example. In Business Central, dimensions are analysis tags such as department, project, region, customer group, or cost centre. They allow a finance team to analyse transactions without building an excessively large chart of accounts. A company that rushes this design may discover during month-end that reports are inconsistent, users select the wrong values, or transactions are blocked because required dimensions were not assigned correctly.
How the extension model changes implementation
Business Central’s extension model is one of the most important differences from older NAV implementations. Extensions can add functionality without directly modifying the base application, and event-based development allows custom logic to respond to business events in a more maintainable way. From a practical perspective, that reduces the technical debt associated with upgrades, but it also requires more discipline at the design stage.
Project teams should ask whether a requirement is a legal necessity, a competitive differentiator, an efficiency improvement, or simply a habit from the old system. Standard setup should be tested before custom code is approved. If a requirement can be met through posting setup, approval workflows, dimensions, number series, user groups, or an existing extension, the long-term maintenance burden is usually lower.
Release waves also matter. Microsoft publishes planned Business Central updates through release wave documentation, and administrators should review those plans before major go-live dates or heavy customisation work. The aim is not to chase every new feature, but to understand which changes might affect testing, integrations, user training, or extension compatibility.
A pragmatic path from discovery to go-live
A Business Central project should start with business discovery, not system configuration. The discovery phase should identify the legal entities, currencies, tax requirements, bank processes, approval rules, reporting needs, and integrations that will shape the build. It should also expose where current processes depend on manual checks, undocumented spreadsheet logic, or individual knowledge held by a small number of employees.
After discovery, teams should design the finance foundation before expanding into operational modules. That usually means agreeing the chart of accounts, posting groups, dimensions, VAT or tax setup, bank accounts, fiscal calendars, number series, and approval controls. If these elements are unstable, sales, purchasing, inventory, and reporting work will inherit the same instability.
Data migration is often the riskiest part of the project because it reveals the quality of past processes. Vendors may have duplicate records, customers may use inconsistent naming, open entries may not reconcile cleanly, and item data may contain obsolete units of measure. Configuration packages can help structure imports, but they do not replace business ownership of cleansing and reconciliation.
A sound migration approach uses dry runs before user acceptance testing. One early dry run should validate structure: fields, mappings, posting groups, dimensions, opening balances, and mandatory values. A later dry run should validate usability: whether users can process invoices, receipts, payments, purchase orders, sales orders, and inventory transactions using migrated data. The final migration should be rehearsed closely enough that the cutover weekend is execution, not discovery.
Testing should follow real transaction paths rather than isolated features. A finance test might begin with a purchase invoice, route it through approval, post it to the general ledger, pay it from the bank, reconcile the bank statement, and review the impact in a financial report. That style of testing reveals permission gaps, approval bottlenecks, dimension mistakes, and posting group errors before production users encounter them.
Adopting in waves rather than all at once
Business Central can support a wide range of processes, but adopting every module at the same time increases risk. Many organisations are better served by beginning with finance core, then adding sales, purchasing, inventory, projects, or service management once the core controls are stable. This sequencing gives users time to learn how the system behaves and gives the project team time to correct early design issues.
A sandbox environment should be used for configuration experiments, extension testing, training, and migration rehearsals. Exit criteria should be written in business language. Examples include successful month-end close testing, approval workflows completed by the right roles, reconciled opening balances, validated tax postings, and sign-off from super users who can demonstrate daily tasks without project-team intervention.
One common mistake is to customise too early. A user may ask for a modification because the new screen differs from the legacy workflow, but the underlying requirement may be met through a standard page view, a saved filter, a role centre adjustment, an approval workflow, or Excel integration. Delaying non-essential customisation until after standard capability has been tested helps protect the implementation from unnecessary complexity.
The roles that make the system work
Business Central adoption needs clear ownership across business and technical roles. The product owner should decide priorities and resolve process trade-offs. Functional consultants translate finance and operations requirements into Business Central configuration. Developers or ISV partners handle extensions and integrations where standard functionality is insufficient. Super users validate day-to-day work and become the first line of support after go-live.
Permission design deserves particular attention. Role-based security should reflect separation of duties, especially where the same person might otherwise create a vendor, approve a purchase invoice, and release a payment. Misaligned permission sets can either block legitimate work or create control weaknesses that auditors later challenge.
Super users should be involved before training begins. They need time in the sandbox to practise realistic scenarios, document local procedures, and understand why the configuration works as it does. Without that preparation, support after go-live becomes dependent on the implementation partner, and minor questions can slow down daily operations.
Small examples that show early value
Dimensions often provide the first visible improvement for finance leaders. Instead of creating separate general ledger accounts for every department or project, the finance team can use dimensions to tag transactions and analyse performance by department, region, or project. The practical challenge is governance: if users can choose any value without clear defaults, reporting quality suffers. Required dimensions and default dimension rules should therefore be designed alongside the chart of accounts.
Approval workflows are another useful early example. A purchasing process can require approval when an invoice exceeds a threshold or when a requester belongs to a particular department. This can reduce informal email approvals and create a clearer audit trail, but it only works when delegation, substitutes, and exception handling are tested before go-live.
Microsoft 365 integration can also demonstrate value quickly. Users can work with Business Central data in Excel for analysis, interact with customer or vendor information through Outlook, and connect Power BI to standard datasets for management reporting. These features should still be governed carefully, especially where exported data contains sensitive financial or customer information.
Power Automate can extend approval and notification scenarios, but low-code automation should not bypass ERP controls. When teams begin building automations around Business Central, ownership, monitoring, and change control should be agreed from the start. Otherwise, a helpful workflow can become an undocumented dependency that fails silently when a user account, connector, or field changes.
Where certification fits into capability building
Formal training is useful when it is tied to project responsibilities rather than treated as a separate learning exercise. The Microsoft Certified: Dynamics 365 Business Central Functional Consultant Associate credential, based on Exam MB-800, aligns with skills such as configuring Business Central, setting up financials, working with sales and purchasing, and supporting operations. That makes it the relevant certification path for functional consultants and advanced business users who need to understand the product beyond navigation.
Teams evaluating structured preparation can use the Business Central course overview to understand how the newer Business Central learning path differs from older Navision training. Readynez can be considered where live, guided preparation for MB-800 needs to sit alongside an implementation or post-go-live upskilling plan.
Certification should not be the only measure of readiness. A certified consultant still needs local process knowledge, and a skilled finance user still needs time to practise in the configured environment. The most reliable capability plan combines product learning, sandbox practice, documented business procedures, and support ownership after launch.
Governance after go-live
Business Central does not stand still after deployment. Microsoft release waves, extension updates, new reporting requirements, and business process changes all create ongoing governance needs. Administrators should maintain a routine for reviewing upcoming changes, testing key business processes in a sandbox, and confirming that extensions remain compatible.
Post-go-live support should distinguish between incidents, configuration changes, training gaps, and enhancement requests. A blocked posting caused by an incorrect posting group is different from a request for a new report. Treating every issue as a technical fault can hide process weaknesses, while treating every request as a customisation opportunity can increase long-term maintenance.
Security should also be reviewed after real usage begins. Initial permission sets are often designed from expected roles, but actual behaviour may show that some users need more restricted access or clearer approval boundaries. This review is especially important when finance, purchasing, inventory, and payment processes are distributed across different locations or departments.
Making Business Central adoption sustainable
The key benefit of Business Central is not simply that it replaces Navision with a newer interface. Its value comes from standardised processes, cleaner data, stronger financial control, and better integration with the Microsoft ecosystem. Those benefits depend on decisions made before go-live: what to standardise, what to migrate, what to customise, who owns the process, and how users will be supported.
A practical next step is to assess the organisation’s finance foundation, migration readiness, and super-user capability before expanding the scope. Where ongoing Microsoft upskilling needs to be budgeted beyond the first Business Central project, Microsoft Unlimited from Readynez may be one option to consider alongside internal practice, partner support, and role-specific learning plans.
