There is a moment in almost every Microsoft Dynamics 365 Business Central go-live that nobody puts on the project plan. A sound migration plan should preserve legacy ERP data for reporting from the outset.
The migration went well. The first invoices are posting. Users are settling into the new system, and management opens its new dashboards. Then someone asks a very ordinary question:
“How does this month compare with the same month last year?”
The room goes quiet because last year lives somewhere else.
It may be in Dynamics GP, Dynamics NAV, Dynamics SL, QuickBooks or another ERP system that was switched to read-only after the migration. Only a few people may still have access. In other cases, the team exported the history to spreadsheets. Some organisations keep an old server alive “just in case.”
A move to Business Central should improve an organisation’s information, not force it to restart its reporting history from zero. With the right approach, historical ERP data can remain available for analysis without recreating the old system inside Business Central.
Why legacy ERP data still matters
Legacy data is the historical business information accumulated before the move to Business Central. It includes transactions, balances and operational history that are no longer being created in the old system but still provide essential context for today’s results.
Many migration projects bring across opening balances and active master records while archiving everything else. That may be sufficient for day-to-day processing, but it creates an artificial boundary in reporting. Trend charts begin on the go-live date, established customers appear new, and historical questions become manual exercises involving exports from multiple systems.
The important distinction is this:
Choosing to preserve legacy ERP data for analysis does not mean reproducing the old ERP inside Business Central.
You do not necessarily need to post every old transaction into the new operational ledgers. The objective is to retain the history that supports business decisions and make it available alongside current Business Central data.
Without that continuity, common reporting problems appear quickly
- Year-over-year comparisons stop working. During the first year after go-live, dashboards cannot show whether current performance is normal compared with the same period last year.
- Seasonality becomes harder to see. Recent transactions alone cannot reveal recurring peaks, quiet periods or long-term purchasing patterns.
- Customer and vendor histories become fragmented. A ten-year relationship can suddenly look only a few months old.
- Historical questions require manual work. Users combine exports from the legacy ERP and Business Central in Excel whenever management asks for a multi-year view.
- Confidence in reporting can fall. When familiar comparisons are unavailable, departments often rebuild their own spreadsheets and maintain competing versions of history.
Which historical data is worth preserving?
Trying to retain every field simply because it exists increases cost and complexity. Start with the information people genuinely use to make decisions. For many organisations, four areas provide most of the analytical value.
Sales history
Historical sales transactions provide context for customers, products, revenue and margins. They allow teams to analyse customer growth, product performance and year-over-year trends from the first day of the new reporting environment.
Purchasing history
Longer-term purchasing data reveals supplier trends, price changes, spending patterns and dependencies. This supports vendor reviews, purchasing decisions and negotiations.
Inventory history
Historical inventory movements give current stock positions context. They can show turnover, seasonal demand, product activity and whether today’s inventory level is normal or exceptional.
Financial history
Historical finance data keeps comparative profit-and-loss and balance-sheet reporting meaningful. Management can continue evaluating current results against previous years rather than waiting for a new reporting timeline to accumulate.
Master data connects the old and new worlds
Transactions are useful only when they can be grouped and filtered consistently. Customers, vendors, items, salespeople, locations, G/L accounts and dimensions therefore matter too.
A customer may have one code in Dynamics GP and another in Business Central. The chart of accounts may have been redesigned, and dimensions may have been consolidated. The structures do not have to be identical, but mappings must be understood. Otherwise, an organisation can import thousands of transactions and still struggle to produce a trustworthy report.
How to preserve legacy ERP data reliably
Whether you use a purpose-built connector or another analytical architecture, several principles separate a useful historical reporting solution from a simple data dump.
Begin with reporting questions and select the right grain
Start by identifying what users need to analyse. Sales history might require transaction-level detail by customer, item, posting date, quantity, sales amount and cost. Finance may require G/L account, date, amount and dimensions. Preserve the fields that answer real questions rather than every technical column in the legacy database.
Set a clear cut-off date
Define the point at which legacy activity ends and Business Central activity begins. For example, the old ERP may contain transactions through 31 December, with Business Central taking over on 1 January. A clear boundary prevents gaps and duplication.
Map master data early
Do not leave customer, vendor, item and account mappings until the end. Historical transactions become valuable when users can analyse them with the business attributes and reporting structures they use today.
Validate signs and totals
Credit memos, negative adjustments and outbound inventory movements must carry the correct sign. A dashboard can look polished while still being wrong. Reconcile imported totals with trusted legacy reports and have someone who understands the business review the results.
Protect current balances
The migration team may already have moved opening balances to Business Central. Historical analytical transactions must not then inflate inventory or financial balances through double counting. The design should preserve historical movement while keeping the current position correct.
Keep legacy records identifiable
The ideal user experience normally combines historical and current records, but users should still be able to isolate either source when required. A simple legacy-data indicator makes validation, reconciliation and focused analysis much easier.
Power BI removes the ERP boundary from reporting
Historically, answering a multi-year question often meant signing in to the old ERP, running a report, exporting it, running the equivalent Business Central report and joining the results manually.
That is not really analytics. It is data archaeology.
Microsoft describes Power BI as an option for creating interactive dashboards and analysing Business Central information across reports and dimensions. Its also positions Power BI among the available reporting approaches.
The reporting layer does not have to inherit the same boundary as the ERP migration. A sales chart might show 2022 through 2024 from a legacy system and 2025 onward from Business Central. The user should be able to select a customer, product or date range and analyse the trend without caring which ERP originally created each transaction.
That creates a much simpler experience:
- Finance compares revenue and margin across several years.
- Sales analyses customer growth before and after the migration.
- Purchasing reviews long-term vendor spend and price movement.
- Inventory examines product activity across multiple seasons.
When users can answer those questions in the Power BI reports they already use, legacy data stops being an archive and becomes a business asset.
A practical route with Business Central Insights
Business Central Insights helps organisations preserve legacy ERP data for Sales, Purchasing, Inventory and Finance reporting through the Insights Connector.
The process uses dedicated legacy tables rather than posting each historical transaction into the standard operational ledgers. The process appends approved records to the relevant fact tables inside the Power BI model, where they can appear alongside current Business Central information.
1. Prepare the historical data in Excel
Standard Business Central Configuration Packages provide the import structure. Export the appropriate package to Excel, populate it with legacy transactions and import the completed file into Business Central.
2. Validate master data and transaction signs
Teams can check imported records against customers, vendors, items, salespeople, locations, G/L accounts and dimensions. Validation also helps identify required fields and incorrect signs before the history reaches reporting.
3. Define the cut-off, review and approve
A cut-off date establishes the last day covered by the legacy system. Imported records remain available for review, and Power BI includes only approved legacy data.
4. Protect inventory and finance balances
Inventory and finance history requires the ending balance to return to zero so the appended analytical transactions do not increase the current balance. The Generate Closing Entries function can create the corresponding closing entries automatically.
5. Refresh Power BI
After approval, the refresh appends legacy records to the appropriate Power BI fact tables. Users can analyse them in applicable reports and include or exclude them with date filters or the Legacy Data yes/no filter.
The complete documents the configuration-package templates, validation rules, approval process and Power BI refresh steps.
A Dynamics GP example
Consider an organisation moving from Dynamics GP to Business Central with ten years of transaction history. Posting every detail into the live Business Central ledgers may be unnecessary, but leaving all that context behind is not the only alternative.
The organisation can select the GP transactions needed for analysis, map them to the current reporting structure and load them into dedicated analytical tables. After validation and approval, Power BI can present the historical GP transactions alongside current Business Central data.
Microsoft’s own cloud migration tooling also recognises the value of GP history. Its documentation for describes options for historical snapshots that can be used in Power BI and other reporting tools.
The technical routes are different, but the business principle is the same: changing ERP systems does not have to mean abandoning analytical history.
Your ERP can change without resetting your business history
A Business Central migration prepares an organisation for the future, but understanding the future often depends on seeing the past.
Historical sales show how customer relationships and product demand have changed. Purchasing history reveals movement in suppliers, quantities and costs. Inventory history gives today’s stock position context. Financial history keeps year-over-year reporting meaningful.
Plan to preserve legacy ERP data as part of the migration. Then the question “How does this month compare with last year?” can have an answer from day one, not after twelve months of accumulating new transactions, not after someone builds another spreadsheet, and not after users sign back into the old ERP.
to see how historical Sales, Purchasing, Inventory and Finance data can be prepared, validated, approved and analysed alongside current Business Central information in Power BI.