Migrate from Dynamics GP to ERPNext

Migrate from Dynamics GP to ERPNext: what the move involves

Dynamics GP support ends December 31, 2029, with security patches until April 30, 2031, so a team that has decided to re-implement rather than move to Business Central needs a plan for the data as well as the software. The work is mostly data mapping, validation and cutover, not installation. ERPNext is licensed under GPL-3.0 and can be self-hosted with Docker Compose or the bench command line tool, so the platform itself carries no license fee. What it costs in total depends on hosting, implementation and internal time, and the facts available here do not give a figure for those components. Ask any implementation partner for a written scope that separates each of them.

Finance usually owns the decisions: how GP account segments become accounting dimensions, which open receivables and payables carry over, how much history loads, and who signs off the trial balance. IT owns the environment, the database engine (MariaDB or PostgreSQL), backups, access and the extraction from the GP SQL Server databases. An implementation partner typically carries the mapping spreadsheets, the import runs and the reconciliation scripts. Effort and risk are driven by the number of companies, the volume of open transactions, the amount of custom GP reporting and the number of add-on products that need a replacement. Confirm each of these with your own GP administrator before you agree a timeline.

The practical risk is a trial balance that does not agree after import. Plan for repeated test loads into a non-production site, reconciling each load to GP at the same date before the next one. ERPNext's Data Import tool takes CSV or Excel files with downloadable templates and supports child table rows, but its documentation advises importing only a few thousand records at a time, so large masters and transaction sets need batching and a log of every run. Treat the cutover as a dated event with a frozen GP period, a final extract, a final import and a parallel month end before GP is switched to read-only.

Which Dynamics GP capabilities map cleanly to ERPNext

This table compares core Dynamics GP modules with their closest ERPNext equivalents and marks each as clean, needs rework or gap. Use it as a starting point for your own module inventory, since coverage depends on which GP modules, add-ons and reports your company actually runs. The main takeaway is that finance and distribution core usually need the least rework, while add-on products and SQL Server reports need an explicit decision before cutover.

Dynamics GP capability	ERPNext equivalent	Status
General ledger and account segments	Accounting with chart of accounts and accounting dimensions	Clean for standard accounts, needs rework for segment mapping
Accounts payable	Buying and accounts payable with supplier invoices and payments	Needs rework for open items and payment history
Accounts receivable	Selling and accounts receivable with customer invoices and payment entries	Needs rework for open invoices, aging and deposits
Inventory	Stock management with warehouses, batches and serial numbers	Needs rework for item setup, costing method and opening stock
Purchasing	Purchase orders, receipts and purchase invoices	Clean for standard flows, confirm approval rules against your GP setup
Sales order processing	Sales orders, delivery notes and sales invoices	Clean for standard flows, confirm pricing and discount logic
Reporting from SQL Server reports and Report Writer	Standard ERPNext reports and custom reports	Gap, requires a decision on rebuild, export or archive
Customization and GP add-on ISV products	Custom apps, server scripts and third-party apps where available	Gap, requires a decision per add-on; confirm availability with each vendor

Which GP data moves, through which export paths

A GP move is really three jobs: pulling data out of the GP SQL Server databases, shaping it into import files, and rebuilding the integrations that sat around GP. The cards below follow that order, with the checks that matter most at each step. Confirm every GP-specific export and table name in your own environment before you rely on it.

Company and system databases

GP splits its data across a company database for each legal entity and a system database for logins, company setup and security. Both sit on SQL Server, so the extraction plan starts with an inventory of which tables hold masters, open transactions and history for each company. Confirm the table list, custom fields and any third-party add-on tables against your own GP instance, because site customizations rarely match a standard template.

Masters: customers, vendors and items

Customers, vendors and items are the first files to build because every open transaction references them. Export each master from SQL Server into CSV or Excel, keeping the GP customer, vendor and item numbers as stable keys. ERPNext's Data Import tool updates existing records and imports them in batches, so plan a clean key scheme before the first load.

Open transactions and history

Open invoices, open purchase orders and unpaid balances need to arrive as documents that ERPNext can post against, while closed history is usually summarized or kept in a read-only archive. Decide the cutoff date and the level of detail before extraction, because history that is loaded as full transactions costs far more to validate. Ask your ERPNext partner how they will reconcile open items to the trial balance.

