Dynamics 365 Business Central Implementation, Extensions and Migration

What is Dynamics 365 Business Central, and what does Solzet deliver?

Business Central is Microsoft's ERP for small and mid-sized organizations, covering finance, sales, purchasing, inventory, projects, manufacturing, warehouse and service management in one system. Microsoft's own list of areas is finance, sales, purchasing, inventory, projects, fixed assets, planning, assembly, manufacturing, warehouse management and service management, and Business Central can be deployed online, with the data stored in the Microsoft cloud, or on-premises. In practice it means one database for the general ledger, the stock, the purchase orders, the project costs and the service work, instead of an accounting package with a spreadsheet bolted to each side of it.

Solzet implements Dynamics 365 Business Central online, builds AL extensions and integrations, and migrates companies from Dynamics NAV, Dynamics GP, 1C and other ERPs. The same people do the consulting and the development. The consultant who ran the finance workshop is still on the project when the posting setup is tested, and the developer who wrote an extension knows which business rule it exists for, because they were in the room when it was agreed. Work is delivered in English, Armenian or Russian.

This page is the overview of the Business Central service line. Each part below has its own page with the detail, and the rest of what we do is on the services page.

• Business Central implementation (online): discovery, fit-gap, solution design, configuration, data migration, testing, training, go-live and hypercare, described phase by phase on this page.
• Business Central AL development: AL extensions, APIs and integrations, and apps prepared for Microsoft Marketplace (AppSource).
• Migration to Business Central from Dynamics NAV, Dynamics GP, 1C and other ERPs, with the history decisions made up front.
• Business Central Armenian localization: AMD as the local currency, Armenian tax and statutory reporting, chart of accounts, documents and e-invoicing. Also available in Armenian and Russian.
• CRM and ERP integration: Business Central with Dynamics 365 Sales, Customer Service and Power Platform through Dataverse.
• Business Central project assessment, optimisation and support for environments that are already live.

Who is this for, and who is it not for?

Business Central fits small and mid-sized companies that want finance, inventory, projects and light manufacturing in one cloud system. Finance and Operations fits larger organizations with several legal entities, deep supply chain or production needs, or retail operations on Commerce. If you also run Dynamics 365 Customer Engagement, both connect to it through Dataverse.

The buyers who get the most out of a Business Central project with Solzet usually recognise themselves in one of the situations below. The common thread is that the business has outgrown the tools it started with, and the finance team spends the last week of every month stitching numbers together from places that were never meant to agree.

Business Central is the wrong answer in three cases, and it is better to hear that before the project than after it. If you run several legal entities across countries with heavy production planning, warehouse automation or a retail estate, look at Finance and Operations instead. If you want SAP, Oracle, Odoo or 1C implemented or upgraded, Solzet is the wrong supplier: non-Microsoft ERP implementations are the one ERP line we keep out of our work, while migrating you from any of them to Business Central is squarely in it. And if the real need is a CRM rather than an ERP, start with Dynamics 365 Customer Engagement and connect Business Central later.

• Growing companies on an entry-level accounting package, with stock, purchasing or project costs tracked in spreadsheets beside it.
• Companies on Dynamics NAV or Dynamics GP that need a plan before Microsoft support ends, rather than after.
• Armenian companies replacing 1C that need Armenian tax and statutory reporting, AMD as the local currency and Armenian-language documents in a Microsoft ERP.
• Distributors, wholesalers, light manufacturers and project-based service firms that need one system for orders, stock, production or projects and the ledger.
• Organizations already on Dynamics 365 Customer Engagement that want orders, invoices and stock visible to sales and service without rekeying.
• Microsoft partners that need Business Central consultants and AL developers on a white-label basis inside their own delivery process.

Business Central or Finance and Operations: which one fits your company?

Both are Microsoft ERPs, both connect to Dataverse, and both are implemented by Solzet, so this is a fit question rather than a sales question. The deciding factor is rarely revenue on its own. It is the complexity you need the system to carry: how many legal entities and countries, how deep the supply chain and production requirements go, whether you run retail operations, and how much of that complexity is genuinely needed rather than inherited from an old system.

Most companies land clearly on one side of the table below. The interesting cases sit in the middle: a mid-sized manufacturer with one complex plant, or a group with several small entities that each look like a Business Central company. For those we run a short fit assessment against your real processes and give you a written recommendation, including what you would give up with each option. Our article on Business Central versus Finance for mid-market manufacturers walks through the decision for one industry in more detail.

