News & Insights / Business Central implementation checklist

Business Central Implementation Checklist: Data, Testing and Go-Live

Published 8 October 2026 · Dynamic Aspect

A successful Business Central project needs more than correct configuration. Business outcomes, data, integrations, permissions, testing, training and cutover all have to be ready at the same time. This checklist gives project sponsors, process owners and delivery teams a practical way to review readiness from discovery through post-go-live support.

Use it as a working control list, not a substitute for a project plan. Assign an owner and due date to every applicable item, attach evidence and record the decision when an item is not relevant.

How to use this checklist

1. Confirm which companies, locations, processes and integrations are in scope.
2. Mark every item green, amber, red or not applicable.
3. Link each green item to evidence such as an approved design, reconciliation or signed test result.
4. Give every amber or red item an owner, action and target date.
5. Review the checklist at each stage gate and before the final go/no-go decision.

A green status should mean evidence exists. "The team believes it is ready" is not evidence.

1. Outcomes, scope and governance

The project needs a shared definition of success before configuration begins.

• An executive sponsor owns the business outcome and can resolve cross-team decisions.
• The project manager, product owner and workstream leads are named.
• In-scope companies, locations, processes, users, reports and integrations are documented.
• Out-of-scope items are documented to prevent assumptions.
• Success measures have a baseline, target, owner and measurement date.
• Decision, issue, risk and change-control processes are agreed.
• Business subject-matter experts have protected project time.
• Acceptance criteria exist for each major workstream.
• Dependencies on vendors, banks, regulators and other projects are tracked.
• The target go-live window avoids unacceptable financial or operational periods.

Useful outcome measures may include order-processing time, stock accuracy, days to close, manual journal volume, invoice handling time or report preparation effort. Avoid objectives such as "implement the new ERP" because they describe delivery rather than value.

2. Process and solution design

Business Central should be configured around agreed future processes rather than undocumented habits in the old system.

• Current pain points and future-state process decisions are recorded.
• Standard Business Central capability has been demonstrated before extensions are approved.
• The chart of accounts and financial dimensions support required reporting.
• Posting groups, number series, tax setup and accounting periods are designed.
• Customer, supplier, item, pricing and approval rules are agreed.
• Inventory, warehousing, projects, manufacturing or service processes are designed where applicable.
• Exceptions, reversals, credits, returns and error recovery are included.
• Each extension has a business owner, requirement and acceptance criteria.
• Regulatory, privacy, audit and records-retention requirements are mapped.
• Solution decisions and configuration are documented for support.

A standard-first approach does not mean accepting a poor fit. It means understanding the standard process and the long-term maintenance consequence before adding custom behaviour.

3. Data migration readiness

Data is a business workstream. Technical extraction and loading cannot determine which customer is active, which item description is correct or whether an opening balance is approved.

Data scope

• Each data object has a named business owner.
• Master data, open transactions, balances and historical data are classified separately.
• The required history period is approved for operational, legal, audit and reporting needs.
• Data that will remain in an archive has an access, security and retention plan.
• Source systems and extraction owners are confirmed.

Data quality and transformation

• Duplicate, inactive and obsolete records have documented treatment rules.
• Required fields, formats, codes, units and dimensions are defined.
• Transformation and defaulting rules are approved by data owners.
• Sensitive data is handled appropriately in test environments.
• Record counts and financial control totals are defined before extraction.

Migration rehearsal and reconciliation

• Representative migration rehearsals are planned before final cutover.
• Migration duration is measured using realistic data volumes.
• Errors are logged, corrected at the appropriate source and retested.
• Master data samples are reviewed by business owners.
• Customer, supplier, bank, inventory and general-ledger balances are reconciled.
• Open documents are tested through their next processing step.
• Formal data sign-off criteria and approvers are named.

Microsoft's go-live readiness guidance recommends testing data migration multiple times and testing the solution with migrated data. This reveals mapping and process issues before the final cutover window.

4. Integrations, reporting and security

An integration is not complete when a successful message has passed once. It also needs security, monitoring, error handling and operational ownership.

• Every inbound and outbound interface appears in an integration register.
• Data ownership, direction, frequency and expected volume are defined.
• Authentication, service accounts, secrets and certificate renewal are controlled.
• Timeouts, duplicates, partial failures and reprocessing are tested.
• Monitoring alerts have an owner and response procedure.
• End-to-end tests cover the systems before and after Business Central.
• Bank, payroll, ecommerce, CRM, warehouse, EDI and reporting dependencies are included where applicable.
• Required statutory, financial and operational reports are reconciled.
• Roles follow least privilege and segregation-of-duties requirements.
• Joiner, mover and leaver procedures include Business Central access.
• Production support access and emergency access are approved and auditable.

5. Testing and acceptance

Testing should prove that complete business outcomes work with realistic data, users, permissions and connected systems.

Test planning

• Unit, system, integration, migration, security and user acceptance testing are distinguished.
• Test cases trace back to requirements and acceptance criteria.
• Named business users own user acceptance results.
• Test data includes normal, high-value, unusual and error scenarios.
• Entry and exit criteria are agreed for each test cycle.

End-to-end scenarios

• Order-to-cash is tested from customer setup through receipt and reporting.
• Procure-to-pay is tested from supplier setup through payment and reporting.
• Inventory movements, counts, adjustments and valuation are tested.
• Month-end activities and reconciliations are tested.
• Returns, credits, cancellations and corrections are tested.
• Relevant project, manufacturing or service scenarios are tested.
• Interfaces and reports are included in the same scenario, not tested in isolation.