Child table rows and templates

Documents such as sales invoices and purchase orders have child table rows for line items, and ERPNext's Data Import tool supports importing those child rows. Each line must carry its parent document reference exactly as the template expects. Build one template per document type, test a few hundred rows first, and keep import batches to a few thousand records or fewer, as the documentation advises.

Google Sheets and staging files

The Data Import tool accepts public Google Sheets as well as CSV and Excel files. A public sheet is convenient for a pilot but exposes financial data to anyone with the link, so use it only for non-sensitive sample data. Keep production extracts in files on your own servers, and record who edited each file and when.

Rebuilding logins and server logic

GP users sign in through Windows and SQL Server security, which does not carry over. ERPNext documents LDAP integration and social login keys as options for replacing them, and confirm both against your identity provider. Server Scripts run Python on document events and are disabled by default from version 15, and Frappe Cloud public shared benches do not allow them, so any GP custom logic that depends on them needs a self-hosted deployment or a redesign.

How the migration sequence runs from inventory to decommission

The sequence moves Dynamics GP into ERPNext in controlled stages, so each step ends with evidence that the books agree before the next step starts. Finance signs off on each stage, and the GP environment stays readable until the audit trail is secured.

Inventory companies, segments and add-ons
Finance and IT list every GP company database, the account segment structure, the open and historical transaction types in use, and each third-party add-on or customization that writes to or reads from GP. Owners are named for each item, and the inventory records which masters and reports the business actually uses. The step is complete when the finance lead signs the inventory and every add-on has a stated replacement, retirement or manual process.
Design the account and dimension mapping
The team maps each GP account segment to an ERPNext chart of accounts structure and to accounting dimensions, deciding which GP segments become dimensions and which stay in account codes. Customer, vendor and item masters are mapped to ERPNext fields, with unique identifiers kept so that later imports can update existing records. The output is a signed mapping workbook that accountants can trace line by line back to GP.
Build and test the pilot company
One GP company is extracted from the SQL Server databases and loaded into a non-production ERPNext site, using the Data Import tool with downloadable templates. The ERPNext documentation advises importing only a few thousand records at a time, so large masters and transaction sets are split into batches and logged. The pilot is complete when the imported trial balance matches the GP trial balance at the same date, account by account, and any differences are explained and cleared.
Reconcile subledgers and open items
Open receivables, open payables, inventory quantities and values are loaded and compared with the GP subledger reports for the same cut date. Finance checks that customer and vendor balances, open invoices and item on-hand quantities agree, and that opening balances are posted in a way the auditors can follow. The output is a reconciliation pack per module, with each variance either fixed in the mapping or documented as accepted.
Run a parallel month end in both systems
The team closes one full month in GP and in ERPNext using the same transaction inputs where possible, then compares the trial balance, subledgers and key management reports. Differences are traced to mapping rules, posting logic, rounding or user process gaps, and the mapping is corrected and retested. The parallel run is complete when finance accepts the ERPNext reports as equivalent for the scope agreed in the inventory, and the open issues list is empty or formally accepted.
Cut over on a defined date
The organization fixes a cutover date and freezes GP transaction entry for the affected companies. The final open items and balances are extracted, loaded into production ERPNext in batches, and reconciled to the frozen GP figures before users are allowed to post. The output is a signed cutover checklist showing the final trial balance and open item totals in both systems, with a documented rollback decision point.
Decommission GP with a read-only archive
After the new system has run without reconciling issues, GP is set to read-only and the company and system databases are backed up and stored with their extraction reports, mapping workbook and reconciliation packs. Access is limited to named roles, and the archive is tested for restore before GP is switched off. Retention and access rules should be confirmed with your auditors and legal team. The step closes when the archive is verified and the decommission record is signed.

How GP account segments become ERPNext accounting dimensions

Decide segment by segment what each GP account segment becomes in ERPNext before any data moves. GP builds account numbers from segments, often a company, department, and cost center or project, and those segments rarely line up with an ERPNext chart of accounts. For each segment, the team needs a decision: it becomes part of the account code in the chart of accounts, it becomes an accounting dimension that can be tagged on ledger entries, or it is dropped because nobody reports on it. Write this mapping down as a controlled document signed off by finance, and keep the GP segment definitions and their values beside it so the mapping can be checked later. Confirm with your own finance team which reports depend on each segment today, since a segment that looks unused is often the filter behind a month-end schedule.

