The go live checklist we work from on Business Central projects

Readiness items on the Business Central go live checklist

Go-live should be a decision, not a date that arrives. Agree on the criteria in advance. Every core process has passed user acceptance testing in a sandbox. Open issues are either fixed or accepted with a workaround. The people who will use the system have trained on their own tasks, using the company's own data.

Run at least one full rehearsal of the cutover. Load the data into a fresh sandbox copy. Use the same files and the same order that you will use on the day. Note how long each step takes and what went wrong. Then the rehearsal notes become the cutover plan.

Data to load and reconcile

Master data comes first. That means the chart of accounts, customers, vendors, items, bank accounts and fixed assets, usually through configuration packages. Then load open transactions as of the cutover date. These are unpaid customer and vendor invoices and open sales and purchase orders. Stock on hand goes in through item journals, with its cost. The closing trial balance goes in through a general journal.

Reconcile each load to the old system before anyone posts anything new. Receivables, payables and inventory totals in Business Central should equal the control accounts in the trial balance you brought across. The trial balance itself should net to zero. Keep the source reports as evidence.

Setup and security on the Business Central go live checklist

Check the settings that are easy to forget. Number series should start where the old system stopped. That includes the next check number on each bank account. Allowed posting dates in General Ledger Setup should cover the opening entries and the first live period. Also test print each document layout.

Confirm that every user has a license assigned and the permission sets for their role. Nobody outside the administrators should hold SUPER. Set up approval workflows and their approvers. Remove test transactions by starting from a clean production company. Do not delete entries from the company used for testing.

Integrations, jobs and extensions

Every integration tested against a sandbox must be re-pointed at production. It must also point at the live account on the other side, whether that is a web shop, a bank, a payroll provider or an EDI network. Check credentials. Send one real transaction through each connection before you declare it ready.

Install the final versions of your extensions and AppSource apps in production. Confirm that the versions match what was tested. Create the job queue entries for cost adjustment, scheduled reports and integration sync, and set them to ready. Also confirm that an email account is set up for outgoing documents.

Day one items on the Business Central go live checklist

Set the old system to read-only, so no one keys into it by habit. On the first day, keep experienced users and your implementation team available to answer questions. Post the first real order, invoice and payment early. Then trace each one through to the ledger.

The first period close is the true test. So schedule extra time and support for it. Reconcile banks, subledgers and inventory with care. Resolve differences while memories are fresh. If you would like experienced help with a cutover, or a second opinion on your plan, our consultants support go-lives remotely.

Business Central go live checklist: questions

When is the best time to go live?

The start of a fiscal period is easiest, because opening balances then tie to a closed trial balance. Many companies choose the start of a fiscal year or quarter. Avoid your busiest season. Also avoid any date when key finance or operations staff are away. So the date comes from the calendar of the business, not from the project plan.

Should we migrate transaction history?

Most companies bring master data, open documents and balances. They keep detailed history available in the old system or in a reporting database. Summary general ledger history by period is sometimes loaded for comparative reports. Loading full detailed history adds effort and risk for limited benefit. So decide which reports you truly need from history before you plan the load.

What if something goes wrong on cutover day?

Decide the fallback in advance. Until new transactions are posted, you can stop and continue in the old system. Define the point of no return in the plan. Then hold a go or no-go check just before it, with the reconciliation results in hand. So a Business Central go live checklist always includes the conditions that would stop the launch.

Do we need to run both systems in parallel?

A long parallel run doubles the workload, and it is rarely needed if acceptance testing and the rehearsal were thorough. A better use of effort is a strong test cycle beforehand. Then reconcile opening balances and the first close with care afterwards. Keep the old system read-only for lookups, so staff can still check history.

Who should be involved in the go or no-go decision?

The project sponsor, the finance lead, a representative from each operational area and the implementation lead. Each confirms their area against the agreed criteria. A decision made by the whole group is easier to stand behind than one made by the project manager alone. Write the outcome down, with the date and the names, in the project record.

Related guides to the Business Central go live checklist

Go-live is the last stage of a longer project. These pages cover the implementation checklist that comes before it. They also cover migration planning, and the support we provide around cutover. Start with the cutover plan guide, since it turns each line of this Business Central go live checklist into an ordered task with a named owner. For the product detail, see Business Central documentation on Microsoft Learn.