NAV to BC reporting
Free checklist4 min read

NAV → Business Central: The Reporting Migration Checklist

Most NAV-to-BC projects budget carefully for the data and treat reporting as an afterthought. Then month-end arrives and the numbers finance relied on are not there. Use this before you migrate.

What’s inside

  • How to inventory the reports finance actually closes on
  • What moves to BC on its own and what quietly does not
  • A rebuild / retire / improve decision for every report
  • How to sequence reporting with the migration, not after it

Most NAV-to-Business Central projects budget carefully for the data and treat reporting as an afterthought. The data migrates on a well-trodden path. The reports do not. Then the first month-end in BC arrives and the numbers finance relied on for years are missing, because BC's reporting stack is different and "we'll rebuild those later" quietly became "later." Drawing on 14+ years working in BC and NAV, here is the checklist to run before you migrate.

Step 1 — Inventory what you actually run

You cannot rebuild what you never listed. Start with the reports, not the tables.

  • List every NAV report finance and operations run monthly, quarterly, and at year-end.
  • Mark the ones a close cannot happen without. Those are your non-negotiables.
  • Note who owns each report today and how long it takes to produce.

Step 2 — Separate what moves from what does not

Not every report is equal. Some have a direct BC equivalent, some have to be rebuilt from scratch.

  • Standard NAV reports usually have a BC counterpart. Confirm the counterpart answers the same question, not just a similar one.
  • Custom or modified NAV reports (custom RDLC layouts, custom objects, C/AL tweaks) do not carry forward. Flag every one.
  • Saved views, Jet or Excel layouts, and Account Schedules need to be rebuilt or replaced. List them separately, they are easy to forget.

Step 3 — Decide the fate of each report

Migration is the cheapest moment to stop maintaining reports nobody uses. Give each one a verdict.

  • Rebuild — still essential to the close or to a decision-maker.
  • Retire — nobody actually uses it, or it duplicates another view.
  • Improve — the monthly Excel step is the tell that the report was never good enough. Fix it now instead of porting the pain forward.

Step 4 — Sequence reporting with the migration, not after it

The most common failure is treating reports as post-go-live cleanup. By then the team is already closing in a system they cannot report out of.

  • Assign each non-negotiable report a build owner and a deadline before go-live.
  • Plan the first month-end in BC as a dry run, with the rebuilt reports already in place.
  • Keep NAV in read-only access until the BC reports are trusted through a full close.

The one rule

The data migrates, the custom reports do not. Plan them as early as you plan the data, and the first close in BC is a non-event instead of a fire drill.

Working through a NAV move and not sure which reports will survive it? That is exactly the conversation worth having before go-live, not after.

Want a copy to send to your team?

Drop your email and we’ll send this checklist so you have it later. Optional, the whole thing is right here on the page. No spam, unsubscribe in one click.