Validate mapped trial balances against GP for every period you carry over, not just the closing balance. After the first load, run the GP trial balance and the ERPNext trial balance for the same periods and compare them account by account, with each dimension value reconciled to its GP source. Differences usually come from segments that were collapsed, from accounts that were merged during mapping, or from opening balances posted to the wrong period. Treat any unexplained difference as a blocker for cutover. Also plan for the loss of historical reporting context: once a segment is dropped or folded into an account code, prior-year comparisons by that segment may no longer be possible in ERPNext without a separate archive. Decide early which reports auditors and management will still need, and keep read-only copies of the GP reports for those periods. Ask your implementation partner to show how each of those reports is reproduced, or where it is not.

How the migration differs by company size and GP footprint

A single-company site that uses GP mainly for the general ledger, receivables, payables and bank reconciliation has the narrowest migration scope. The work centers on the chart of accounts, which maps to ERPNext accounts and accounting dimensions, and on a small set of masters: customers, vendors and open transactions. Validation is mostly a question of proving that balances carry over correctly and that the first closed periods in ERPNext reconcile to the last GP period.

Chart of accounts mapping: Map each GP account segment combination to an ERPNext account, and decide whether any segment should become an accounting dimension instead.
Open items: Import open receivables and payables with their due dates and document references so aging reports match GP on cutover day.
Opening balances: Load balances as of a defined cutover date and compare the ERPNext trial balance to the final GP trial balance line by line.
History depth: Decide how much transaction history to load. Many finance-only sites keep history in a read-only archive and load only opening balances.
Parallel close: Run one full month end in both systems before retiring GP.

Confirm with your controller which reports auditors and lenders use each month, since those reports define the validation bar.

Many GP sites depend on third-party add-on products for payroll interfaces, tax, document management, reporting or industry-specific processes. Each add-on has its own data store, its own integration with GP tables, and often its own licensing. A migration to ERPNext does not carry these add-ons over, so each one needs an owner decision: retire it, replace it with a built-in feature, rebuild the logic, or keep it as a separate system that reads exported data. The validation effort grows with the number of processes that depended on add-on behavior.

Add-on inventory: List every add-on, what data it reads and writes, and which user roles depend on it.
Replacement decisions: Mark each add-on as retained, replaced or retired, and record the owner who signed off.
Custom logic: Server Scripts in ERPNext are disabled by default from version 15 and must be enabled with the server_script_enabled setting, so confirm that your hosting setup allows them before planning custom logic.
Integration feeds: Test every feed that moves data into or out of the ledger, such as bank files or payroll journals.
Report parity: Rebuild the reports that add-ons produced and compare them to GP output for a closed period.

Ask each ISV vendor for a written export of its data before you start, since some vendors support extraction only while the license is active.

What drives cost and duration, and how to keep each down

This table lists the main drivers of cost and effort in a Dynamics GP to ERPNext move, why each one changes the bill, and how to reduce it. Read the one-time rows as the migration project and the recurring rows as what you keep paying after cutover. The main takeaway is that the number of companies, segments, open items and validation rounds shapes most of the work, while the software itself carries no license fee when self-hosted.

