Most Business Central go-lives don’t fail because the software breaks. They fail because a checklist got treated as a formality, signed off in a meeting rather than actually verified in the system or because it only asked whether the system was ready and never seriously asked whether the people were.
Here’s what that looks like in practice. Opening balances reconcile to the penny, every integration posts correctly, the sandbox-to-production migration runs clean and three weeks later, the warehouse team is still emailing spreadsheets around because nobody walked them through processing a return in the new Sales Return Order screen, or finance is manually re-checking every G/L entry because they don’t yet trust the automated bank reconciliation. Nothing broke. The system works exactly as configured. It’s failing anyway, because readiness was only ever measured on the technical side.
This guide is built the way we’d actually run a go-live: covering the technical checklist your implementation partner should already own, but going into real depth on the training, UAT, and adoption side, the part that decides whether a Business Central rollout actually sticks once the project team moves on to the next thing.
Technical readiness vs. People readiness
Every go-live checklist is really running two tracks in parallel, and conflating them is where most gaps hide.
Technical readiness asks whether Business Central itself works: do opening balances tie out, are posting groups configured correctly, do integrations write back cleanly. It’s owned by IT and your implementation partner, and when it fails, it fails loudly and immediately, a batch job errors out, a bank feed won’t reconcile, an approval workflow stalls on a missing approver.
People readiness asks whether your organization can actually operate inside Business Central day to day: has the AP clerk actually processed a three-way match without help, did the warehouse manager sign off on the inventory process because they ran it themselves not because IT said the screen loads correctly. This track is owned by department managers and the super users you name before go-live, and when it fails, it fails quietly. Nobody files a ticket for “I don’t trust this yet.” They just quietly go back to the workaround they know.
You need both tracks genuinely ready, not just technically signed off, before you commit to a cutover date. What follows covers the technical side at a summary level, your implementation partner should already have significant depth here and goes deep on the people side, because that’s where preventable go-lives actually go sideways.
Technical readiness: what your implementation partner should have covered?
This isn’t the full technical checklist that lives with whoever’s running your implementation but if any of the following can’t be confirmed with evidence rather than an assurance, it’s worth raising before you go further.
- Master data — customers, vendors, items, G/L accounts, resources, fixed assets — is fully migrated with number series that won’t collide with legacy document numbers once you’re live.
- Posting groups (General Business, General Product, Customer, Vendor, Inventory, VAT) are configured and have been tested with real sample postings, not just reviewed on paper.
- Opening balances in the General Ledger reconcile exactly to the last closed period, and Item Ledger Entries reflect a verified physical count or a frozen legacy snapshot — inventory valuation errors here are some of the hardest to untangle after go-live.
- Permission sets are assigned by role and tested by having an actual user in that role attempt real tasks in a sandbox environment — not just reviewed against a spreadsheet of what they should be able to do.
- Every integration (ecommerce, CRM, banking, EDI, payroll) is pointed at the production environment, not sandbox, and field mappings have been verified with live test records flowing in both directions.
- Approval workflows are configured with the actual people who’ll approve transactions, not placeholder approvers left over from testing.
- A production backup has been taken and an actual restore has been tested — confirmed, not assumed.
Training: the gap between “attended” and “can do the job”
“The team went through training” and “the AP clerk can process a three-way match without help” get treated as the same statement more often than they should be. They’re not. The first describes an event that happened. The second describes a capability that was verified. The distance between them is usually where week-one confusion actually comes from.
Business Central’s Role Center design makes this both easier and easier to get wrong. Every user lands on a Role Center tailored to their job — an Order Processor sees a different home screen than an Accounting Manager — which means generic, one-size-fits-all training sessions genuinely don’t map to how anyone actually works in the system. A single two-hour overview session covering “how Business Central works” leaves an AP clerk knowing roughly nothing more useful than before about how to actually post an invoice through their own Role Center.
What holds up better in practice:
- Training is structured around each person’s actual Role Center and the specific tasks they’ll perform in it — not a system-wide tour.
- Completion is tracked by demonstrated task, not attendance. Can this person post a purchase invoice end to end, unassisted? That’s the bar, not “was in the room.”
- Training happens with enough lead time before go-live to let a second pass catch what didn’t stick the first time — not crammed into the final week when there’s no time left to reinforce anything.
- Quick-reference material exists in a place people will actually find it under pressure — pinned in Teams, printed at a workstation — not buried in a shared drive folder nobody’s opened since the project kicked off.
- A named super user exists in every department — a specific person, not an assumption that “someone will figure it out” when the questions start.
UAT and sign-off: who confirms readiness matters?
A developer confirming “the screen works” and a department lead confirming “this matches how we actually process a customer return” are answering two different questions, and only one of them predicts whether go-live goes smoothly.
User acceptance testing in Business Central should run in a sandbox environment refreshed from production data, using test scripts that walk through complete business processes end to end — not isolated screen checks. A returns process, for example, needs to be tested as the whole sequence: creating the Sales Return Order, receiving the item back into inventory, issuing the credit memo, and confirming the G/L impact lands where finance expects it. Testing each step in isolation misses exactly the kind of handoff problem that shows up for real in week one.
- Every critical business process has a documented test script that was run end to end, not spot-checked.
- Sign-off comes from the person who owns that process day to day, not from IT confirming the underlying functionality technically works.
- Edge cases — partial shipments, credit memos, backorders, multi-currency transactions if relevant — are tested explicitly rather than assumed to work because the standard case did.
- Known issues are logged with a decision attached: fixed before go-live, or accepted with a documented workaround everyone’s aware of.
- Whoever tested a process is the same person who’ll be running it after cutover — testing by proxy tends to miss the details that actually trip people up.
Testing the system and the people, separately
Most mock go-lives only test the system: a timed data migration into a fresh sandbox copy, a technical smoke test, confirmation that integrations fire correctly under something resembling production load. That’s necessary and it belongs on the checklist — but it only answers “does the system work.” It says nothing about whether your people can actually operate inside it under real conditions.
A rehearsal that also tests people looks different. It puts actual end users — not the project team, not IT — in front of a refreshed sandbox and has them run real transactions the way they will on day one: a warehouse associate processing an actual-looking shipment, an AP clerk entering and routing an invoice through the real approval workflow. This surfaces a different category of problem than the technical rehearsal does. Not “did the integration fail,” but “does the person doing this job every day know which screen to open, and how long does it actually take them to get through it.” Those are exactly the gaps that show up for real in the first week if nobody catches them here first.
- A full mock go-live has been run against a copy of production data, refreshed close enough to go-live that it reflects real conditions.
- Actual end users — not the project team — ran real transactions during the rehearsal.
- Time-to-complete was measured for key tasks, not just whether the task technically succeeded.
- Gaps the rehearsal surfaced were fixed before cutover, not logged for “later” and quietly forgotten.
Cutover day
- A minute-by-minute runbook exists with named owners and expected timings for each task, not a general sequence everyone’s supposed to remember.
- The legacy system’s freeze time is communicated clearly and actually enforced — a stray transaction entered after the freeze is one of the more common causes of a reconciliation that won’t tie out.
- A go/no-go checkpoint is scheduled after the final data load and validation, with specific pass/fail criteria agreed in advance, not decided in the moment.
- One named person has the authority to trigger a rollback if criteria aren’t met — shared ownership with no single decision-maker is how a bad situation drags on instead of getting resolved.
- The rollback plan has actually been rehearsed, not just written down and filed away.
- Support is staffed and visible from the first hour Business Central is live — not set up reactively once the first question comes in.
Hypercare: built around adoption, not just defects
Hypercare gets defined most often as a support window scoped around defects — log the bug, fix the bug, move on. That framing misses the more common failure mode: people quietly reverting to the workaround they trust because the new way still feels unfamiliar, not because anything is technically broken. A hypercare period built only to catch bugs will miss almost all of that, because nobody files a ticket for “I don’t trust this yet” — they just go around it.
A hypercare period built around adoption looks for a different signal. If three people from the same team ask the same question in the first week, that’s not three isolated questions — it’s a training gap that a quick refresher session fixes faster than answering the same thing three separate times ever will.
- A hypercare period, typically two to four weeks, is scheduled with dedicated support availability — not folded into whoever has spare time.
- Daily office hours exist as a standing window for quick questions, separate from a formal ticket queue that feels like too much friction for a small clarification.
- Repeated questions from the same team get treated as a signal to address the underlying gap, not just answered one-off each time they come up.
- A named point of contact — ideally the super users identified before go-live — is visible to each department during this period.
- The first live month-end close gets active support, since it’s often the point where processes that looked fine in daily use reveal a gap nobody caught in testing.
- A 30/60/90-day check-in asks whether the system is actually being used the way it was designed, not just whether it’s still technically stable.
If your team doesn’t have the bandwidth to staff this properly on top of everything else running during a go-live, this is exactly the gap dedicated go-live support is built to close.
Common go-live mistakes we see
| Mistake | Why It Happens | How to Prevent It |
| Training scheduled the week before go-live | Training gets pushed back first when the project timeline slips | Lock training dates early and protect them from schedule slippage the way you would a technical milestone |
| UAT signed off by IT instead of the process owner | Faster to get one technical sign-off than coordinate every department | Require sign-off specifically from the person who runs the process day to day |
| No named super users going into go-live | Assumed someone will naturally step into the role once questions start | Name specific people per department before go-live, not after the first week of confusion |
| Hypercare ends the moment the system is technically stable | Support gets scoped around defects rather than adoption | Extend hypercare through the first month-end close and a 30-day adoption check-in |
Where FlexPro365 Fits Into a Go-Live Plan Like This
Most of this checklist doesn’t need an outside partner, a disciplined project lead can run the technical readiness track with an implementation partner and get through it fine. Where teams consistently run out of bandwidth is the second track: someone has to actually sit with the AP clerk until they can post a three-way match unassisted, chase down a real process-owner sign-off instead of accepting a rushed one from IT, and stay present through hypercare watching for the quiet reversion to spreadsheets rather than waiting for a bug ticket that never comes.
That’s the specific gap FlexPro365 works in:
- Before go-live — business central training services built around each person’s actual Role Center, tracked to a demonstrated task rather than a completed session, plus UAT support that makes sure sign-off comes from the person who runs the process, not whoever’s fastest to say yes.
- During cutover — a second set of eyes on the people side of the runbook, not just the technical one.
- After go-live — hypercare that tracks adoption signals, not just defect counts: repeated questions from the same team, workarounds people quietly fall back on, whether the first live month-end close actually goes smoothly.
If your team has the technical side covered but is stretched thin on the part that determines whether people actually adopt the system, that’s the conversation worth having before a cutover date gets locked in.
