Buying an ERP is a major decision. Getting it to work properly inside the business is an even bigger one.
A Business Central implementation affects the way finance records transactions, sales teams handle orders, buyers work with suppliers, warehouse staff manage stock, and managers review business information. It can also expose problems that were hidden inside an old system, especially when data is inconsistent or employees have built manual workarounds over the years.
For that reason, implementation should begin with the business rather than with a list of software screens.
The project needs a clear answer to a few practical questions: What needs to improve? Which existing processes are worth keeping? What information actually needs to move? Which systems must connect with Business Central? And where is additional development genuinely necessary?
This guide breaks down those decisions and the work that normally surrounds a Business Central project.
Where Should a Business Central Project Begin?
Start with the reason for replacing or introducing the ERP.
Maybe month-end reporting takes too much manual effort. Perhaps several departments keep separate versions of customer or inventory information. A distributor may struggle to know what stock can actually be promised to customers. A manufacturer may have difficulty connecting purchasing, production, and inventory planning.
Those problems should shape the project.
A long list of requested features is not enough. The team needs to understand the outcome the business is trying to reach.
For example, “better inventory management” is too broad to guide an implementation.
A more useful requirement could be:
“The sales team needs visibility into available inventory before confirming a customer delivery date.”
Now the team has something concrete to investigate, design, test, and measure.
Microsoft’s current implementation guidance also encourages organizations to think about the business outcome and to involve both business and technology stakeholders during the project.
Map the Work Before Designing the System
People who have worked with an old ERP for years often stop noticing the workarounds around it.
A spreadsheet may be used to calculate something the ERP does not report conveniently. An employee may copy information from one system into another. An approval may happen through email because the existing workflow was never designed for it.
Those habits are important during discovery.
Take a purchasing process as an example.
A department asks for something. A manager approves it. Purchasing creates an order. The supplier confirms the request. Goods arrive. Someone records the receipt. Finance receives the invoice. The invoice is checked and posted. Payment is eventually made.
If the project only looks at the purchase order screen, it misses most of the process.
Mapping the complete flow helps the team understand responsibilities, approvals, data requirements, controls, and dependencies.
Decide What the Future Process Should Be
An ERP replacement should not automatically become a historical museum for every old procedure.
Some old steps exist for good reasons. Others exist because the previous software made them necessary.
This distinction can save a project from unnecessary complexity.
Imagine a business has three manual checks before releasing an order because its current system does not provide the information users need. If Business Central can provide the required visibility earlier in the process, there may be no reason to reproduce all three checks.
The implementation team should therefore ask what the business actually needs, rather than simply asking how to copy what already exists.
That is one reason Microsoft recommends fit-to-standard analysis before deciding where customization is required.
Understand the Difference Between Configuration and Custom Development
A company may ask for a feature that sounds unique but turns out to be a configuration issue.
Another requirement may genuinely fall outside the standard application.
Those situations should not be treated the same way.
A sensible sequence is:
Understand the requirement → review standard capability → consider process change or configuration → identify the remaining gap → evaluate an extension, integration, or other solution
This approach avoids development work that solves a problem the standard application could already handle.
Microsoft notes that unnecessary customizations can add design, coding, testing, training, and documentation effort.
That does not mean every implementation should avoid extensions. A business may have an important process that gives it a legitimate operational advantage. In that case, development can make sense.
The point is to make the decision deliberately.
Build the Business Central Environment Around Real Requirements
Once the future processes are agreed, the system can be prepared.
The configuration will depend on the organization, but common areas include financial management, sales, purchasing, inventory, locations, warehouse activities, projects, fixed assets, manufacturing, reporting, and user access.
A manufacturer, for example, may need a much deeper solution design than a company using Business Central primarily for finance and basic order processing.
Production BOMs, routings, work centers, capacity, planning, component availability, production orders, and costing can all influence the design.
A company operating warehouses may instead have greater emphasis on receiving, put-away, picking, shipment, locations, and inventory movements.
The configuration should reflect those operational realities.
Data Migration: Decide What Deserves a Place in the New System
Data migration is not simply a technical exercise.
A legacy system can contain years of customer records, vendors, products, transactions, custom fields, inactive accounts, and duplicates.
Moving all of it may create a new problem: a cleaner ERP filled with old information that nobody actually needs.
Before migration, decide what the business requires.
That might include active master records, open documents, opening balances, selected historical information, and other data needed for operations or reporting.
Then check the quality of the source information.
Are customer records duplicated?
Are product codes consistent?
Are old vendors still active?
Are balances reconciled?
Do custom fields have somewhere sensible to go?
These questions should be answered before the final migration.
For organizations moving from older Business Central environments to Business Central online, Microsoft’s current migration guidance also distinguishes between approaches and explains that legacy customizations and extension data can affect what is transferred and how.
Review Legacy Customizations Before Migration
This deserves special attention for Dynamics NAV environments.
An older NAV installation may contain years of custom development. Some of it may be essential. Some may no longer be used. Some may have been replaced by functionality now available in the newer platform.
A useful review looks at each customization individually:
What does it do?
Why was it created?
Who depends on it?
Is the requirement still valid?
Can standard Business Central handle it?
Would an extension be a better fit?
Microsoft’s documentation also describes the transition from older C/AL-based customizations toward AL extensions in relevant upgrade scenarios.
That means an old customization list should be treated as project input, not as an automatic development backlog.
Identify External Systems Early
Business Central may need to work alongside several other applications.
A business might have an online sales platform, CRM, payroll application, banking connection, warehouse software, or another specialist system.
The important part is not simply knowing that an integration exists.
The project should define the relationship between the systems.
For every connection, document:
What information is sent?
Where does it originate?
Which system owns it?
When is it transferred?
What happens if the transfer fails?
Who deals with the error?
For example, saying that an online store “integrates with Business Central” says very little.
Does the integration send orders? Customers? Product information? Prices? Inventory availability? Shipment updates? Refund information?
The answers affect architecture, testing, support, and project scope.
Extensions Should Solve a Business Need
Business Central uses an extension-based development model for adding functionality. Microsoft’s AL documentation covers how extensions are used to extend the application.
From the company’s perspective, however, development should have a clear purpose.
Suppose a business has a genuinely specialized process that differentiates the way it operates. An extension may be worth developing.
Now consider a different request: an employee wants a custom page because the old ERP had one.
That request deserves more investigation.
The custom page may be useful, but it may also be a legacy habit with no meaningful business benefit.
Every custom component brings additional considerations around testing, maintenance, documentation, and future changes. The business should understand those trade-offs before approving it.
Test Scenarios, Not Just Features
A serious ERP test should resemble an actual day at work.
For example, a purchasing scenario might begin with a request and finish only after the invoice has been posted and the supplier payment process is ready.
A sales scenario might involve:
Order entry → inventory availability → fulfillment → shipment → invoicing
A manufacturing test could involve demand, planning, material availability, production orders, consumption, output, and costing.
The team should also test situations that do not go according to plan.
What happens when an item is unavailable?
What happens when a user does not have the expected permission?
What happens when an integration stops responding?
What happens when a migrated record contains unexpected information?
Those cases often reveal weaknesses that a simple demonstration never exposes.
Give Business Users a Real Role in Testing
Technical testing can tell you whether the application behaves as designed.
Business testing tells you whether the design makes sense.
That difference matters.
A warehouse supervisor may immediately notice that a process adds an unnecessary step. A finance manager may question a report because it does not support an important month-end decision. A buyer may discover that an approval route sends documents to the wrong person.
Those are not minor observations. They can indicate that the solution needs adjustment before launch.
Training Should Reflect Responsibilities
A user does not need to know every part of Business Central.
A person working in accounts payable needs different knowledge from someone receiving goods in a warehouse. A production planner has different responsibilities from a sales representative.
Role-based training makes the transition easier because employees learn the tasks they will actually perform.
Training also gives the project another chance to find weak spots.
When several users struggle with the same procedure, the answer may not be “provide more training.” The underlying process may need to be redesigned.
Prepare the Cutover Carefully
The period immediately before go-live is where small uncertainties can become operational problems.
The project team should have clear ownership for final data loading, data checking, access, integrations, unresolved defects, user communications, and support.
A cutover plan might answer questions such as:
Who performs the final migration?
Who verifies opening balances?
When do integrations move into production?
Who confirms user access?
Which issues prevent launch?
Who handles incidents on day one?
Microsoft’s implementation guidance treats preparation and transition to operation as explicit parts of the implementation lifecycle.
That is useful because the project does not suddenly become “finished” the moment users receive their new login details.
What Can Increase Implementation Effort?
Not every Business Central project is equally complicated.
The amount of work can increase when a business has:
Multiple companies or locations: More structures and processes may need to be coordinated.
Poor-quality source data: More time is needed for cleanup and validation.
Legacy customization: Existing code and modified processes require careful assessment.
Several integrations: Each connection introduces design and testing work.
Manufacturing operations: Production, planning, capacity, materials, and costing add functional depth.
Specialized warehouse processes: Inventory movement and fulfillment may require more detailed process design.
Limited user availability: Delayed business decisions can slow workshops, testing, and approvals.
Those factors are more useful for estimating project complexity than simply counting users.
How Much Does a Business Central Implementation Cost?
There is no single figure that applies to every organization.
Implementation economics can include more than the Microsoft subscription itself.
A project may involve consulting, data migration, integration work, custom development, training, testing, support, third-party applications, and internal employee time.
That is why two organizations with the same number of users can receive very different project estimates.
When reviewing a proposal, look at what the price actually includes.
A low initial number is not necessarily a low total cost if major activities have been left outside the scope.
For an accurate estimate, the project should first define its requirements, integrations, migration needs, development scope, and implementation responsibilities.
How Long Does Implementation Take?
There is no universal Business Central implementation schedule.
The timeframe depends on what is being changed and how prepared the organization is.
A company with a limited scope, clean data, few integrations, and straightforward processes is in a different position from a business introducing manufacturing, multiple entities, complex reporting, and several external connections.
The quality of decisions also matters.
Projects can slow down when requirements remain unresolved, users cannot participate in workshops, or testing starts too late.
A realistic timeline should therefore be built around actual scope and dependencies rather than an attractive generic promise.
Mistakes That Can Derail a Project
Some implementation problems are surprisingly avoidable.
Copying every old process
Not every legacy procedure deserves to survive the move.
Treating migration as an import job
Data needs business review as well as technical handling.
Approving custom development without testing alternatives
A requirement should be understood before development begins.
Discovering integrations near the end
External dependencies should be known early enough to influence design and testing.
Letting users see the system only at the end
Early involvement produces better feedback.
Treating go-live as the finish
The first period of live operation provides information that can guide further improvements.
Choosing a Business Central Consulting Partner
A consultant can contribute much more than system configuration.
Look at how the partner handles discovery.
Ask how requirements are documented.
Ask how they decide whether to configure, customize, extend, or integrate.
Ask how data migration is tested.
Ask how business users participate.
Ask what happens after go-live.
A strong partner should be comfortable explaining why a proposed approach is appropriate and where its limitations are.
You should be able to understand the reasoning, not just receive a list of technical tasks.
When Professional Business Central Consulting Is Most Valuable
Specialist help can be particularly useful when an organization is replacing an older ERP, moving from NAV, dealing with significant customization, connecting several external applications, introducing manufacturing or warehouse processes, or managing multiple entities.
The consultant can help bring functional and technical decisions together.
That may mean reviewing the current environment, challenging unnecessary complexity, defining the migration scope, planning integrations, supporting testing, or preparing the team for go-live.
The goal should be to leave the business with a system it understands and can operate, rather than a system that only the implementation team knows how to maintain.
Final Thoughts
A Business Central implementation is ultimately an exercise in making better choices about how the business works.
The software is important, but so are the decisions surrounding it.
A company that spends time understanding its processes will make better configuration decisions.
A company that cleans its data before migration will have fewer avoidable problems.
A company that questions legacy customization will have a better chance of reducing unnecessary complexity.
And a company that involves its users throughout the project will have a much clearer view of whether the new system actually works in practice.
Microsoft’s current guidance follows the broader principle of delivering value early and continuing to improve the solution as the organization learns from real use.
That is a useful way to think about Business Central implementation: not as one huge software event, but as a structured change in how the company operates.
Frequently Asked Questions
What should a company do before starting a Business Central implementation?
Define the business objectives, document important processes, identify requirements, review current data, list integrations, and identify major legacy customizations.
Is fit-to-standard important for Business Central?
Yes. Reviewing standard capabilities first can help the organization avoid unnecessary development and make better decisions about genuine functional gaps.
Should all legacy customizations be moved?
No. Each customization should be reviewed to determine whether its business purpose still exists and whether another approach is now more suitable.
What data should be migrated?
That depends on operational, reporting, legal, and business requirements. Active master data, open transactions, balances, and selected history are common considerations, but the scope should be decided project by project.
Can Business Central connect with other business applications?
Yes. The exact integration approach depends on the applications involved, the information exchanged, and the required business process.
Why is user acceptance testing important?
It allows business users to confirm that the designed solution supports real work, including normal transactions, exceptions, approvals, reporting, permissions, and integrations.
Does Business Central implementation stop at go-live?
No. Support, issue resolution, user feedback, process refinement, and optimization continue after the system enters production.