How does a Business Central implementation run, phase by phase?

A Business Central implementation is mostly decisions, and the software is the easy part. Every phase below ends with something you can review and sign off, so the project never depends on trusting that progress is happening somewhere out of sight. The phases overlap in practice, but the order holds: nobody configures the posting setup before the chart of accounts is agreed, and nobody loads opening balances before a migration rehearsal has reconciled.

Two decisions sit in front of the build. Deployment: Business Central can run online, in the Microsoft cloud, or on-premises, and for a new implementation we recommend online unless you have a specific reason to host it yourself. Licensing: the licence mix is sized from the roles that actually use each area, worked out during discovery and bought through your Microsoft licensing channel. We do not publish prices for our own work, and we will not guess Microsoft's for you either; the point of sizing it in discovery is that the number you renew for years is based on real roles.

How long it takes depends on the modules in scope, the number of companies, the state of your data, the extensions and integrations you need, and how quickly your own people can make decisions. A finance and inventory rollout for one company is a very different project from a multi-company rollout with production, warehouse handling and a CRM integration. The discovery phase produces the plan and the estimate, with the assumptions written down, so you commit to the build on evidence rather than on a number someone quoted on the first call.

• Discovery and fit-gap: workshops per process area, the current chart of accounts and reporting needs, and a fit-gap list that says what standard Business Central covers, what needs configuration and what needs an AL extension.
• Solution design: companies and dimensions, posting setup, number series, approval workflows, roles, integrations and the data migration scope, written up as a design document you sign off.
• Build: configuration in a test environment, AL extensions in source control with code review, and integrations built against agreed contracts.
• Data migration: master data, open balances and open documents loaded in rehearsals, each one reconciled against the old system before the next.
• Testing: end-to-end scenarios run by your own key users, from quote to cash, purchase to pay and month-end close, not only feature checks.
• Training and cutover: role-based training on your own data, a cutover plan with a rollback decision point, and a final migration over a planned window.
• Go-live and hypercare: the consultants who built the system support the first period closes, then hand over to support with documentation.

How do you move data from Dynamics NAV, Dynamics GP, 1C or spreadsheets into Business Central?

Data migration is where Business Central projects slip, so we plan it from the first week. The first decision is what to bring. Master data (customers, vendors, items, the chart of accounts) and open positions (balances, open orders, open invoices, stock on hand) always move. History is a choice: full transaction history, summarised history, or a read-only archive of the old system. Each option has a cost in effort and in testing, and the right answer depends on what your auditors, your finance team and your sales team actually look up.

The route depends on where you start. Dynamics GP data from GP 2015 and later can be migrated to Business Central online with Microsoft's built-in cloud migration tool, and a historical GP snapshot can be migrated too. Dynamics NAV customers upgrade to Business Central on-premises first and then switch to Business Central online with the cloud migration tool; Business Central on-premises version 25 or later migrates directly. For 1C, and for other ERPs and spreadsheets, the work is extraction, mapping and transformation: the 1C chart of accounts and reference data mapped to the Business Central structure, cleaned, and loaded in rehearsals.

The deadlines are real. Dynamics NAV 2018 extended support ends on 11 January 2028. Microsoft ends Dynamics GP support for enhancements, tax updates and technical support on 31 December 2029, with security updates until 30 April 2031. Details are on the migration to Business Central page, with a NAV to Business Central migration checklist, a guide to what GP customers should do before support ends, and a guide to moving from 1C to Business Central.

• A migration scope per data type: what moves, from which date, in which form, and who in your team owns the sign-off.
• Cleansing before loading: duplicate customers and items, dormant vendors and inconsistent units of measure fixed in the source or in the mapping, not after go-live.
• Rehearsals with reconciliation: trial balance, receivables, payables and stock value compared with the old system after every load.
• Custom code in NAV or GP reviewed one item at a time: replaced by standard Business Central, rebuilt as an AL extension, or retired.

How do AL extensions and integrations fit around standard Business Central?

Business Central extensions are written in AL, using the AL Language extension for Visual Studio Code. An extension adds tables, fields, pages, reports and business logic beside the base application rather than rewriting it, which is the difference between a customised NAV database that nobody dares to upgrade and a Business Central environment that takes Microsoft's updates with a test cycle rather than a project. Our rule of thumb is simple: configuration first, an extension where configuration genuinely cannot do the job, and every extension in source control with code review, automated builds and a test environment that mirrors production.

