Building an implementation project plan for Business Central that people follow

How to structure a Business Central implementation project plan

Organize the plan by workstream first and by phase second. Typical workstreams are project management, finance, sales and purchasing, inventory and warehouse, data migration, integrations, development, reporting, training and cutover. Add manufacturing if you use it. Each workstream has a named lead on your side and a consultant beside them.

Under each workstream, list tasks that end in something you can see. Examples are a decision recorded, a setup area configured, a data load reconciled or a test passed. Tasks described as ongoing activity cannot be marked complete, so they hide slippage. Keep detail high for the phase you are in. Keep it lighter for later ones.

Milestones in a Business Central implementation project plan

A milestone is a point where something is proven. A meeting held does not count. Good ones include scope and fit-gap signed off and a first configured company for key users. Others are a first trial data load reconciled, extensions ready for testing, user acceptance passed and the go-live decision taken.

Give each milestone written exit criteria agreed in advance. Design is complete when every gap has a decision. It is not complete just because the workshops have ended. Testing is complete when the agreed scenarios pass with no blocking issues open. Criteria remove most of the argument about whether the project is on track.

Dependencies and the critical path

Some tasks cannot start until others finish, and those chains decide the date. The chart of accounts and dimensions come before posting groups. Those come before any transaction test. Item and customer data must be loaded before process testing. Extensions must be finished before acceptance testing can be trusted.

The longest chain is the critical path. In most projects it runs through data and through third parties, such as a bank's file format, an EDI partner's test slot or a carrier integration. Start those conversations early, because their timing is not yours to control. Show them as separate lines in the plan.

Owners, capacity and the business calendar

Every task has one owner, and that owner is a person, not a department. Be realistic about capacity. The finance lead who must design the chart of accounts is also closing the books. Plot month-end, year-end, stock counts, peak season and holidays against the plan before fixing any milestone.

Choose the go-live date with the same care. The start of a fiscal period makes cutover balances cleaner, and a quiet trading period gives people room to learn. Then build the plan backwards from that date. Check whether the early phases still have enough room. If they do not, move the date or cut scope.

The cutover section of the implementation project plan

Cutover deserves its own detailed schedule, down to the hour and the person. It lists the freeze on the old system, final data extracts and loads in order. It also lists reconciliations with sign-off, integration switch-over, user access and the go or no-go checkpoint. Rehearse it in a sandbox before the real day.

Plan the period after go-live too. Say who answers questions on the first day, how issues are logged and ranked, and when the first month-end is closed with support on hand. Keep the plan alive with a short weekly update of tasks done, tasks late and decisions needed. A plan nobody updates is a record, not a tool.

Business Central implementation project plan: questions

What tool should the project plan be kept in?

Use whatever the team will open every week. A shared task board or a simple spreadsheet works for many mid-sized projects. Scheduling software helps when dependencies are complex. The habit of updating the plan matters far more than the tool that holds it. So pick the tool people already know, and agree who updates it and when each week.

How long does a Business Central implementation take?

It depends on scope, the number of companies, data quality, integrations and how much time your team can give. We do not publish a standard duration, because any figure would hide the real drivers. Instead, a short discovery produces a Business Central implementation project plan for your own situation. Then you can defend the dates in it.

Who should own the plan, us or the partner?

Both, with clear lines. The partner usually maintains the plan and its dependencies. Your project lead owns the tasks assigned to your staff and the business calendar. One shared plan is essential, because two separate versions drift apart within a few meetings. So agree a single master copy in the first week, and keep every update in it. Both sides then work from the same Business Central implementation project plan.

What usually causes a plan to slip?

Data cleanup that starts late is the usual cause. Others are decisions that wait for a busy manager, scope added without adjusting the date, third-party integrations and key users pulled back to daily work. Each can be seen early if the weekly update is honest. So ask the plan owner to flag any task that moves twice.

Should the plan include work after go-live?

Yes. Include the support period, the first month-end close and items deliberately deferred from scope. Add a check of how the system is used once things settle. Writing the deferred items down is what makes it possible to say no to them before go-live. So the Business Central implementation project plan should not stop at cutover.

Related planning pages for your implementation project plan

A Business Central implementation project plan rests on a method and ends in a cutover. These pages cover the methodology behind the phases, the implementation checklist, change management and support during go-live. Start with the methodology page, so the phases in your plan match a sound structure. Then use the checklist to confirm that no stage is missing from the plan. For the product detail, see Business Central documentation on Microsoft Learn.