If you’re planning a move to Dynamics 365 Business Central, there’s a good chance someone has already suggested hiring a Business Analyst to run the internal side of it. That’s usually a sound instinct. A Business Central migration is mostly about processes, data and people. The technical work matters, but it’s rarely where projects go wrong.
The job description is often vague, though. “Support the ERP migration” can mean almost anything. This article covers what we think a Business Analyst on a Business Central migration should own, where they need a partner’s help, and the questions to settle before anyone touches the data.
Why migrations end up on the analyst’s desk
A migration forces decisions that nobody in the business has had to make for years. Why do we post freight that way? Who approves credit limits? Which of these 40 custom reports does anyone still open?
The person who answers those questions needs to understand both the old system and the way the business actually runs. Finance knows its corner, operations knows its corner, and IT knows the servers. The Business Analyst is the one who connects them, and that connecting work is what keeps a migration from turning into a copy-paste of old problems into a new system.
At a 120-person UK distributor, the internal analyst noticed during a process walkthrough that returns were being credited by a warehouse supervisor outside the system. Nobody had listed it as a process. We added a returns approval step in standard Business Central before build began. It cost a day of configuration and avoided a gap in stock and credit notes at go-live.
Settle these questions before you move any data
Before data mapping starts, the analyst should get clear answers to a few foundational questions. Each one shapes the scope and the timeline.
What are you migrating from? The path differs a lot by source system.
- Dynamics NAV: this is usually an upgrade. The work depends heavily on the version and how much custom code is in the database.
- Dynamics GP: Microsoft provides cloud migration tooling, but it covers a defined set of data. You still need decisions about what it doesn’t cover.
- Non-Microsoft systems (Sage, QuickBooks, older or homegrown ERPs): this is a data migration and a reimplementation, not an upgrade.
Cloud or on-premises? For most organisations we work with, the answer is Business Central online. That choice has consequences. Customisations have to be built as extensions rather than direct code changes, and some older approaches to integration and reporting don’t carry over.
How much history do you need? This is the question that most often derails timelines. “Everything” is rarely the right answer. Common options include:
- Opening balances plus open documents only
- A defined number of years of summarised history
- Full detail kept in an archive or the old system in read-only mode
The analyst should drive this conversation with finance and audit early, so it doesn’t get settled in a hurry during cutover.
Processes first, data second
It’s tempting to start with data because it feels concrete. We’d argue the order should be reversed.
For each core process (order-to-cash, procure-to-pay, inventory, month-end close, and so on), the analyst should document three things:
- How the process works today, including the workarounds.
- How standard Business Central handles it.
- The gap, and whether that gap really needs closing.
That last point is where the analyst earns their salary. A lot of customisation in older ERP systems exists because of a requirement from years ago that no longer applies. Every gap you close with standard functionality is one fewer extension to build, test and maintain through Business Central’s regular update cycle.
A UK food distributor had a customised NAV report that built a weekly customer statement with a manual export to Excel. During review, the analyst found that standard Business Central statements and the customer ledger layout already covered the content. They dropped the customisation and adjusted the report layout with a small amount of Word layout work. It saved a development task and one more object to test at each update.
Data migration: where the detail lives
Once the processes are agreed, data work becomes much more straightforward. The analyst typically owns or coordinates:
- Data mapping: which fields in the old system go where in Business Central, and which go nowhere. This includes setup data like posting groups, dimensions, payment terms and number series, which shape everything that comes after.
- Cleansing: duplicate customers, inactive vendors, items with no movement in years, inconsistent units of measure. Fix these in the source or during transformation. Don’t migrate them and promise to clean up later, because that cleanup rarely happens.
- Chart of accounts and dimensions: a migration is a good moment to rationalise these. Doing it later is far harder.
- Trial loads: plan for more than one. Each trial load surfaces issues the previous one didn’t.
- Reconciliation: agree upfront how you’ll prove the migrated balances are right. Trial balance, aged receivables, aged payables and inventory valuation should tie out between old and new, and someone in finance should sign off.
Business Central has its own tools for importing data, including configuration packages and the GP migration tooling. Your partner will choose the method. The analyst’s job is to make sure the business decisions behind the data are made and documented.
The things people forget
On the projects we’ve seen, the issues that surface late are rarely the ledgers. More often they’re the following:
- Reports and Excel workbooks that people rely on but nobody listed. Ask each team what they open every week and every month-end.
- Integrations with e-commerce, warehouse systems, banks, payroll, EDI and CRM. Each needs an owner, a new connection method and a test plan.
- Third-party add-ons in the old system. Check whether there’s a Business Central equivalent on AppSource, whether standard functionality now covers it, or whether you need something custom.
- Approvals and permissions. Rebuilding these properly takes time, and they’re often left until the week before go-live.
- Documents and layouts such as invoices, statements, remittances and picking lists. Customers and suppliers notice these.
On one migration for a 60-person UK engineering firm, we nearly missed that the old system held open purchase orders with part-received lines. Our first load only brought across fully open orders. It surfaced in a cut-over rehearsal, when the warehouse could not receive a delivery against an order. We changed the migration to carry the received quantity across. Then we added a check on partial receipts to the rehearsal checklist for every project.
Cutover and the first month
The analyst should own the cutover plan alongside the partner. That plan covers the freeze date for the old system, the final data load sequence, reconciliation sign-offs, and a clear go/no-go decision with named owners.
After go-live, expect the first month-end close in Business Central to take longer than usual. Plan for it, staff for it, and have the analyst available to triage questions. Separating “this is a training issue” from “this is a configuration issue” quickly makes a big difference to how the first few weeks feel.
A practical checklist for your Business Central migration
Use this as a starting point. Adjust it to your source system and scope.
- Source system and version confirmed; migration path agreed with your partner
- Cloud vs on-premises decision made and its implications understood
- Data history scope agreed with finance and audit, in writing
- Core processes documented as-is, with Business Central fit/gap noted for each
- Every existing customisation reviewed: keep, replace with standard, or drop
- Chart of accounts and dimensions reviewed and rationalised
- Master data cleansing owners assigned (customers, vendors, items)
- Field-level data mapping documented and signed off
- At least two trial data loads planned, with reconciliation for each
- Full inventory of reports, workbooks and document layouts
- Integration list with owners, new connection approach and test plan
- Third-party add-ons assessed for Business Central equivalents
- Permission sets and approval workflows designed and tested
- User acceptance testing scripted around real end-to-end scenarios
- Training plan by role, timed close to go-live
- Cutover plan with freeze date, load sequence and go/no-go criteria
- Support plan for the first month-end close
Where a partner fits alongside your analyst
A good internal Business Analyst and a good implementation partner complement each other. Your analyst knows the business: its history, its politics and its real processes. A partner brings knowledge of Business Central’s standard functionality, the migration tooling, and the patterns that tend to cause trouble.
What we’d suggest avoiding is either side trying to do the other’s job. A partner can’t decide how much history your auditors need. An analyst new to Business Central shouldn’t have to work out the extension model from scratch under deadline.
Talk to us
If you’re planning a Business Central migration, from NAV, GP or another system, and want a second opinion on scope, data approach or how to structure the roles, we’re happy to talk it through. There’s no obligation and no sales script, just a practical conversation about where you are and what comes next.
Get in touch with Vizor Solutions at vizorsol.com.