Dynamics GP end of support: Business Central or open-source ERP

What the end-of-support decision requires from you

Your exit timeline depends on dates, data and people as much as on the platform. The five cards below cover what your team must settle before comparing Business Central with self-hosted Odoo or ERPNext, from the support horizon to the owner of the cutover.

Staying on GP, Business Central or self-hosted open-source ERP

How each option meets the constraints, and where it falls short

This table compares where each option keeps data, how it is licensed, how long it receives support, and how data leaves it. Read the support column first if your constraint is a fixed end date, and the export column first if your constraint is exit cost. The main takeaway: Business Central and Odoo Enterprise carry vendor-set upgrade and export limits, while ERPNext and Odoo Community depend more on your own patching and upgrade discipline.

Which open-source ERP fits a GP site with add-ons and customization

How to deploy self-hosted Odoo or ERPNext under your data controls

This sequence takes a finance team from choosing a supported version to a cut over where GP history, balances and access rules sit on infrastructure the organization controls.

1. Confirm the target version and support window

   The finance lead and the platform owner choose the Odoo or ERPNext major version before any hosting work starts. For Odoo, check the standard support end dates on the Odoo support documentation, since standard support covers the first three years after a major release and security patches are only provided during that window. For ERPNext, confirm the version appears on Frappe's supported versions page, because a version past end of life carries no Frappe warranty coverage. Record the chosen version, its support end date and the date you plan to upgrade again, since Odoo SaaS and on-premise upgrades are on a fixed cycle. Done when a signed note names the version and its end of support date, and the upgrade calendar is in the change log.

2. Choose the hosting method and build the environment

   The platform team selects how the application runs inside your own data center or cloud account. Odoo can be installed from a packaged installer or from source, and an Enterprise subscription code is entered to activate an on-premise Enterprise database. ERPNext can run with Docker Compose using production images, through the bench command line tool, or on Frappe Cloud, which keeps hosting outside your infrastructure. Where data residency rules apply, the choice of Frappe Cloud should be treated as a third-party hosting decision and reviewed by compliance. Done when a written architecture note covers where the application server, database, backups and mail relay sit, and who holds administrator access to each.

3. Set up database, cache and service tiers

   The infrastructure team builds the database and supporting services, then separates them into tiers. For Odoo, the database is PostgreSQL. For ERPNext, the database is MariaDB or PostgreSQL, with Redis, background workers, the scheduler and the web tier running as separate services in the Compose setup. Restrict database ports to the application network, enforce TLS for connections, and create separate accounts for application and administrative access. Note that the single-file demo setup in frappe_docker is intended for short-lived evaluation only and must not be used for the production system. Done when the staging stack starts cleanly, backups run on a schedule to a location separate from the database host, and a restore has been tested on a copy.

4. Configure identity with LDAP or social login

   The identity team connects the ERP to the directory your staff already use, so user lifecycle and password policy stay under one control. Odoo supports LDAP authentication, and ERPNext documents LDAP integration and Social Login Key configuration for OAuth-style providers. Decide which accounts are local break-glass administrators, store their credentials in your secrets manager, and map directory groups to ERP roles before any finance user logs in. Confirm that leavers are disabled in the directory and that the ERP stops accepting their sessions. Done when a test user from each role can sign in through the directory, and a user removed from the directory is refused access in the test system.

5. Extract GP data and prepare import files

   The data team pulls masters, open transactions and the history you have decided to keep out of the company and system SQL Server databases of Dynamics GP. Work from a read-only copy of the GP databases, not the live system. Prepare one file per object (customers, vendors, items, chart of accounts, open receivables and payables, opening balances) using the templates for the target application, and assign stable external identifiers so later loads update rather than duplicate records. Keep the raw extract in an archive location with access logging. Done when row counts for each object match the GP source and a second person has signed off the mapping of GP account segments to target accounts or accounting dimensions.

6. Import masters in batches and test with duplicates

   The implementation team loads the prepared files into the staging system in small batches. ERPNext's Data Import tool advises importing only a few thousand records at a time, and Odoo's import tool accepts Excel and CSV files with External IDs recommended for third-party data, so both are loaded in controlled groups with error logs reviewed after each run. Keep test copies off production data: for Odoo, use database duplication with neutralization so outgoing email, payment integrations and scheduled actions are disabled in the copy. Done when each batch reconciles to its source counts and the error log is cleared or explained by the finance lead.

7. Run parallel month end and validate trial balances

   Finance runs the close in both GP and the new system for at least one full period, using the same cut-off dates and the same source transactions. Compare trial balances, subledger totals for receivables and payables, inventory valuation and bank reconciliations line by line. Investigate every difference to a specific transaction, mapping rule or rounding treatment, and log the cause. Any scripts or custom logic added on the ERP side should be reviewed for whether it is permitted on that hosting model, since ERPNext Server Scripts are disabled by default from version 15 and Frappe Cloud public shared benches do not allow them. Done when the trial balances agree or every difference has a documented and approved explanation.

8. Cut over and archive the GP environment

   The project owner schedules the cutover after the parallel close is accepted and the open items are re-confirmed on the production date. Freeze GP entry, run the final extract, load the delta, and reconcile the opening balances to the closing GP trial balance. Switch user access, update the backup schedule to cover the production database, and place the GP databases in read-only mode with a verified backup kept for audit retrieval. Done when the sign-off record names the cutover date, the reconciliation evidence is stored with the archive, and auditors have been told where the historical GP data is kept.

Evidence an auditor will ask for during a GP exit

A GP exit is judged on what you can show, not on what you say happened. The cards below cover the records that connect the old Dynamics GP company to the new ledger, and the access and change trail behind them. DeployOpen prepares this evidence, but independent auditors decide whether it is sufficient.

Questions buyers ask before choosing a Dynamics GP exit path

What should decide the path for your organization