Business Central go live support for a calm cutover

Readiness checks for Business Central go live support

A launch date means little until the system has passed a readiness check. We go through every area with the owner responsible for it. Are the test scripts signed off? Are the users trained? Do the integrations run? Do the printed documents look right? Can each person sign in with the permissions their job needs?

The result is a plain list of open items. Each is marked as a blocker or as something that can wait. Managers then make an informed choice to proceed or to move the date. Postponing because of a known gap is far cheaper than finding that gap with customers waiting for shipments.

Rehearsing the cutover in a sandbox

We write the cutover as a numbered runbook. It says who freezes the old system and who extracts the data. It names which configuration packages load in which order, and who confirms each total. Then we carry out the whole sequence in a sandbox. We time each step. We fix the runbook wherever reality differs from the plan.

A rehearsal exposes the problems that documents hide. Consider a customer file with duplicate numbers. Consider an item without a posting group, or an open order that points to a closed period. Each is cheap to fix in practice and costly on the real night. Bigger data sets get a second run.

What Business Central go live support covers at cutover

During the cutover, we load master data, open customer and vendor entries and inventory quantities and values. We also load open orders and the general ledger opening balances. We reconcile each load against the old system before the next begins. Your finance lead confirms the trial balance. Only then may users start posting.

Alongside the data, we turn on what was held back during testing. That means job queue entries, integrations pointing at live endpoints, email settings, bank connections and number series starting values. We set the legacy system to read only. So nobody keeps posting there out of habit.

Business Central go live support through the first real transactions

The first live stretch is when users meet situations no test script covered. We keep consultants on call during US business hours. Questions take a short path: a shared channel, a quick screen share, an answer. We log issues with their cause. So the same question from three people becomes one fix or one training note.

We also watch what users cannot see. At first, we check posting errors, failed job queue entries and stuck integration messages daily. We check unusual inventory adjustments too. Catching a wrong posting group in the opening stretch is simple. Finding it at year end means correcting a lot of entries.

First month end: where Business Central go live support hands over

The first period close is the real test of a new system. We walk your accountants through it step by step. The steps are bank reconciliation, the inventory cost adjustment and accruals. They also include the VAT or sales tax settlement where it applies, and the financial reports. Together, we trace anything that does not tie out to its source.

Once the close is clean, launch support hands over to ordinary support. We pass on the issue log. We also pass on the list of agreed improvements left for a later phase. The pitfall to avoid is ending help on launch day. The questions that matter arrive with real work.

Business Central go live support: what buyers ask

What does go live support include?

It includes a readiness check and a rehearsed cutover runbook. It covers loading and reconciling opening data and turning on integrations and scheduled jobs. Support for users during their first live transactions comes next. Then we guide you through the first month end and hand over to regular support.

Can you support a launch that another partner is running?

Yes. We can act as extra hands during cutover. We can also give an independent check on readiness. First, we ask to see the test results, the data migration plan and the open issues first. So our advice rests on the actual state of the project.

Should we run the old system in parallel?

Usually not for long. Entering every transaction twice exhausts people, and the two systems rarely agree. A rehearsed cutover gives better assurance with far less effort. It uses reconciled opening balances and keeps the old system read only for lookups.

When is the best moment to switch?

The start of a fiscal period keeps opening balances simple. A quieter trading stretch gives users room to learn. We avoid dates right before a peak season or a major audit. We also avoid a Microsoft update window for your environment.

What happens if something goes wrong during cutover?

The runbook names a fallback point. Until that point, you can reopen the old system. We reconcile loads one at a time. So we catch a problem at the step that caused it. Most are corrected and reloaded without changing the date.

Around the launch

Launch support sits between the project and everyday running. These pages cover the implementation and data work that come before Business Central go live support, and the support that follows. Read them to plan the whole launch. Then use our contact page to tell us your target date, and we will outline a readiness check. For the product detail, see Business Central documentation on Microsoft Learn.