This is Part 1 of a three-part series on getting more out of your Business Central data before, during, and after go-live
Part 1 — Why Reporting Belongs in Phase 1 (you’re here)
Part 2 — Native Reporting vs. a Third-Party Tool
Part 3 — Fixing Reporting After Go-Live
Reporting comes up at three points in a Business Central project: when you’re scoping the build, when you’re deciding how you’ll actually produce reports on the platform, and when you’re already live, and the gaps are showing. This series takes them in order. Part 1 is for the first group teams still planning the implementation, where reporting is both the easiest thing to plan for and the easiest to leave until it’s too late.
Your legacy report library RDLC, Crystal, SSRS, Jet, Management Reporter, custom, etc. does not migrate to Business Central, so it’s best to decide how you will report in BC during requirements planning and implementation, not after go-live. And if you’re new to the Microsoft ERP ecosystem, it’s worth understanding the limitations of native reporting as you scope your project, so you can make the best decision about how to move forward early in the process.
Every Business Central kickoff runs a similar agenda. Requirements gathering, data migration, customizations, the ISVs you depend on, integration points, training, the cutover weekend, and the go-live date everyone is working toward. Reporting sometimes makes the list but is often earmarked for a subsequent phase of the implementation, treated as something you can look at or optimize later.
Here is why that’s a problem.
A migration plan is good at accounting for what lives in the system, and financial and operational reporting often does not. Ask how the business actually gets its numbers today, and you find three layers. There are the formal reports everyone knows about. There are the custom ones a partner built years ago, still running, rarely documented. And underneath both is the manual layer: the exports, the spreadsheets, the copy-and-paste consolidations that quietly carry half the reporting load and appear in no plan because they live on people's desktops, not in the ERP.
Because most of that is invisible at kickoff, reporting reads like a finishing touch you add once the real system is running. It isn't. The technical work of the migration barely registers with finance. What finance will notice is the first month-end after go-live, when a report they have run for years isn't there, and nothing was scoped to replace it.
That gap shows up in what finance leaders worry about. In a December 2024 Gartner survey of 250 CFOs and finance leaders, enterprise data quality was named a top enterprise-performance challenge for the year ahead, ranking ahead of both AI strategy and regulatory change. A migration that moves the transactions but leaves reporting for later feeds exactly that problem, and it is how finance ends up making decisions on numbers it doesn't fully trust.
This happens across industries, and getting ahead of it is exactly where Western Computer comes in. After nearly four decades of moving distributors and manufacturers onto Business Central, Western has seen the reporting gap surface the same way several times, and encourages customers to consider reporting in Phase 1, getting what you need in scope and finding it before go-live rather than after. As Shane Stader, Account Manager at Western Computer, puts it:
“Legacy systems accumulate years of custom reports the business relies on without realizing how embedded they are. When reporting is pushed to Phase 2, teams often don't discover what they're missing until they're live and already making decisions in the dark. Doing a proper discovery of those reporting needs up front, and deciding whether a tool like Cosmos can replace them, saves you from rebuilding trust in the data after go-live instead of before it.”
— Shane Stader, Account Manager, Western Computer
Every business has reports they need, but most businesses don’t have the full picture of what those are. If you don’t plan your reporting strategy as part of your move to Business Central, critical data and business insights will be left behind. This will have an immediate impact on change management and trust in the new ERP rollout.
Here is what you might not be thinking about. Your transactional data migrates. Your reporting does not. A migration moves data from the customers, vendors, open balances, and years-of-posted-transactions tables. The reports built on top of those tables are a separate question, and what happens to them depends entirely on how they were built.
Custom RDL and RDLC reports are the heaviest case because, for many NAV shops, they are the largest report library the company owns and have been built up over the years. They were written against the old system's objects, and they do not simply move. To exist in Business Central Cloud, they have to be redeveloped as AL extensions, which is development work, not a migration step.
Management Reporter is the hardest case. For GP finance teams, it has been the backbone of financial reporting, and it is on the way out. Microsoft has stopped developing it, and its future is tied to Dynamics GP, which will lose support at the end of 2029. There is no migration path from Management Reporter into Business Central. While BC's financial reports are intended to be the successor, they are not a one-to-one replacement for the consolidation and distribution GP teams built in MR. Those statements are rebuilt rather than carried forward.
Crystal Reports and SSRS reports built on legacy structures do not port either. And if you run on-premise Jet Reports, expect to update reports whenever table and field structures change during the migration, since they point to a data model that has moved underneath them.
Then there is the part nobody puts in a migration plan. Much of what a business calls “reporting” is not in any tool at all. It is exports, manual consolidations, copy-and-paste, and one person's macros. None of that migrates either, and because it never appears in the project scope, it is the last thing anyone accounts for and the first thing people miss.
This is the reality of moving from a customizable on-prem system, where reports were built directly against the database over many years, to a modern SaaS platform like Business Central with a different architecture. The reports do not come with you, so decide what replaces them before you go live.
"You can't scope a reporting replacement you haven't discovered yet."
— Shane Stader, Account Manager, Western Computer
Knowing the gaps exist is not the same as knowing which ones are yours. The way you find out is by inventorying your reporting during the migration, while there is still time to plan for it, not after go-live, when the gap is already open.
If reporting is going to be a Phase 1 decision, it needs Phase 1 work, and that starts with discovery. Western Computer builds it into the front of a migration: “We push for a formal discovery of reporting requirements in Phase 1, so the replacement is scoped against the actual complexity of what's being replaced, not just what looks good on paper," says Stader.
Work through this during implementation planning, with finance and operations in the room, not just IT, because they know which reports they need most, and how they are currently compiled.
Strip away the specifics, and it's the same story. Migrating? The custom reports built up over the years don't come with you; Management Reporter and legacy solutions have no successor in Business Central, and the spreadsheets that carry half the load were never part of the plan. Already live? Those gaps are already here, patched over with exports and workbooks that multiply every quarter. Native Business Central was built for a single company to report on its own transactions. The day you need consolidation across entities, self-service in Excel, or reports that survive close, you're past what it was built to do.
With a third-party reporting tool like Cosmos, finance and operations can build its own reports without a ticket, deliver a single set of numbers the whole business trusts, automatically consolidate entities, and run a close that doesn't stall. That's what a reporting layer is for, and it's what Cosmos was built to do: connecting Business Central to Excel and Power BI, shipping with the reports you need on day one, and running on its own cloud so that heavy reports never drag the system down.
Western Computer has spent nearly four decades helping distributors and manufacturers migrate to Business Central and can help you identify gaps and build a plan for a better future in Business Central reporting.
Talk to Western Computer about a Cosmos demo.
Yes. Reporting is one of the most commonly deferred parts of a migration and one of the most regretted. Because legacy report libraries do not migrate and native reporting has real limits, deciding how you will report before go-live saves you from rebuilding confidence in your numbers after the fact.
Management Reporter does not migrate, and there is no direct equivalent in Business Central. Financial statements are either rebuilt from financial reports or recreated in a dedicated reporting layer. Since Management Reporter is no longer developed and rides GP's lifecycle, plan the replacement before go-live rather than after.
Not directly. Business Central Cloud uses its own report objects and layouts within AL extensions, so reports built in Crystal or standalone SSRS do not carry over and must be rebuilt to run on the platform. Planning for that rebuild, or replacing those reports with a reporting layer, belongs in your migration scope.