Integrations are the other half. Typical ones are banks and payment providers, e-commerce platforms, EDI with large customers, warehouse scanning, payroll or HR systems, and reporting in Power BI. We build them against documented APIs with authentication, logging, retries and an error queue someone actually watches, because an integration that fails quietly is discovered by finance at month-end. Where your own developers or another system need data out of Business Central, we design the API surface with them instead of leaving each consumer to scrape tables.

Business Central extensions can also be submitted to Microsoft Marketplace (AppSource), validated with the AppSourceCop analyzer. If you are an independent software vendor turning your own product into a Business Central app, we build it to those rules from the start. Microsoft partners can use the same AL developers and consultants on a white-label basis through our Dynamics 365 subcontracting service. The full scope is on the Business Central AL development page.

What does the Business Central Armenian localization include?

Solzet delivers the Business Central Armenian localization: AMD as the local currency, Armenian tax and statutory reporting, an Armenian chart of accounts, Armenian-language documents, and e-invoicing integration with the State Revenue Committee where applicable. Solzet builds it as extensions on the international (W1) version of Dynamics 365 Business Central, which is available in Armenia.

That last point matters. Business Central online is available in Armenia on the W1 base application, and Microsoft leaves the Armenian localization to partners rather than shipping it in the product, which is the gap Solzet fills. Because the localization is built as extensions, it sits beside the standard application in the same way as any other AL extension and moves forward with Microsoft's updates through a normal test cycle. Companies in Armenia moving from 1C get the statutory side they rely on today, inside a Microsoft ERP that also connects to Dynamics 365 Customer Engagement and Power Platform.

The localization has its own page in English, Armenian and Russian, covering what it includes and how a project runs. For the migration side, see our guide to moving from 1C to Business Central.

How does Business Central work with Dynamics 365 Sales and Power Platform?

Solzet works on both sides of the Microsoft business stack. We know Dataverse and Dynamics 365 Customer Engagement deeply, and we implement Business Central and Finance and Operations. That means one team designs the CRM, the ERP and the integration between them: Customer Engagement with Business Central through the Dataverse connection and virtual tables, Customer Engagement with Finance and Operations through dual-write and virtual entities, and Power Platform across both.

On the Business Central side, the route is specific. Business Central connects to Dataverse through the Set up Dataverse connection assisted setup, with one-way or two-way synchronization, and that connection is the route for integrating with Dynamics 365 Sales. The Business Central Virtual Table app exposes Business Central data in Dataverse as virtual tables without copying it, so the data stays in Business Central while a sales app, a Power Apps screen or a Power Automate flow reads it. Deciding which data synchronizes and which is only read through virtual tables is a design decision, and it is the one most often made by accident.

Many companies run CRM and ERP with two suppliers and end up reconciling the two by hand. Solzet scopes the CRM, the ERP and the data flow between them as one design, so customers, orders, invoices and stock mean the same thing in both systems. We recommend the right solution: Dynamics 365 (Customer Engagement, Business Central or Finance and Operations), Power Platform, or a custom-built CRM. One team for CRM, ERP and the integration between them. The detail is on our CRM and ERP integration page; the CRM side is on Dynamics 365 Customer Engagement consulting, and for organizations that want CRM outside Microsoft licensing we build custom CRM that connects to Business Central through its APIs.

What happens after go-live, and can you take over an existing Business Central project?

After go-live the consultants and developers who built the system stay with it through hypercare, usually the first period closes, and then hand over to support. Support covers user questions, configuration changes, fixes and enhancements to AL extensions, and testing your extensions and integrations against Microsoft's Business Central updates before they reach production. Small changes go through the same source control and test environment as the original build, so the system you have a year after go-live is still one somebody can explain.

Already live on Business Central? Solzet can audit your existing project and give you a stabilisation plan. The assessment looks at the setup against how the business actually runs, the extensions and their code quality, the integrations and their error handling, data quality, security and permissions, and the open issues your users have stopped reporting because nothing happened last time. The output is a written list of findings with a priority and an estimate for each, which you can deliver with us, with your own team or with your current supplier.

Typical reasons to ask for one: month-end takes longer than it did on the old system, an extension breaks on every Microsoft update, the previous implementer has moved on, or the project went live with half the scope and nobody owns the rest. The approach is the same as our broader Dynamics 365 health check and technical audit, applied to Business Central.