+1 480 485 7373
Microsoft Teams
Treat a Business Central go-live as a decision, not a date
A go-live date is useful because it focuses everyone. Still, the project should earn that date, and it should never override evidence. The right question a few days out is not whether the date has arrived. It is whether process owners have signed off testing, balances reconcile and users can do their jobs. You also need a clear way back if something serious goes wrong.
Most companies switch at the start of a month or a quarter, after closing the prior period in the old system. That gives clean opening balances and a natural comparison point. Switching mid-period is possible, but it doubles the reconciliation work. It also makes the first month end in Business Central much harder.
Go-live checklist items to confirm in the final days
- ✓Acceptance testing signed off by every process owner, with open items listed and agreed
- ✓Every user set up with the permission sets they tested with, and each person able to log in
- ✓Number series for invoices, orders, receipts and payments set to continue from the old system
- ✓Posting groups, tax setup and the chart of accounts locked against casual changes
- ✓Bank accounts, check layouts and payment export formats tested with the bank
- ✓Integrations repointed from sandbox endpoints to production, with credentials in place
- ✓Document layouts for invoices, statements and purchase orders approved and loaded
- ✓Training complete, with a short quick-reference sheet for each role
- ✓A support rota for the first days, naming who answers which kind of question
The cutover sequence on your Business Central go-live checklist
- 1
Freeze the old system
Stop new postings in the legacy system at an agreed moment. Tell every department, including anyone who enters transactions from home.
- 2
Close and extract
Finish the period close in the old system. Then take final extracts of customers, vendors, items, open invoices, open orders and the trial balance.
- 3
Load master data and open items
Import master records first, then open receivables and payables at document level so aging and payment matching work from day one.
- 4
Post opening balances and inventory
Enter general ledger balances and item quantities with values from a recent count. Use a clearing account that should end at zero.
- 5
Reconcile before anyone posts
Tie the trial balance, customer and vendor aging and inventory valuation back to the old system. Then have the controller sign the comparison.
- 6
Switch on integrations and users
Enable scheduled jobs and connections, and release users into production. Next, post a first real transaction together while the team watches.
Go or no-go criteria for your go-live checklist
Watching the first days after a Business Central go-live
A short daily stand-up
Fifteen minutes each morning with department leads and the consultant to raise blockers, agree priorities and spot patterns early.
Posting error queue
Someone checks job queue entries and integration logs daily. That way you catch a failed sync in the morning, not at month end.
An early bank reconciliation
Reconcile the bank within the first days rather than waiting for month end. It is the fastest proof that postings land correctly.
Fix list with owners
Every reported issue goes on one shared list with a severity, an owner and a status. Keep that list as the last page of your Business Central go-live checklist, so nothing lives only in an inbox.
Business Central go-live checklist questions from controllers
When is the best time to go live on Business Central?
The start of a new month or quarter is the cleanest point, right after you close the previous period in the old system. It gives you tidy opening balances and a clear comparison for the first close. Avoid your busiest season and the days just before a year-end audit. Fiscal year start is attractive but not required.
Should we run the old and new systems in parallel?
Usually not in full, because double entry exhausts staff and the two systems drift apart anyway. A better approach is thorough testing on migrated data, followed by close monitoring of the new system. Keep the old system available read-only for lookups and comparisons. Limited parallel checks on a few critical calculations, such as payroll postings or complex pricing, can make sense.
What should our fallback plan look like?
It should say in writing which failures would make you stop and who decides. It should also say what the business does in the meantime. For most companies, that means keeping the old system intact and readable until the first Business Central close ends. You will rarely need the plan, but writing it forces an honest look at readiness. It also calms staff who are nervous about the switch.
Open orders and staffing on go-live day
How do we handle open sales and purchase orders at cutover?
Migrate them as open documents with their remaining quantities, so warehouse and purchasing can carry on without re-keying. Partially shipped or received orders need special care, because only the outstanding portion should come across. Check a sample line by line against the old system before releasing users. Close orders that are really dead in the old system instead of migrating them.
Who should be available on go-live day?
Your key users, the process owners, someone with administrator rights, and the implementation consultants. Each person should know which questions come to them and how to reach the others quickly. Having the controller present for the first postings and reconciliation is especially valuable. Senior sponsors should be reachable for decisions, even if they are not watching every transaction.
Talk to us about your project.
Tell us what you run today and what has to change. A senior consultant replies with a written next step.