If you run Microsoft Dynamics GP, you already know the date. , and most of the content aimed at you right now says the same thing: start planning your move to Dynamics 365 Business Central.
That advice is not wrong. But it skips over the question most GP customers are actually asking this year, which is closer to: What can we do in the next six months that improves the business and doesn't commit us to a full ERP project we're not ready to fund?
Power BI is one of the few answers that holds up. It solves a reporting problem leadership is complaining about today, and — done properly — it builds an asset that survives the migration instead of being thrown away with the old system.
Here is how to approach it.
1. Start Where Finance Is Already Frustrated
Most GP shops have a mature reporting stack: SmartLists for lookups, Management Reporter for financials, a folder of SSRS reports someone built years ago, and a monthly cycle that ends in Excel. It works. It is also slow, backward-looking, and impossible to explore without going back to the person who built the report.
Start with receivables and cash. It is the fastest place to show value because the questions are concrete and the answers are already in GP:
- Total outstanding receivables and aging by customer
- Days sales outstanding and how it is trending
- Invoices past terms, ranked by exposure rather than alphabetically
- Payment behavior by customer over time, not just current balance
- Collections priorities for this week
Finance leaders do not need a data warehouse to get this. They need the aging refreshed daily instead of at month-end, and the ability to click into a customer without opening a ticket.
Once that dashboard is live, extend the same approach by role rather than by module. A CFO wants margin, cash, and budget-versus-actual. A sales leader wants revenue by customer and product. Operations wants purchasing, inventory turns, and fulfillment. Each of those is a different view of GP data, and none of those users should have to learn GP navigation to get it.
That is the underrated part: Power BI extends GP information to people who will never have a GP license.
2. Bring in the Systems GP Was Never Going to Cover
ERP-only reporting has a ceiling, and every GP customer hits it in the same place. The financial truth lives in GP. The pipeline lives in a CRM. Operational detail lives in a spreadsheet or an industry-specific application. Nobody can answer a cross-functional question without three exports and a VLOOKUP.
Power BI is where those sources come back together. Forecast versus actual revenue. Quoted margin versus realized margin. Service delivery cost against what was invoiced. Inventory positions against open sales orders.
This is also the point where the reporting conversation stops being an accounting project and becomes a business one — which matters when you eventually need budget approval for the larger ERP decision.
3. Build the Data Foundation, Not Just the Dashboard
This is where most GP and Power BI projects quietly go wrong.
The tempting shortcut is to point Power BI at the GP company database, expose the tables, and let users figure it out. GP's schema does not reward that. A few realities to design around:
Open and historical tables are separate. Receivables, sales, and general ledger transactions each live in different tables depending on status and year. Report only against open tables and you understate history. Union them carelessly and you double-count. Every reliable GP model handles this deliberately.
Multiple companies mean multiple databases. Most GP customers are running more than one company database, and consolidated reporting means aligning account frameworks and segments across them. That mapping is a business decision, not a technical one, and it needs to be made explicitly rather than inferred by whoever builds the dataset.
Fiscal calendars are not calendar years. GP period setup has to be reflected in the date dimension, or every month-over-month comparison in the model is subtly wrong.
Definitions need owners. What counts as revenue. What makes a customer active. How margin is calculated. Which balance is "outstanding." If two departments answer those differently, you will ship two dashboards that disagree, and the project loses credibility in a single meeting.
Getting these decisions written down is the actual deliverable. The visuals are the easy part.
4. Use Reporting to De-Risk the Business Central Decision
Here is the strategic argument for doing this now rather than after a migration.
In a typical ERP project, reporting is treated as something to rebuild once the new system is live. That means the requirements conversation happens at the worst possible moment — when the team is exhausted, the budget is spent, and users are comparing the new system unfavorably to reports they had for years.
Building your analytics layer while you are still on GP inverts that sequence. By the time you evaluate Business Central, you already have:
- A documented, agreed set of KPIs and business definitions
- Clarity on which GP data leadership actually uses, and which reports nobody has opened in two years
- A reporting experience that is decoupled from the ERP, so users keep their dashboards through the transition
- A defensible answer to the historical data question — because GP history that does not migrate cleanly can still live in your analytics platform
That last point deserves emphasis. "What happens to twenty years of GP history?" is one of the most common objections that stalls these projects. An analytics layer built before the migration is a legitimate answer to it.
You also end up scoping Business Central against real business requirements instead of a wish list assembled under deadline pressure.
What This Sets Up for AI
Every ERP vendor is now selling Copilot and AI agents, and most SMB leaders are being asked by their board what the plan is.
The unglamorous truth is that AI applied to business data is only as good as the business context underneath it. A model that does not know how your organization defines revenue, margin, or an active customer will produce confident answers that your controller will spend a week disproving.
The KPI definitions, the cleaned-up entities, and the semantic model you build for are exactly that context. You do not need an AI strategy to justify the work. But if you do this properly, you will have done most of the preparation without calling it an AI project.
The Practical Middle Path
The choice is not between staying on GP and starting a migration tomorrow.
GP can keep running the transactions it has run reliably for years. Power BI can solve the visibility problem this quarter. The data foundation you build in between makes the eventual Business Central decision cheaper, better-informed, and far less disruptive.
The mistake is treating ERP, reporting, data, and AI as four separate initiatives with four separate business cases. They are one arc. A GP and Power BI project is simply the first step that pays for itself before the next one starts.
About the author
DStrategyTech is a Michigan-based Microsoft partner helping SMBs turn data, business applications, and AI into measurable business value across the Microsoft ecosystem — spanning Data & AI, Dynamics 365, Power Platform, and Cyber Security.
For organizations running Dynamics GP, we offer a fixed-scope : a short engagement that documents your KPI definitions, evaluates your GP data structure, delivers a working Power BI starting point, and produces a clear recommendation on what should happen before any Business Central decision.
Visit to start the conversation.