Business Central migration checklist: from plan to operation

Most migrations do not go wrong on the weekend itself. They go wrong because someone discovers in March that open entries from C5 (a Danish accounting system) came across as one total balance, or that the NAS job that sent orders to the warehouse was never recreated in BC online.

This is the checklist we use ourselves when we move customers from C5, NAV and on-premises Business Central to BC online. Use it as a starting point, and cross out what does not apply to you.

Phase 1: Assessment and planning

Start two to three months before go-live. Most of the work is finding out what you actually have.

Assessing the current environment

• Which system and which version: C5 2012, NAV 2009, NAV 2018, BC 14 or newer
• A list of all customisations: what is still in use, and what was built for a process that no longer exists
• A list of integrations: webshop, bank, EDI, warehouse system, payroll, and how they run today (files, NAS, web services)
• Database size and how many years of history it holds
• The reports people actually use every month

Cloud readiness assessment

• C/AL customisations have to be rewritten as AL extensions. There is no conversion button that does it for you
• Direct SQL access, .NET components and files on a network folder do not work in BC online
• Microsoft's cloud migration tool requires on-premises BC version 25 or newer. Older versions have to be upgraded or reimplemented
• Licence needs: Essentials or Premium, full users and Team Members

Stakeholder alignment

• One decision-maker on the customer side who can say yes and no
• One super user per area: accounts, sales, warehouse
• What does success mean? Typically: the first VAT settlement and the first month-end close without surprises
• Tell the organisation early when the system closes and what changes for them

Developing the migration strategy

• Full migration with all history, or reimplementation with open entries, balances and master data
• Go-live date: a year-end or a period start makes reconciliation much easier than the middle of a month
• From C5: Microsoft's C5 migration tool moves master data, open entries and general ledger history, but it summarises older postings per account
• What happens to the history that is not moved? It must be retrievable for five years under the Danish bookkeeping law (bogføringsloven)
• A plan B: When do we decide to postpone?

Our experience shows that for every hour spent on thorough planning, you save about three hours in carrying out the migration and troubleshooting.

Phase 2: Pre-migration preparation

One to two months before go-live. This is where most problems are found, or not found.

Technical preparation

• Create the production and sandbox environments in BC online in the right country version
• Rewrite the customisations that need to come along as AL extensions, and drop the rest
• Move integrations to BC's APIs with OAuth. Old SOAP web services and user logins have to go
• Replace NAS jobs with job queue entries
• Set up e-invoicing, payments and Continia apps in the new environment

Data preparation

• Clean up master data before, not after: blocked customers, duplicates, items with no sales in five years
• Reconcile open customer and vendor entries in the old system, so you know what the figures should be
• Decide what is archived rather than moved
• Do at least one full trial migration to a sandbox and reconcile it

User preparation

• If users come from C5, everything is new. If they come from NAV, it is mostly the web client and new pages
• Train on your own data in a sandbox, not on Cronus (Microsoft's demo company)
• The super users are the first line of support in the first week
• Agree who users call after go-live

Test environment

• A copy of production data in a sandbox
• Test scenarios written by the users: from order to invoice, from purchase invoice to payment, month-end close
• Test with the users' real permissions, not as SUPER
• Test every integration with real data: an order from the webshop, a payment file, an OIOUBL invoice (the Danish e-invoicing format)

Phase 3: Carrying out the migration

Typically a weekend. If phase 2 has been done properly, it is mostly an exercise in following the plan.

Final preparation

• Go through the plan with everyone who has a task over the weekend
• Confirm that all open items from the test are closed
• A full backup of the old system
• Users know when the system closes and when the new one opens

Data migration

• Close posting in the old system
• Run the final migration or the last delta run
• Reconcile: balance at the cut-off date, open customer and vendor entries, inventory quantity and inventory value
• Keep the reconciliation. Your auditor will want to see it

Configuration and set-up

• Users and permissions are not carried over. Create them via security groups in Entra ID
• Install your own apps and AppSource apps in the right order
• Switch integrations on and test that the first order gets through
• Set up Universal Print or printing via email. The printer in the basement cannot be seen from the cloud
• Set up document sending, for example Continia Document Output, so invoices go out correctly from day one

Validation and testing

• Post an invoice, a credit memo and a payment
• Check that e-invoices and payment files go through
• Check permissions with an ordinary user
• Go/no-go on Sunday evening with the decision-maker

Phase 4: Post-migration activities

The first four weeks decide whether users trust the system.

Immediate post-migration support

• The consultant is available, preferably in person, for the first days
• One list of errors and questions that everyone can see
• Watch the job queue and the integration logs daily
• Prioritise what stops invoicing and payments over what is merely irritating

System optimisation

• Find slow pages and reports with telemetry in Application Insights
• Clean up job queue entries that run too often
• Review permissions again once users have worked in the system for a couple of weeks
• Document the set-up, so it does not live only in the consultant's head

User adoption and training

• Ask users what takes longer than before, and fix it
• Extra training where it is needed, typically in month-end close and reporting
• Write down the new ways of working
• Close the Excel sheets that live on alongside BC

Long-term planning

• Microsoft updates BC online twice a year, in April and October. Test your apps in a sandbox beforehand
• Keep track of who has access and which licences you pay for
• Make a list of what was parked for "after go-live"
• Look for manual routines that can now be automated

The real gain comes in the months after go-live, when the manual routines disappear. Plan that phase as carefully as the migration itself.

Conclusion

A migration to BC online is mostly a question of preparation: know your customisations and integrations, clean up data before the move, and reconcile everything, both in the test and on the day.

Use the checklist as a starting point. Not every item applies to everyone, but the items that get skipped are usually the ones that come back in the first month-end close.