Defects and sign-off

• Defect severity, owner, target date and retest evidence are recorded.
• Any defects accepted for go-live have a documented workaround and accountable business owner.
• Performance is acceptable for expected volumes and peak tasks.
• UAT sign-off is based on agreed criteria rather than the calendar date.
• Regression tests cover areas affected by late changes.

6. Training and organisational readiness

Training should prepare users to complete their role, handle common exceptions and get help. A feature tour is rarely enough.

• Each user is mapped to a role and required process.
• Training uses realistic scenarios and terminology.
• Super users receive deeper configuration and troubleshooting knowledge.
• Users practise corrections, exceptions and approval paths.
• Quick-reference guides and process instructions have owners.
• Attendance, completion and confidence are tracked.
• Managers understand productivity impacts during transition.
• New policies, responsibilities and controls are communicated.
• Support channels and escalation routes are visible before go-live.
• Business continuity procedures cover temporary system or integration unavailability.

7. Cutover and go-live checklist

The cutover plan should be detailed enough for another informed team member to follow. Include timings, dependencies, validation, owners and decision points. Microsoft's cutover guidance provides a useful framework for planning, rehearsing and verifying the transition.

Cutover preparation

• A minute-by-minute or task-level runbook is approved for the final migration window.
• The transaction freeze and communication plan are agreed.
• Final backup and recovery steps are documented and tested.
• Production environment, licences, users and permissions are ready.
• Final configuration and deployable components are version-controlled or documented.
• Integration endpoints, schedules and credentials are prepared.
• Final migration scripts have been rehearsed with measured timings.
• Reconciliation reports and approvers are available during cutover.
• A rollback or contingency decision is defined for critical failure.

Go/no-go decision

• Scope and acceptance criteria have been reviewed.
• UAT, migration, security and integration sign-offs are complete.
• Critical defects are closed and remaining risks are formally accepted.
• Users, super users and support teams are ready.
• External providers and dependent systems confirm readiness.
• Data migration and validation can complete within the available window.
• The sponsor, business owners and technical leads attend the decision.
• The decision and conditions are recorded.

Production validation

• Users can sign in with the correct roles.
• Opening balances and control totals reconcile.
• Critical sales, purchasing, inventory and financial transactions complete.
• Integrations exchange and process production data correctly.
• Required reports show expected results.
• Monitoring, alerts, backups and support queues are active.
• The business receives a clear go-live communication.

8. Hypercare and optimisation

Go-live is the start of operational ownership, not the end of the project.

• Hypercare hours, contacts, severity levels and response expectations are agreed.
• Daily triage separates defects, training questions, data issues and enhancement requests.
• Critical reconciliations are repeated through the first close or reporting cycle.
• Integration and job queue failures are actively monitored.
• Workarounds have owners and expiry dates.
• User adoption and process performance are measured against the baseline.
• Deferred scope is prioritised through governance rather than informal requests.
• Support documentation and system ownership are handed over.
• A post-implementation review captures lessons and approved optimisation actions.
• Legacy systems are retired only after archive, access and retention requirements are accepted.

Business Central readiness scorecard

Use this summary at a stage gate. Record each workstream as green, amber or red. A red critical area should trigger an explicit decision rather than being hidden by an overall percentage.

• Scope and governance: approved scope, owners, measures and decision logs.
• Solution design: signed designs and accepted extension decisions.
• Data: rehearsal results and reconciled control totals.
• Integrations: end-to-end results and monitoring ownership.
• Security: approved roles, access and operational controls.
• Testing: UAT sign-off and accepted defect position.
• Training: role coverage, completion and support readiness.
• Cutover: rehearsed runbook and approved go/no-go criteria.
• Support: hypercare and long-term ownership confirmed.

Frequently asked questions

What should be included in a Business Central implementation checklist?

It should cover outcomes, scope, governance, solution design, data migration, integrations, security, reports, testing, training, cutover, reconciliation, support and optimisation. Each item needs an owner and evidence.

How many data migration rehearsals are needed?

There is no universal number. Run enough rehearsals to prove mapping, data quality, timing, reconciliation and error handling with realistic volumes. Microsoft recommends testing migration multiple times and testing with migrated data.

Who should sign off user acceptance testing?

Named business process owners should sign off against agreed acceptance criteria. The project or technical team can coordinate testing but should not accept business outcomes on the users' behalf.

What are the most important go-live criteria?

Critical processes must work end to end; balances must reconcile; integrations, security and support must be ready; users must be trained; and unresolved risks must have accountable acceptance and a workable contingency.

Should open defects block go-live?

Critical defects normally should. Lower-severity defects may be accepted when the business impact, workaround, owner and resolution date are documented. Severity labels should reflect operational risk rather than schedule pressure.

How long should hypercare last?

Set the period according to transaction volume, process criticality and reporting cycles. Exit hypercare when agreed stability, reconciliation and support-readiness criteria are met, not only after a fixed number of days.

Next step

Use the checklist to run a readiness workshop with the sponsor, process owners and technical leads. For product context, see how Dynamics 365 Business Central supports finance and operations. If the review exposes red areas that need structured resolution, contact Dynamic Aspect.

Prepared by Dynamic Aspect. Microsoft guidance checked on 8 October 2026. Adapt this checklist to your project scope, deployment model and acceptance criteria.

‍