Treat historical data access as a core business requirement, not an optional technical step.
Key takeaways
Classify data into master data, open balances and historical data to simplify migration.
Store GP history in a scalable cloud repository like Azure Data Lake for fast access.
Microsoft Dynamics GP has served as a reliable enterprise resource planning (ERP) system for many years. Now, as organizations prepare for a future in which GP is no longer the primary system, the central challenge becomes preserving continuity. Finance and operations teams still need quick, dependable access to historical transactions, audit trails and familiar reporting views once the new ERP is in place. Without that access, routine tasks such as reconciliations, audits and customer inquiries become slower and more difficult.
Most modern ERP projects focus their data migration efforts on what's needed for day-to-day operations—core master records and current-state data such as customers, vendors, items, the chart of accounts, open accounts receivable and payable (AR/AP), and current-year general ledger (GL) balances. Detailed applied history and legacy transactional structures are often excluded because converting them is complex and costly and introduces risk. This creates a practical gap between what the new ERP contains and what business teams need for audits, customer service, collections, sales conversations and operational analysis. Closing that gap requires a structured plan for historical data access—not just a technical export.
A successful transition treats historical access as a core business requirement rather than an optional technical exercise. The first step is to clearly distinguish the data that must be converted into the new ERP from the data that should remain available for inquiry and reporting. From there, the organization can deliver that history in a format users can reach quickly, without overloading the new system or forcing people back into a retired GP environment. This approach keeps the new ERP streamlined while still meeting practical needs for investigations, reconciliations and long-term analysis.
Structuring ERP data migration and historical data access
A practical way to organize the migration effort is to classify data into three groups: master data, open balances and historical data. Master data—customers, vendors, items and the chart of accounts—must be migrated because it underpins daily processing and supports consistent reporting. Open balances—starting GL balances, unpaid receivables and payables, and unfulfilled orders—must also move because they define the operational starting point in the new platform. Historical data plays a different role: Users need to search, filter, export and reconcile it, but they rarely need to edit it inside the new ERP. Treating historical data as "inquiry-first" reduces conversion complexity, shortens implementation timelines and prevents the new ERP from absorbing years of legacy detail that can degrade performance and complicate security, data retention and compliance.
Once those categories are clear, the next decision is where historical data should reside so that it stays easily accessible without requiring preservation in a full GP environment.
Some organizations maintain a SQL Server instance and connect reporting tools directly to it; others move SQL into the cloud. Increasingly, companies are shifting historical data into a data lake architecture to support scalable storage, broader analytics scenarios and simpler integration with modern reporting platforms. Azure Data Lake is a common option, and similar patterns work well in other cloud and analytics ecosystems. The right fit balances your governance framework—security, retention, auditability and cost management—with the ability to retrieve records quickly and consistently when needed.
With historical data stored in a suitable location, attention can turn to everyday access. Teams that have used GP often prefer the familiar SmartList-style experience: ad hoc queries, the ability to choose and rearrange columns, grouping and subtotaling, and flexible filters without arbitrary limits. Modern query and list tools can replicate and even extend that experience across multiple systems, not just the legacy database. Users can run real-time queries against underlying sources, save personalized views as favorites, share those views with colleagues and export the query results directly to Excel.
More advanced options—refreshable Excel connections, API access for Power BI and embedded views inside the new ERP—reduce friction by bringing historical insight into the tools and screens where users already work, instead of sending them back to a separate GP interface.
Unified reporting with GP history and new ERP data
In a post-GP environment, one of the most valuable capabilities is the ability to combine legacy history with current activity in the new ERP. Rather than treating GP as a disconnected archive that sits off to the side, organizations can build unified views that merge historical and new-system transactions while clearly labeling the source. This supports continuous reporting across the cutover date for sales, purchasing, payables, receivables and inventory—without resorting to manual spreadsheet stitching. It also preserves the expected drill-down behavior, in which summary results link back to related detail (such as header-to-line relationships), giving teams a complete view for reconciliation, customer questions, vendor disputes and audit support. When designed thoughtfully, this model protects institutional knowledge and reporting continuity while keeping the new ERP focused on the data it genuinely needs for ongoing operations.
A practical, repeatable approach is to extract GP history into a cloud data store and expose it through configurable lists that behave like an enhanced, cross-system version of SmartList or SmartList Builder. Historical data becomes reusable list views that support filtering, sorting, adding columns, exporting and role-based security. "Merge views" can then blend GP history with real-time transactions from the new ERP to provide a life-to-date perspective without manual reconciliation steps. Confidence in the results comes from transparent controls that prevent double counting, typically relying on date-based cutovers or transaction-level rules that define what belongs to GP versus the new platform.
The business value grows further when historical data is embedded directly into the screens people use every day. Instead of running stand-alone reports, teams can open a tailored list from a customer record, vendor record or other operational page, where the system automatically passes the relevant identifier (such as a customer ID) and returns only matching transactions. This speeds up searches, improves accuracy and supports better decisions in the flow of work: Collections teams can review payment and invoice patterns, customer service agents can verify prior orders, and finance can validate trends without switching systems. Because the embedded view can be configured to show GP-only history, new-ERP-only activity or a merged set, the experience can be optimized by role and process rather than locked into a single reporting model for everyone.
This architecture also supports flexibility in ERP selection and integration with a broader application ecosystem. Whether the organization adopts Business Central, NetSuite, Sage Intacct or another ERP platform, the same pattern applies: Connect to new ERP data, connect to legacy GP history, and deliver consistent list-based experiences that feel native inside the host application. Many organizations also need financial and operational visibility inside customer relationship management (CRM) and other daily-use systems. Embedding sales transaction history in Salesforce, Dynamics 365 Sales or HubSpot enhances pipeline reviews and account management by giving sales teams immediate insight into purchasing behavior without requiring ERP licenses or extensive training. The same approach can extend to connected platforms such as Shopify, Stripe and other operational tools, providing cross-functional visibility without relying on brittle, one-off integrations.
A GP transition is fundamentally a business continuity project: Keep operations running smoothly, keep reporting coherent and keep historical answers available on demand. Begin by sorting the data into two groups: master data and open balances that must be migrated and historical data that must remain accessible. Then pair that strategy with a scalable storage solution and an embedded reporting experience that spans both legacy and new systems. With the right governance and cost model—role-based security across applications, a subscription-based reporting platform, and targeted one-time services to assess the GP footprint and implement connectors and views—organizations can extract history into a cloud repository such as Azure Data Lake and retire on-premises GP servers.
The outcome is a cleaner, better-controlled ERP implementation, stronger oversight of legacy information and solid continuity for teams—without the operational, financial and security burden of keeping old systems online.
Accessing GP data after migration
View RSM's on-demand webinar "Life after GP: Where does your data go next?" to hear RSM and eOne Solutions discuss options for keeping historical Dynamics GP data accessible, learn how Popdock supports ERP migrations and explore practical next steps for your transition.
Related insights
Contact our Microsoft professionals
Complete this form and an RSM representative will be in touch shortly.
