An implementation methodology for Business Central, phase by phase

The phases of a Business Central implementation methodology

Most methods share the same backbone. Discovery sets the scope and how the business works today. Design decides how each process will run in Business Central. Build covers configuration, extensions, integrations and data. Test proves it with real users. Deploy is the cutover, followed by a period of close support.

What separates one approach from another is how the phases overlap. A strict waterfall finishes design before anything is built. An iterative approach configures a working company early and refines it in rounds. Business Central works well out of the box. So the iterative route usually shows problems sooner and costs less to correct.

Standard first in a Business Central implementation methodology

A sound method starts from the standard product. Each requirement is walked through in Business Central as delivered. Then it is sorted into one of four answers. It fits, it fits with configuration, it needs an add-on, or it needs development. Only the last two add cost and upkeep. So they deserve a clear business reason.

The fit-gap list becomes the scope document that everyone can read. Each gap has an owner, a decision and a priority. Many gaps disappear when people see the standard process work with their own data. That is why you should settle the list in workshops. A requirements spreadsheet alone is not enough.

Workshops in a Business Central implementation methodology

Design sessions work best in a sandbox loaded with a sample of your own customers, items and chart of accounts. Process owners see a sales order become a shipment and an invoice with their data. Then they say what is missing. The team records decisions there and then, with the reason.

Repeat the loop by area. Take finance, sales, purchasing and inventory, then whatever is specific to you. After each round, the configured company is closer to the final one, and the key users know it better. By the time formal testing starts, they have already used most of the system several times.

Data, testing and training as one thread

Data migration is rehearsed more than once. Each trial load exposes duplicates, missing fields and mapping errors. There is still room to fix them at the source. Testing builds from single functions to complete processes. It ends with a user acceptance test, run by your staff against written scenarios.

Training ties to the same scenarios. People learn the process they will run, in the company they will use. The test scripts become the first user guides. A method that leaves data and training to the end tends to find its biggest problems when there is least room to deal with them.

Governance that keeps the implementation methodology honest

Every project needs a sponsor who can decide. It also needs a project lead on the client side, process owners for each area and a consultant lead. Short, regular steering meetings look at scope changes, risks and decisions awaited. The team writes down a change to scope, with its effect, before anyone starts work on it.

Microsoft publishes its own guidance for Dynamics 365 projects, called Success by Design. Its themes match what works in practice. Decide early, stay close to standard and check readiness before go-live. The go-live decision itself should rest on agreed criteria. A calendar date alone is not enough.

Business Central implementation methodology: common questions

Is an agile or a waterfall method better for Business Central?

A blend usually works best. Scope, budget and the cutover approach are fixed early, as in waterfall. Configuration and design move in short rounds with users. Pure waterfall delays feedback, and pure agile makes it hard to commit to a date. So a good Business Central implementation methodology mixes the two, and it names which parts are fixed.

How much of our team's time does the method assume?

More than most companies expect. Process owners attend workshops, clean data and test. A project lead keeps decisions moving. You cannot hand the work entirely to a partner, because only your people know how the business needs to run. So plan cover for their daily duties, and agree the hours for each role at the start.

What documents should the method produce?

At minimum, you need a scope and fit-gap list and a design record of decisions for each process. You also need a data migration plan with mappings, test scenarios with results, a cutover plan and short user guides. Keep each one brief enough that people actually read it. A long document that nobody opens protects nobody. Those pieces make a Business Central implementation methodology something a team can follow.

How does the method handle customization requests?

Each request goes through the fit-gap step. Can standard do it? Can configuration? Is there an established add-on? Only then does the team consider an extension. Approved development is built in AL as an extension, so it survives updates. Any competent developer can then maintain it. This keeps customization small and well documented.

When is a phased rollout better than a single go-live?

A phased rollout is better when the scope is wide or the company has several entities or sites. Finance and core trade can go first. Warehousing, manufacturing or further companies follow. Phasing lowers risk. However, it means running temporary processes between phases, and that needs planning. We can help you weigh the two options.

Related topics for your Business Central implementation methodology

A Business Central implementation methodology is the frame. These pages fill it in with the practical pieces. They include the step-by-step guide, a project plan outline, fit-gap work and user acceptance testing. Read the step-by-step guide first, then use the project plan outline to turn the phases above into dates and owners for your own company. For the product detail, see Business Central documentation on Microsoft Learn.