How to get your data out of Dynamics GP before support ends
Dynamics GP data sits in SQL Server databases: a system database that holds the company list and user security, and one or more company databases that hold each company's general ledger, masters, open items and history. A complete copy is therefore a database-level extraction combined with a reconciled set of files, with no single export button that captures everything. Finance and IT leaders who must leave GP before the support window closes need that copy in hand early, because mapping, test loads and the parallel month end all depend on it. Start by confirming which databases belong to the live environment, since older test or retired company databases often sit beside production.
This page covers five steps: scoping which companies and databases are in play, extracting masters, open transactions and history, verifying each extract against GP reports, keeping a read-only archive for audits, and planning contract timing. Before work starts, confirm the export paths your organization can use for your exact GP version and licensing terms, with Microsoft or your GP partner. The BACPAC export that Microsoft documents for Business Central online is a different product and path, so do not assume it applies to an on-premises GP installation. Put the confirmed paths in writing as part of the scope.
Build an inventory before any extraction runs. For each company database, record the earliest and latest posting dates, approximate counts of open receivables, payables and inventory transactions, custom objects, and third-party add-on tables, along with the business owner who will sign off the balances. Ask who sets the retention period for the archive and what auditors will need to see, such as trial balances by period. Then confirm the date your support and any export rights end, and work backward from it. Illustrative example: if a company has several years of history in one database and a separate test copy, the inventory shows which one the archive must reflect.
What you can export from Dynamics GP and the formats the target accepts
This table pairs each Dynamics GP data type with a likely extraction route and the input limits of the destination. The format and limit columns describe what Odoo and ERPNext accept on import, not what GP can export, so confirm the GP side against Microsoft documentation and your own GP version before you plan the extract.
| Data type | Extraction method to confirm | Target format and import limits |
|---|---|---|
| Customers | Read from the company database or export through a standard GP report, confirmed for your GP version | Odoo: Excel (.xlsx) or CSV with External IDs. ERPNext: CSV or Excel template, a few thousand records per batch |
| Vendors | Read from the company database or export through a standard GP report, confirmed for your GP version | Odoo: Excel (.xlsx) or CSV with External IDs. ERPNext: CSV or Excel template, a few thousand records per batch |
| Items | Read from the company database or export through a standard GP report, confirmed for your GP version | Odoo: Excel (.xlsx) or CSV with External IDs. ERPNext: CSV or Excel template, a few thousand records per batch |
| Chart of accounts and segments | Read account and segment tables from the company database, then confirm the mapping with your finance team | Odoo: CSV or Excel with External IDs for accounts and analytic plans. ERPNext: CSV or Excel, with dimensions loaded separately |
| Open receivables and payables | Read open document tables from the company database at a fixed cutoff date | Odoo: CSV or Excel with External IDs. ERPNext: CSV or Excel, child table rows supported for invoice lines |
| Open orders | Read open sales and purchase order tables from the company database at the cutoff | Odoo: CSV or Excel with External IDs. ERPNext: CSV or Excel, child table rows supported for order lines |
| General ledger balances | Read balances at period end from the company database, reconciled to the trial balance in GP | Odoo: opening balance entries via CSV or Excel. ERPNext: CSV or Excel template for journal entries |
| Transaction history | Read posted history from the company database, scoped by years you decide to keep | Odoo and ERPNext: large volumes need batching, so plan history loads in separate files |
What does not export cleanly and how teams work around it
Some Dynamics GP data sits outside the standard records you export first. The items below often need a separate path: a query, a rebuild or a retained copy. For each one, confirm the approach with your GP partner and with the target vendor before you set a cutover date.
Third-party add-on tables
Add-ons from independent software vendors keep their data in their own SQL Server tables, and custom fields added to standard windows may sit in separate tables. A standard export of built-in records can miss both. Identify these tables in the SQL Server catalog, extract them with queries or a scheduled export, and map each one to a custom field or child table in the target. Confirm with your GP partner which tables belong to each add-on and whether its vendor provides a supported export.
Customized reports and forms
Reports and forms you customized are layouts over the data, so they do not move with the tables. Export the definitions you still have, and keep a sample output of each one for reference. Then rebuild the reports the business still needs in the target, starting with month-end, tax and statutory outputs. Keep PDF copies of the final closing reports from GP. Confirm with your partner which reporting tools your customizations used and whether their definitions can be exported.
Users and security roles
Users, passwords and security roles define who could see and post what. Plan to recreate credentials in the target rather than rely on any export of them. Export user-to-role and role-to-task assignments as reference, then design roles in the target around segregation of duties. Confirm with your GP partner or Microsoft how GP stores passwords and what any export includes before anyone depends on it.
Workflow and approval history
Approval routes and the record of who approved what sit in workflow tables that many migrations skip. Their value is evidence: proof that an approval was in force when a transaction posted. Extract approval history for open items and for the last closed periods into a read-only archive. Then configure approval rules in the target as new settings, documented as a change. Confirm with your GP partner which workflow features you used and where their history is stored in the company database.
Attached documents
Scanned invoices, contracts and notes attached to records may be stored inside the database or on file shares. Auditors often ask for these first, because they prove the underlying transaction. Inventory attachments by record type and count, extract the files with their record keys, and index them in a document store the target can link to. Confirm with your GP partner where attachment data lives and whether links between files and records survive a database copy.
Audit and change logs
Audit and change logs record who changed a master record or a posted transaction, and when. They are the evidence most often requested in an audit of a migration. Keep the source SQL Server databases in a restorable, read-only backup for the retention period your auditors set, and export the logs you need as CSV files for the archive. Confirm with your GP partner which change tracking is enabled in your environment, since it depends on configuration, and with your auditors how long the archive must stay readable.
What sits in the company and system databases
A complete Dynamics GP export depends on knowing that the data lives in two kinds of database. Each company has its own company database, which holds the chart of accounts, customer, vendor and item masters, open and posted transactions, and history. The system database holds company setup, user records, security and shared settings. Both matter. Company data without its setup loses the meaning of its company IDs, fiscal periods and posting options, and without the security tables you cannot reconstruct who was allowed to see or approve what. Treat the two as one export scope, and record which database each table group came from.
Multi-company sites carry the most common gap. Every company is a separate database, so a site with several legal entities has several databases to inventory, and each one needs its own extraction and its own row counts. Start from the company list in the system database, then confirm each company's database exists and is reachable. Include inactive or historical companies that no longer post but still hold records that auditors may ask for. A missing company discovered after cutover is expensive to recover, so reconcile the company list against the databases on the server before you write any extraction plan.
Extraction should start from a list of table groups, not from the screens your users work in. Screens and standard reports apply filters, date ranges and site selections, so they show what people see rather than everything stored. Build the inventory by group: masters, open transactions, posted history, setup, security and any third-party add-on tables. Then confirm the exact table inventory for your GP version and installed add-ons with your partner and Microsoft's documentation. Microsoft's own migration tool can help you scope what it carries over, but it is not a complete export of your data, so use its coverage as a checklist for your inventory, not as the extraction itself.
The sequence for a complete export and verification
This sequence turns a loose extract into a verified data set that finance has signed off, so each later migration step rests on counts and balances you have already checked. Each step ends with a named check that must pass before you move on.
Inventory every company and system database
Your GP administrator lists every company database, the shared system database, and each third-party add-on that writes its own tables or reports. Record the SQL Server version, the database sizes, the company IDs in use, and which modules each company actually posts to. Include scheduled reports, saved queries, and any custom stored procedures that someone downstream depends on. The step is done when the finance owner confirms the list is complete, because anything missing here will surface as a gap at cutover. Ask the add-on vendors which tables they own, since those are easy to miss in a standard GP schema walk.
Set a cutoff date and freeze activity
Agree a cutoff date with the finance owner and decide how posting is controlled during extraction. Options include closing the period to new entries, restricting user logins, or logging all activity made after the cutoff for later catch-up. Document who may post after the cutoff and how any exceptions are approved. The output is a signed cutoff memo that names the date, the freeze method, and the owner. Without this, the extract and the live system drift apart and every later reconciliation becomes harder to explain.
Extract masters and map them to target templates
Export customers, vendors, items, the chart of accounts, and the GP account segments from the company databases to flat files. Map each GP field to the matching column in the target's import template, for example in Odoo's Excel or CSV import or ERPNext's Data Import templates. Assign a stable external identifier to every master record so later loads can be matched and re-run without duplicates. The check is a row count per master type in the extract that equals the count in GP for the same cutoff, with unmapped source fields listed and approved.
Extract open transactions, balances and history
Pull open invoices, open purchase orders, open receivables and payables, inventory on hand, and the trial balance as of the cutoff. Then extract historical transactions only at the depth the target needs, which is usually summarized periods for reporting and full detail for open items. Keep the source queries and their run dates in version control so the extraction can be repeated. The check is that open receivables and payables total to the GP aging report and that the trial balance debits equal credits in every company.
Load into a test copy in small batches
Load the masters first, then open balances, then transactional history, into a test instance of the target system. ERPNext's documentation advises importing only a few thousand records at a time, so split each file into batches of that size or smaller and record the result of every batch. Run the load on a dedicated test environment, not production. The check is a load log per batch showing records created, updated, and rejected, with every rejection explained and either fixed in the source or accepted by the owner.
Reconcile counts and totals at each load
After each batch, compare the target's record counts, open item totals, and trial balance by account against the GP figures at the same cutoff. Keep a reconciliation sheet with one line per check, the GP value, the target value, and the difference. Investigate any difference before the next load, because later loads built on an unexplained gap make root cause analysis far harder. The step is complete when every line shows zero difference or a documented, approved reason.
Sign off with the finance owner before cutover
Present the reconciliation sheet, the load logs, the cutoff memo, and the list of accepted exceptions to the finance owner. Ask for written sign-off on the trial balance, open receivables, open payables, and inventory values in the test copy. Archive the signed pack alongside a read-only export of the GP databases so auditors can trace the migrated figures back to source. Cutover should not proceed until this sign-off exists, and the archive is the evidence you will need later.
How much history to export and where the read-only archive lives
This approach carries across open receivables and payables, open purchase and sales documents, item and customer balances, and the opening general ledger balance for each account at the cutover date. It keeps the target small and the import short, and it suits sites where prior periods are already closed and reported. The trade-off is that history for drill-down, year-over-year comparisons and some tax or audit queries stays only in GP, so you must decide early where those questions will be answered.
- Import volume: Open items and balances are a small fraction of total transactions, which keeps the target database lean and the reconciliation manageable.
- Opening balances: You need a trial balance at the cutover date that ties to GP to the cent, by account and by dimension.
- Reporting gaps: Prior-year comparatives will not exist in the new system unless you load them separately.
- Open documents: Partially applied payments, unposted batches and open purchase orders need explicit rules for whether they move or close in GP first.
- Audit trail: Without an archive, the link from a new opening balance back to the GP transaction detail depends on your extract files.
Confirm with your external auditor whether they accept an opening balance as the starting point for the new system's audit period, and whether any open items must be evidenced with GP source documents.
This approach loads transactional history for a defined number of prior fiscal years into the new system, so users can report and trace activity without leaving it. The number of years is a policy decision driven by audit retention, reporting needs and what the target can import cleanly. Loading more history raises import time, validation effort and the amount of data your support team must maintain, and it can add noise to the new system's reports.
- Driver of scope: Start from your retention policy and the questions auditors and tax reviewers ask, not from what the tool can physically import.
- Import method: Large history loads are usually split by period and by object type. The ERPNext Data Import tool recommends importing only a few thousand records at a time, so plan batches and reconciliation per batch.
- Mapping history: Historical GP account segments must map to the target's accounts or dimensions, including retired accounts, and every mapping decision must be recorded.
- Validation: Each loaded period should reconcile to GP trial balances, and you should keep the reconciliation reports as evidence.
- Performance: Heavy history can slow reporting in the first months, so test the target at production volume before cutover.
Confirm with your auditors which fiscal years must be traceable in the new system and whether summarized history is acceptable for any of them.
This approach keeps the full GP company and system databases as a retained, read-only copy, separate from the production target. It preserves every transaction, audit trail and configuration detail regardless of how much history you migrate, and it gives auditors a fixed source for questions the new system cannot answer. The archive itself must be secured, backed up and kept accessible for as long as your policy requires, which makes it a recurring cost and an ongoing access-control responsibility.
- What to keep: Retain the company databases and the system database, plus the GP version and the SQL Server version needed to open them, since restoring to an unsupported platform is a real risk.
- Access: Limit read access to named roles, log queries and remove the ability to post or change data.
- Format options: A restorable database backup, a set of flat extracts with a data dictionary, or both. Flat extracts are easier to query later but lose GP logic.
- Storage and backup: The archive needs its own backup, encryption and location decisions, and its cost recurs for the whole retention period.
- Decommissioning: Plan the exit date for GP licences and servers only after the archive is tested by a restore.
Confirm with your auditors and your retention policy in writing which format is acceptable, who may access the archive, and how long it must remain restorable.
What to plan before the Dynamics GP contract or support ends
Extraction goes wrong most often before anyone runs a query: unclear license rights, unverified backups and cutover dates that collide with month-end. The cards below cover the decisions to settle first, and each one should be confirmed with your Microsoft partner or licensing contact before the data work begins.
Confirm support and patch dates
Check the end of support and end of security patch dates for the exact Dynamics GP version and service pack you run against Microsoft's current published lifecycle, not an older plan or a partner summary. The answer sets how long you can keep GP running while extraction, testing and parallel close take place. Record the dates in writing and tie the project plan to them, including any gap between support end and the date your cutover is expected to finish.
Confirm post-termination data rights
Read the license terms that govern your GP and any add-on products to find out whether you may keep using the software, or hold a copy of the data, after the subscription or maintenance agreement ends. Ask specifically whether a read-only copy of the company databases is permitted for audit and retention purposes, and whether third-party add-on vendors impose separate restrictions. Get the answer from your licensing contact in writing before you decommission anything.
Secure a tested full backup
Take a full backup of every company database and the system database that holds GP setup, security and company registration records, then restore it to a separate server to prove it is usable. A backup that has never been restored is not a control you can rely on. Store copies outside the production SQL Server, record the SQL Server version used, and keep the backup set until the archive has been verified.
Set the freeze calendar
Build a calendar that places the transaction freeze, final extraction, test loads and parallel run around your month-end and year-end close, rather than the reverse. Name a cutoff date for posting, a window for open-item reconciliation and a rollback point for each stage. Agree with the controller which periods will be closed in GP and which will be reopened in the new system, because a freeze that lands mid-close is the most common reason for late reconciliation work.
Decide who holds the archive
Name the owner of the read-only archive, the storage location and the people allowed to query it, and document how an auditor or internal reviewer requests access. Decide whether the archive lives in your own data center or in a cloud account you control, how it is encrypted and how long it is retained. Confirm the retention period with your legal and audit teams, since the period is set by your obligations and not by the software.
Agree acceptance criteria with finance
Before the first extraction, write down with the finance team what counts as a complete and correct migration: trial balance agreement by period, matching open receivables and payables totals, item and customer counts, and the reconciliation of each extract back to the GP source. Assign a named approver for each criterion. These criteria give the extraction work a finish line and give auditors evidence of what was accepted and by whom.
What do teams ask before they export Dynamics GP data?
How much effort does a complete Dynamics GP data export take?
The effort depends mainly on how much data sits in scope and how clean it is. A complete export covers the company databases for every legal entity, the shared system database, any add-on tables from third-party products, and the history you choose to keep. Each extra company multiplies the mapping and reconciliation work, because account segments, customer and vendor numbers and item codes often differ between entities. Add-ons add tables you must identify and document before extraction. Deep history and duplicate or inactive master records increase the cleaning effort. Ask your partner to inventory each database and add-on before estimating anything.
Can our own team run the Dynamics GP export internally?
Often yes, if the team has the right mix of skills. The extraction side needs someone comfortable with SQL Server, including reading table relationships in the company and system databases and writing queries that respect GP's transaction and batch structures. Someone with deep GP knowledge must confirm which tables hold open items, posted history and master data, and which fields carry meaning. Finance must sign off on every balance, cutoff and reconciliation. A partner is useful when the internal team lacks SQL Server depth, when add-ons are heavily used, or when the team cannot spare people during close.
How long does the export work take, and what sets the timeline?
The timeline is set by the scope decisions, not by the extraction queries themselves. The main drivers are the number of companies, the number of add-on products with their own data, how much history you keep, the state of your master data, and how many reconciliation rounds finance needs before signing off. Your timeline also depends on whether you run the export during a parallel period or only at cutover. Ask any partner for a schedule tied to named milestones in a written scope, and check which assumptions about your data and staffing the schedule relies on.
What does the business need to provide for the export?
The business must make decisions that technical teams cannot make alone. Finance needs to choose the cutoff date for open receivables, payables and inventory, and decide how much posted history to carry forward. Each area, such as sales, purchasing and inventory, needs a named owner who confirms master data such as customers, vendors and items. Someone must own reconciliation of each extract to GP trial balances and subledgers, and agree tolerances for differences. Without these owners and decisions, the export produces files that nobody accepts.
Do we need an outside audit review of the read-only archive?
Preparing evidence and undergoing an auditor's assessment are different activities. A partner can help document the archive, including extraction scripts, data dictionaries, reconciliation records, access controls and retention settings, so your team can show how the data was produced and protected. Only an independent auditor can assess your controls and issue an opinion, and certification bodies issue certifications. Confirm with your external auditor, before the archive is designed, which evidence they expect, which retention rules apply, and whether they want to review the process in advance.
How do we protect the archive once GP is switched off?
Treat the archive as a regulated record. Store it in a self-hosted database or file store with restricted administrative access, encrypted backups, logged reads and a documented retention period set by your legal and compliance teams. Keep the extraction scripts and reconciliation reports with the data so an auditor can trace each figure back to its source. Test restores periodically, because an archive that cannot be read later is not useful. Confirm the retention and access requirements with your compliance lead before choosing storage.
What should we ask a partner for in a written quote?
Ask for a fixed scope that lists each source database, each add-on, each company, the history depth, and the target format for every extract. The quote should name the deliverables, such as extraction scripts, staging files, reconciliation reports, a data dictionary and an archive, along with acceptance criteria for each one. It should state what the client must provide, including named reconciliation owners, access to SQL Server, and finance time. Ask how change requests are priced and how the partner handles data that fails validation. DeployOpen agrees scope, deliverables and timelines in writing before work starts.
How DeployOpen scopes and delivers a Dynamics GP data exit
DeployOpen is a Chainscore Labs company that plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Dynamics GP data exit, we start with a written scope that defines which company and system databases, masters, open transactions and history are extracted, and we deliver the extraction, validation and archive in your environment.
How we scope
- Inventory which company and system SQL Server databases hold the data you need to extract
- Agree in writing which masters, open transactions and history years are in scope
- Define the read-only archive format, retention needs and the audit evidence you expect
- Confirm the target platform and who in your team signs off each extract
How we build
- Write repeatable extraction queries or scripts against the GP databases in your environment
- Produce staging files shaped for the target platform's import templates
- Reconcile record counts and control totals between GP source and each extract
- Test imports on non-production copies before any run is treated as final
How we hand over
- Deliver extraction scripts, mapping tables and reconciliation reports as documentation
- Provide a read-only archive of extracted data with an index of what it contains
- Record the steps, owners and open items so your team can repeat or audit the exit
- Walk your finance and IT staff through the evidence before the source system is retired
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- Re-run extracts for later cutover dates or late corrections under the agreed scope
- Support the archive through audit requests, with auditors and certification bodies making their own determinations
- Confirm retainer terms and response expectations in the written agreement