Driver	Why it changes cost or effort	How to keep it down
Companies and segments	Each legal company needs its own company setup, chart of accounts and dimension design, and every GP segment that maps to a dimension adds mapping work and test cases.	Consolidate unused companies and segments before extraction, and agree the dimension list with finance so only reporting-relevant segments become accounting dimensions.
Open items and history volume	Open receivables, payables, inventory on hand and transaction history all need extraction, transformation and reconciliation. Data Import is recommended for a few thousand records at a time, so large volumes mean more batches.	Load only open items and opening balances at cutover, and keep older history in a read-only archive for audit use rather than importing it.
Add-ons and custom reports	GP add-on ISV products and custom Crystal or SQL reports have no direct ERPNext equivalent, so each one needs a replacement, a rebuild or a retirement decision.	Inventory every add-on and report with its owner and usage, then retire the unused ones before design starts.
Custom logic and Server Scripts	Custom business rules built as Server Scripts need review for the version in use. Since version 15 they are disabled by default and must be enabled, and Frappe Cloud public shared benches do not allow them.	Confirm early whether you need Server Scripts, and if you self-host, decide who owns enabling them and maintaining them.
Users and roles	Each GP security role must be redesigned as ERPNext roles and permissions, and user access must be tested for segregation of duties.	Reduce the role count by grouping tasks, and confirm the user count with the business before licensing or hosting decisions.
Integration count	Each bank feed, tax engine, payroll link, e-commerce or warehouse connection must be rebuilt or re-pointed, and each one adds its own test cycle.	List every integration at the start, mark which ones are required at go-live, and move the rest to a later phase.
Validation rounds	Trial balance, subledger and open item tie-outs repeat with every test load, and parallel month end runs add further rounds.	Fix the mapping rules before each load and agree sign-off criteria in advance so each round tests a narrower set of differences.
Hosting and support (recurring)	Self-hosting ERPNext is free, but you pay for your own infrastructure, backups, monitoring and staff time. Frappe Cloud shared site hosting starts at 5 US dollars per month, per the ERPNext pricing page.	Compare self-hosting with Frappe Cloud using your own staffing and backup requirements, and ask any partner to quote hosting separately from implementation.
Implementation and migration (one-time)	Implementation is delivered through certified partners, and migration effort follows the drivers above, so the quote depends on the written scope.	Ask each provider for a fixed scope covering mapping, extraction, load scripts, validation rounds and cutover support, and request the assumptions behind each estimate.

What usually goes wrong in a GP to ERPNext migration

Most GP to ERPNext migrations fail on data, not software. The risks below cluster around the trial balance, the account mapping, the import process, the custom reports that nobody owns, and the calendar. Each card names one risk and the check that prevents it before cutover.

Trial balances that never reconcile

If the ERPNext trial balance does not match the final GP trial balance by account and period, every later report inherits the gap. Reconcile opening balances per account and per fiscal period, and keep the GP reports from the last closed month as the signed reference. Do not sign off cutover until the difference is zero or each remaining difference has a documented, approved explanation.

Segment mapping errors

GP account segments are often built up over years, and a single mistake in how segments map to ERPNext accounts and accounting dimensions will misstate departmental and project reporting. Write the mapping table before any extract runs, have finance sign off every segment value, and test a sample of transactions end to end. Confirm which dimensions must be mandatory on each document type.

Import batches that fail on child rows

Sales invoices, purchase orders and journal entries carry child table rows, and the Data Import tool can reject a parent when a child line references a missing item, account or tax template. Load masters first, then transactions, and keep batches small because the documentation advises a few thousand records at a time. Keep each failed file and its error log so reruns are repeatable.

Open items that do not tie to the ledger

Open receivables and payables must total the control accounts in the ledger on the cutover date. Differences usually come from unapplied payments, credit memos or invoices dated in a closed period. Extract open items as of one cutoff, compare the subledger totals to the general ledger, and resolve each difference before the first ERPNext transaction is posted.

Custom GP reports with no owner

Many GP sites rely on Report Writer reports, SmartList views and third-party add-on reports that nobody documents. These often disappear silently after cutover, and the gap appears at audit or month end. Inventory every report in use, record who consumes it, and assign each one a replacement in ERPNext or a retirement decision before parallel close begins.

Server Scripts assumed on shared hosting

Logic that moved from GP customizations into ERPNext often depends on Server Scripts. From version 15 they are disabled by default and must be enabled with the server_script_enabled setting, and Frappe Cloud public shared benches do not allow them. Confirm the hosting model before design starts, and if you need them, plan for a self-hosted bench where you control that setting.

Questions buyers ask before moving Dynamics GP to ERPNext

What does a Dynamics GP to ERPNext migration cost, and what drives the price?

The cost is driven by the work, not by a license fee, because self-hosting ERPNext is free according to the ERPNext pricing page. Your spend falls into four components: the infrastructure you run (servers, database, backups, and any Frappe Cloud hosting you choose, which starts at 5 US dollars per month for shared site hosting according to the same pricing page), the implementation and data migration work, the internal time your finance and IT staff spend, and ongoing support or upgrades. Scope decides most of the variance: the number of company databases, the volume of open transactions, how many GP add-on products must be replaced, and how many custom reports exist. Ask any provider for a fixed-scope quote with deliverables and timelines written out, and ask for each component to be priced separately so you can see what recurs.

