Every GP migration guide covers the same ground: data conversion, chart of accounts mapping, integrations, user training, go-live checklists. What none of them mention is that your entire reporting layer disappears in the move. Migrating GP reporting tools to Business Central is the part of the project that gets discovered, not planned for, and by the time finance realizes what happened, they're already live.
Where the Reporting Layer Goes
FRx is gone. It has been for years, but GP shops kept it alive because it worked. Management Reporter picked up some of that responsibility, and for teams that invested in it, the muscle memory runs deep: row sets, column sets, building trees, generating report groups, scheduling output. That entire framework does not migrate to Business Central.
The data moves. The transactions move. The chart of accounts gets mapped. But the reports that finance built and maintained over years, the ones that drive the close, that go to the board, that satisfy auditors, those stay behind. Nobody packs them in a box and carries them over because there is no box. The tooling that produced them does not exist in BC.
What Business Central Offers in Their Place
BC has a native financial report writer. It can produce a balance sheet. It can produce an income statement. It handles row definitions and column definitions with a structure that looks, at first glance, like it might serve the same purpose.
It does not. The report writer feels like a tool that was built for a different era and placed into the cloud without rethinking what finance teams need from it. Layouts are rigid. Formatting control is minimal. Dimensional reporting beyond two global dimensions requires workarounds that become maintenance problems. Building the kind of multi-column, multi-period, departmental rollup reports that a controller produces every month is either painful or impossible, depending on the complexity involved.
Account schedules (now called financial reports in newer versions) serve basic compliance output. They do not serve the operational reporting, the variance analysis, the board packages, or the management reports that finance runs on every month.
Why Migrating GP Reporting Tools Deserves Its Own Workstream
If you are a consulting firm guiding clients through GP to Business Central migrations, this is the conversation worth having before go-live, not after. The moment a controller sits down in their new system and tries to produce their standard month-end package, they will discover the gap themselves. That discovery is never pleasant. It arrives as a support ticket or an urgent call, and it lands in the middle of a close.
The better approach is to scope reporting as a workstream in the migration project. Inventory the reports the finance team depends on. Identify which ones BC's native tools can handle (there will be a few) and which ones need a different solution (there will be many). Build the reporting layer alongside the transactional migration so that day one in BC includes reports that work, not a promise that someone will figure it out later.
Rebuilding the Reporting Layer in Excel
The reason FRx lasted as long as it did is that it gave finance control over report layout, formatting, and structure without requiring developer involvement. Finance teams built what they needed, maintained it themselves, and trusted the output. That's the standard any replacement has to meet.
Velixo takes a different approach than BC's native tools. Instead of replacing the report writer with another report writer, it turns Excel into a live reporting interface connected directly to Business Central. Finance teams build reports in Excel using functions that pull real-time data from BC. Rows, columns, dimensions, periods, entities: all controlled through familiar Excel structures. The layout is whatever Excel can produce, which means there is no layout limitation.
For teams migrating from GP, the reporting workflow they're used to, where finance owns the report, controls the structure, and produces the output without waiting on IT, transfers directly. The underlying system changed from GP to BC. The way finance works with its reports does not have to.
Writeback adds a capability that FRx never had. Budgets, journals, and forecasts built in Excel can be pushed back into BC from the same workbook. The reporting layer becomes bidirectional, which means the Excel workbook that produces your month-end package is also the workbook that posts your recurring journal entries and updates your forecast.
Migrating GP Reporting Tools After Go-Live
If your team is already live on BC, or close to it, and reporting has not been addressed, catalog the reports your finance team produces every month. Separate the ones that drive decisions from the ones that satisfy compliance. Then figure out which tool lets finance rebuild them without starting over.
The reports that matter most are usually the ones with the most complexity: multi-department P&Ls with rollups, board packages that combine financial and operational data, variance reports that compare actuals against budget at the cost center level. These are the reports that BC's native tools struggle with and the ones that FRx or Management Reporter handled well in the GP world. They should be the first ones rebuilt in the new environment.
Partners managing a migration timeline should treat reporting readiness the same way they treat data conversion readiness. If the data validation checklist has fifty items on it, the reporting checklist should have at least ten. Which reports need to be functional on day one? Which can wait until month two? Who owns the rebuild? If those questions don't have answers before go-live, finance will be the team that feels the migration went wrong, even if every transaction migrated perfectly.
The data is already moving to BC, but will your reports be ready when it gets there?
Velixo connects to Business Central in hours, not weeks. If you want to see what your GP reports look like rebuilt in Excel with live BC data, .
