A Business Central project can look very different depending on the company.
For one business, the biggest headache is inventory. For another, it’s finance. A manufacturer may be trying to get purchasing, production, and stock information into the same workflow, while a growing distributor may simply be tired of managing orders across several disconnected systems.
So there isn’t much value in starting an implementation with a giant list of features.
Start with the problems.
What takes too long today? Where does information get entered twice? Which reports require manual work? Where do employees stop trusting the system and start checking their own spreadsheets?
Those answers give the project somewhere useful to begin.
The Discovery Phase Should Get Uncomfortable
People are usually quite good at explaining how a process is supposed to work.
The interesting part is what happens when something goes wrong.
A customer changes an order after it’s been entered. A supplier sends less stock than expected. An invoice doesn’t match the purchase order. A manager needs a report that isn’t available.
Follow those situations.
They often expose the unofficial procedures that have grown around the old ERP.
Someone keeps a spreadsheet. Someone sends an email. Someone phones another department to confirm a number. None of these steps may appear in the formal process documentation, yet the business depends on them.
An implementation team needs to know about those things.
Then Comes the Hard Question: Do We Still Need It?
Once the current operation is understood, don’t automatically reproduce it.
A company may have spent years building workarounds around an old system. Recreating every workaround in Business Central would mean carrying yesterday’s limitations into tomorrow’s system.
Look at the standard functionality first.
Maybe the new system can handle the requirement without any special development. Maybe the process itself can be simplified. Maybe an integration solves the problem more cleanly.
And sometimes customization really is necessary. That’s fine.
The mistake is deciding that before understanding the requirement.
Data Has a History
Every ERP database has one.
There are records nobody uses anymore. Names entered differently by different people. Customers who appear twice. Products that were discontinued years ago. Old codes that still show up in reports.
The migration team can move all of it.
That doesn’t mean they should.
Someone who understands the business needs to decide what belongs in the new system and what doesn’t. Then the technical team can work on cleaning, mapping, transforming, and loading the selected information.
Run that process more than once.
A trial migration gives users something concrete to inspect. It’s much easier to correct a bad customer record in a test environment than to explain the problem after employees have started using the live system.
Business Central Has to Fit Into the Rest of the Business
The ERP isn’t necessarily the center of every process.
A customer might place an order through a website. The order reaches an e-commerce platform first. Customer information sits in a CRM. Payment is handled somewhere else. A shipping provider sends tracking information back later.
All of those handoffs matter.
Someone needs to decide where the authoritative information lives and what each system is responsible for.
The technical connection is only half the job. The business rules behind the connection matter just as much.
Don’t Test Like Everything Is Going Well
A test environment can be deceptively comfortable.
The data is prepared. The steps are known. The project team is standing nearby.
That’s not how Tuesday morning will feel after go-live.
Let employees work through ordinary transactions without someone guiding every click. Then introduce problems.
Change a sales order. Enter the wrong quantity. Try to process something that isn’t available. Correct an invoice. Interrupt an integration. Ask a user to find information they haven’t been shown directly.
You learn much more from this than from watching someone complete a perfect demonstration.
Go-Live Is Mostly About Timing
The actual switch can involve dozens of small decisions.
When does the old system stop accepting transactions? When is the final data extracted? Who checks the migrated information? When are integrations activated? Who confirms that users can access what they need?
These jobs shouldn’t exist only in somebody’s head.
Write them down. Give each task an owner. Walk through the sequence before launch.
A rehearsal doesn’t guarantee a perfect go-live, but it can expose obvious gaps while there is still time to do something about them.
The First Month Is a Reality Check
Once the system is live, the business starts producing situations nobody thought to include in a workshop.
A user discovers a quicker way to complete a task. Finance encounters an unusual transaction. Management wants another view of the data. Somebody asks why a process works differently from the old system.
Some requests deserve attention immediately.
Others don’t.
The implementation team and business should keep a practical list and decide what needs fixing now and what can wait. This prevents every new request from turning into a fire drill.
It also creates a useful improvement backlog based on real usage rather than assumptions.
What a Good Implementation Should Leave Behind
At the end of a Business Central Implementation Process, the company should have more than a new ERP login.
It should have fewer unnecessary workarounds.
Employees shouldn’t need five unofficial spreadsheets to understand what’s happening. Important information shouldn’t depend on one person remembering a manual step. Connected applications should have clear responsibilities. Users should know how the processes work and where to get help when something goes wrong.
That’s a much better measure of success than simply saying the project went live.
Business Central is the technology. The implementation is where the business decides what to do with it.