How long does a GP to ERPNext migration take?

The schedule depends on scope and on how much of the work your team can staff, and no duration figure is supplied for this migration. The main drivers are the number of GP companies and modules in use, how clean your customer, vendor and item masters are before extraction, how many open receivables and payables must be carried over, whether you need a parallel month end before cutover, and how many custom reports or integrations must be rebuilt. Plan the work in phases: extraction and mapping, test loads, reconciliation of trial balances, and a live cutover. Ask your implementation partner to tie each phase to a written milestone, and confirm with them how long the validation cycles will take in your environment.

What does the finance and IT team need to supply during the migration?

Expect the finance team to own the business decisions and the IT team to own the data and environment. Finance must approve the mapping of GP account segments to ERPNext accounting dimensions, sign off on the chart of accounts, confirm opening balances, and reconcile trial balances at each test load. IT must provide the server environment, database access for extraction from the GP SQL Server databases, user and access design, backup arrangements and a secure location for the archive. Both teams should name a single decision owner for master data, because duplicate customers and vendors are the most common source of rework when records are imported with the Data Import tool.

Can our own team migrate from Dynamics GP to ERPNext without a partner?

Yes, a capable internal team can run the migration, since ERPNext is open source, can be installed with Docker Compose or the bench command line tool, and its Data Import tool accepts CSV or Excel files with downloadable templates. The practical question is capacity and experience, not licensing. Your team will need skills in SQL Server extraction, data cleansing, accounting setup and Linux or container operations, and it will need to run reconciliation without a second set of eyes. A partner is most useful for fixed-scope work such as extraction scripts, dimension design, validation and production hardening. Ask any partner to state in writing which parts they will deliver and which parts remain with your staff.

Do we have to move Dynamics GP history into ERPNext?

No, history is a scope decision, and most teams load only what they need for operations and reporting. Many keep opening balances and open transactions in ERPNext and move older history into a read-only archive extracted from the GP databases, which also helps with audit requests. If you do load history, remember that the Data Import tool is designed to import a few thousand records at a time, so large transaction volumes take many batches and extra validation. Confirm with your auditors and tax advisers which periods they need in the new system and which they will accept from an archive, and write that decision into the scope before extraction begins.

How do ERPNext versions and support affect the migration plan?

Pick a supported version before you build the target system, because the version determines how long you get security and maintenance. According to Frappe's supported versions page, version 15 is planned to be supported until the end of 2027 and version 16 until the end of 2029, while version 14 reached end of life on January 31, 2026. Frappe's policy also says that to receive warranty coverage from Frappe you must be on a listed version and subscribed to a matching Frappe Cloud support plan. Confirm with Frappe which plan matches your version and whether your implementation partner will apply upgrades, so that the migration does not start on a release that will expire during your go-live period.

How DeployOpen works on this

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so an ERPNext migration from Dynamics GP runs on your servers or cloud account. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory the GP company databases, the system database and the add-ons and reports your finance team depends on.
Agree in writing which masters, open transactions and history years move into ERPNext, and which stay in a read-only archive.
Document the segment-to-dimension mapping and the trial balance checks that must pass before cutover.

How we build

Deploy ERPNext in your environment with Docker Compose or the bench tool, sized for your database and user counts.
Build repeatable extract, transform and load steps for customers, vendors, items and open transactions using the Data Import tool in batches.
Test imports in a staging site, reconcile balances against GP reports, and record every exception for sign-off.

How we hand over

Deliver runbooks for the import sequence, reconciliation checks, cutover steps and rollback decisions.
Provide configuration and access documentation for administrators, including any server scripts and their enablement settings.
Walk your finance and IT staff through a parallel month end so they can run the process without DeployOpen.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after go-live.
Retainers can cover ERPNext version upgrades, backups and hardening, scoped in writing with your team.
Ask for the support scope, response expectations and upgrade plan in the written quote before work begins.

Migrate from Dynamics GP to ERPNext