Which open-source ERP fits a Business Central replacement?
If you are weighing a Business Central replacement because of a renewal, a licensing change, a residency requirement or lock-in, Odoo is the stronger fit when you want broad module coverage and a commercial upgrade path, and ERPNext fits when you want a fully GPL-3.0 stack built on the Frappe Framework. Odoo Community is published under the LGPLv3, and Odoo Enterprise adds features such as Odoo Studio, functional support and version upgrades on top of that core. ERPNext is GPL-3.0 throughout and runs on MariaDB or PostgreSQL with Docker self-hosting. Both can run in your own cloud account or data center, which is the main reason to consider them when residency or control of the database is the driver. The pressure usually comes from how Business Central is deployed. It can run online, with data stored in the Microsoft cloud, or on-premises, and the two models do not move data freely between each other. Online databases can be exported as BACPAC files to an Azure standard storage account, but only with a paid subscription and up to 10 times per month per environment. Microsoft also states it does not support creating a working on-premises Business Central environment from a BACPAC exported from the online service. If your exit plan assumes you can take a full working copy of the database and run it yourself, that assumption needs to be tested before you commit to a timeline.
Before choosing between the two, confirm which deployment you run today, whether your entitlements and export quota cover the data pull you need, and which extensions your business depends on, since those set the rebuild effort more than the core ledgers do. Ask your Business Central partner for a written inventory of tables, customizations and reports, and check that the open-source candidate covers the accounting and inventory processes you actually run. Plan for the export to be a source of data, not a working database: you will re-create configuration and load masters through each platform's import tools, and the Business Central export cap means you should schedule your trial loads well before the cutover window rather than relying on repeated full exports.
Odoo Community or ERPNext: which one to shortlist
Both Odoo Community and ERPNext can host Business Central-style ledgers, items and customers on infrastructure you control. They differ in licensing structure, the features you may have to pay for, and the development model your team would own, so the shortlist should follow those differences.
Odoo Community: the core edition
Odoo Community is published under the LGPLv3, and Odoo describes it as the core on which the licensed Enterprise edition is built. It fits teams that want a permissive open-source base and can accept that some conveniences sit in Enterprise. Check which modules your Business Central extensions depend on, and confirm whether each one exists in Community or only in Enterprise before you commit to a design.
Odoo Enterprise: the trade-off
Odoo Enterprise adds features such as Odoo Studio, functional support, version upgrades and Odoo Online or Odoo.sh hosting. Those are recurring subscription costs on top of your infrastructure and implementation work. Ask Odoo for a written list of what each edition includes, and model the subscription for every user and year, not just the first deployment.
Odoo release and support cycle
Odoo documents that each major version is supported for three years, followed by two more years to complete the upgrade. Minor versions usually arrive about every two months. Your team must plan major upgrades inside that window, and your custom modules must be ported at each one. Budget upgrade work as a recurring cost, not a one-time project.
ERPNext: GPL-3.0 on Frappe
ERPNext is GPL-3.0 licensed and built on the Frappe Framework, with MariaDB or PostgreSQL as the database. It fits organizations that want a full open-source ERP with the accounting, inventory and selling modules in one codebase, and that can self-host with Docker. Confirm the database engine your data team and backup tooling already support, because that choice shapes your operations for years.
The Frappe framework learning curve
Customizing ERPNext means working with Frappe doctypes, server scripts and the framework's conventions rather than standard Python modules alone. Replacing AL extensions therefore needs developers who learn that framework, or a partner who already knows it. Ask for a worked example of one of your extensions rebuilt on the framework before you choose ERPNext for a heavily customized estate.
Hosting and operations ownership
Whichever candidate you choose, you own hosting, patching, backups and database administration if you self-host. Odoo.sh and Odoo Online are paid Enterprise options, and Frappe Cloud is a managed option for ERPNext. Decide early whether your team will run the platform, and confirm who carries on-call duties for month-end close and upgrade windows.
How Business Central capabilities map to open-source modules
This table pairs each core Business Central area with its closest Odoo and ERPNext equivalent and notes where coverage differs. Read it as a starting shortlist, then confirm each row against your own localization, dimension and posting requirements, because the supplied research does not establish those details for either platform.
| Business Central area | Odoo equivalent | ERPNext equivalent and gaps |
|---|---|---|
| General ledger and chart of accounts | Accounting app with chart of accounts, journals and fiscal periods. Confirm posting rules and closing workflows for your jurisdiction. | Accounts module with chart of accounts and general ledger. Confirm period closing and posting controls against your current setup. |
| Multi-currency and dimensions | Multi-currency support is available. Confirm how many analytic dimensions you need and how they feed reporting. | Multi-currency support is available. Confirm how accounting dimensions map from your Business Central dimension codes. |
| Items and inventory | Inventory app covering stock locations, moves and valuation. Confirm costing methods and lot or serial tracking. | Stock module covering warehouses, item valuation and stock ledger. Confirm costing method and batch handling for your items. |
| Sales and purchasing | Sales and Purchase apps cover quotations, orders, invoicing and vendor bills. Confirm approval chains and returns handling. | Selling and Buying modules cover quotations, orders, invoices and purchase receipts. Confirm approval flows and drop shipment needs. |
| Customers and vendors | Contacts and partner records hold customers and vendors. Import them with External IDs to keep references from Business Central. | Customer and Supplier masters with Data Import templates. Import in batches of a few thousand records at a time. |
| Reporting and analysis | Standard financial reports and pivot views are included. Custom report layouts may need Python or report development. | Financial statements and script or query reports are included. Custom reports and Business Central page extensions need rebuilding in Python. |
What you give up when leaving Business Central
Moving from Business Central to Odoo or ERPNext changes more than the ledger engine. The items below are the Microsoft integrations, marketplace extensions, support contracts and vendor-managed upgrades that many finance and IT teams rely on without tracking them as costs. Inventory each one before you set the migration scope.
Microsoft 365 and Teams links
Business Central users often work from Excel, Outlook and Teams with the ERP data one click away. In Odoo or ERPNext, those links do not come with the product, so you rebuild them. Plan Excel workbooks that read from the open-source database through the import and export tools, and use Odoo's Excel import and export for recurring spreadsheet work. Ask each department which Microsoft 365 workflows depend on ERP data, and decide whether each one becomes a connector, a scheduled export or a manual step. Confirm that any connector you choose supports your identity provider and your data residency rules.
Power BI reports and dashboards
Power BI reports built on Business Central data usually connect to the live tables or to a reporting feed. Those connections must be redesigned. Choose a reporting target first, such as a PostgreSQL or MariaDB read replica, a warehouse or a BI tool that reads the open-source database, then rebuild the highest-value reports before retiring the old ones. Keep a list of every report, its owner and its refresh schedule, and confirm that the open-source database user you create has read-only access to the reporting tables only.
AppSource extensions with no direct equivalent
Many Business Central customers run AppSource extensions for tax, banking, e-invoicing or industry features. Some have an open-source counterpart in Odoo or ERPNext apps, and some do not. For each extension, record the functions it adds, the data it writes and the people who depend on it. Where no equivalent exists, plan a custom Python module built on the target framework, and budget its build, testing and maintenance as recurring work. Confirm with each vendor whether the extension can run on your target platform at all.
Partner support contracts
A Business Central partner typically provides implementation help, break-fix support, and change requests under a contract with defined response terms. Leaving that model means you pay a support provider directly for each component, or you staff those roles internally. Ask any provider for a written scope that covers the ERP application, the database, the hosting and the integrations, and confirm who answers when a close is blocked. Those contract terms are what you are replacing, so compare them line by line.
Vendor-managed upgrades
Business Central receives platform updates from Microsoft in its online service, so your team does not schedule the platform upgrades itself. Self-hosted Odoo and ERPNext place that work on your team or your provider. Odoo documents that each major version is supported for three years, followed by two more years to complete the upgrade, and that minor versions are usually released every two months. Build an upgrade calendar, test custom modules on each release, and confirm the support window before you commit to a version.
How to move ledgers, items and customers off Business Central
This sequence moves Business Central master data and open balances into Odoo or ERPNext, proves the results in a pilot and a parallel run, and ends with a documented cutover and a decommissioned source. The output is a target system that reconciles to the source at a known date.
Inventory AL extensions and integrations
Your team lists every AL extension, report, page, codeunit, scheduled job, and third-party connector that touches Business Central, along with who uses each one and what it produces. A BACPAC carries table contents only, so every piece of business logic must be assigned to a replacement, a Python module in the target system, or retirement. The step closes when each item has an owner and a disposition, and the finance and operations leads have signed off the list.
Export the source database
For an online environment, a tenant administrator exports the database as a BACPAC file to an Azure standard storage account from the Business Central admin center, which requires a paid subscription and allows up to 10 exports per month per environment. On-premises installations are exported with the database tooling your team already runs. Store the export in a restricted location and record its date, environment, and checksum. Keep in mind that Microsoft does not support restoring an online BACPAC into a working on-premises Business Central environment, so the file serves as a data source for extraction only.
Extract and map masters and open balances
Restore the BACPAC into a non-production SQL Server instance, then extract customers, items, chart of accounts, dimensions, and open ledger entries into staging files. Map each Business Central field to the Odoo or ERPNext object, and define how you will reference third-party records. Odoo recommends External IDs when importing from another application, so give every migrated record a stable source key. The step closes when a mapping document covers every object in scope and each field has a transformation rule.
Load data with import templates in batches
Prepare Excel or CSV files that match the target import templates and load them in dependency order: chart of accounts and dimensions first, then customers, vendors, items, and finally open documents. ERPNext's documentation recommends importing a few thousand records at a time, so split large tables into batches and log each result. Your team reruns each batch in a clean target database until errors are zero. The step closes when record counts and control totals match the staging files for every object.
Rebuild logic as Python modules and run a pilot
Developers re-create the retained AL behavior as Python modules in the target framework, such as custom validation, posting rules, and document numbering, and they rebuild each integration against the new interfaces. A pilot company or one business unit then processes real transactions for a period your finance team defines. Confirm the report outputs, tax results, and approval flows match the Business Central results for the same inputs. The step closes when the pilot sign-off lists every open defect and its resolution.
Run both systems in parallel
Business Central and the target system run side by side, with transactions entered in one system and reconciled to the other on an agreed schedule. Finance compares trial balances, subledger totals, inventory valuation, and open receivables and payables each cycle, and records every variance with a cause and an owner. Confirm that audit trail requirements, including user and timestamp history for changed records, are met in the target system before the parallel period ends. The step closes when reconciliation shows no unexplained variances across two consecutive cycles.
Cut over and decommission Business Central
Freeze the source at an agreed cutoff, run a final extract and load, and reconcile the target to the frozen balances before users open transactions in the new system. Redirect integrations, retire scheduled jobs, and revoke user access to the old environment while keeping a read-only archive under your retention policy. Decide with your licensing and contract owners when the subscription ends. The step closes with a signed cutover record, a retained archive with a documented restore path, and a decommission checklist that is complete.
Which option fits by situation
If your main driver is where data is stored, self-hosting moves the database, file storage and backups into your own cloud account, data center or air-gapped network. Business Central online keeps data in the Microsoft cloud, and Microsoft documents an on-premises deployment option, but a BACPAC exported from the online service cannot be restored into a working on-premises Business Central environment. That makes the migration a one-way extract into a new platform rather than a lift of the running environment. Both Odoo and ERPNext run on infrastructure you control, with ERPNext supporting MariaDB and PostgreSQL and Docker-based self-hosting.
- Hosting location: You choose the region, account and network boundaries for the application, database and object storage.
- Database engine: ERPNext supports MariaDB and PostgreSQL. Confirm which engine your database team already operates and backs up.
- Backup and restore: Your own backup schedule and restore tests replace the vendor's default service behavior.
- Admin access: Restrict database and server access to named staff, and record who can reach production data.
- Vendor-hosted options: Odoo Online, Odoo.sh and Frappe Cloud are managed services, so check their data location before choosing them.
Before you commit, ask your legal and privacy team to confirm which data sets must stay in-country and whether any export must pass through a managed service.
If licensing terms or renewal pricing are the trigger, the open-source core changes the cost structure more than the license fee does. Odoo Community is published under LGPLv3, and Odoo describes Community as the core on which Enterprise is built, so the decision is whether you need Enterprise features such as Odoo Studio, functional support, version upgrades or Odoo Online or Odoo.sh hosting. ERPNext is GPL-3.0 licensed, so the software itself carries no license fee. Your recurring costs then move to infrastructure, support, upgrades and staff time.
- Community core: Confirm that the modules you use are available in Community before assuming a zero-subscription setup.
- Enterprise decision: List which Enterprise features you need, such as Studio or hosting, and price them separately.
- Upgrade cadence: Odoo states each major version is supported for three years, followed by two more years for the upgrade, and minor versions are usually released about every two months. Plan for this recurring work.
- Infrastructure: Hosting, storage and backups are recurring costs that you control.
- Support contracts: Ask any partner for a fixed-scope quote that separates one-time implementation from ongoing support.
Ask for a written comparison of total cost over the period you plan to run the system, including the Business Central licensing you would retire.
If your Business Central environment depends on heavy AL extensions, the migration is mostly a rebuild exercise. AL extensions do not move to Odoo or ERPNext, so each custom table, page, report, codeunit and event subscriber needs a equivalent design. In Odoo, custom behavior is normally built as Python modules that extend models and views, and ERPNext customizations are built on the Frappe Framework. Standard features covered by extensions may already exist in the target, which reduces the volume of rebuild work.
- Inventory of extensions: List every AL object, its business purpose and its users before choosing a target.
- Standard coverage: Map each extension to a built-in feature, a configuration change or a custom module.
- Integrations: Identify every external system that calls Business Central APIs or receives its data, since those connections must be rebuilt.
- Reports: Rebuild reports and documents in the target format and test them with real month-end data.
- Ownership: Name who maintains custom Python code after go-live and how changes are reviewed.
Ask your implementation partner to give a written estimate per extension group, and confirm which extensions you can retire.
In regulated organizations, the question is whether the new platform can produce the audit trail, access control and change evidence that your assessors will request. A self-hosted deployment lets you design those controls and collect the evidence yourself. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so agree the evidence set with them before go-live.
- Audit trail: Confirm the target records who changed ledger entries, master data and posting settings, and when.
- Access control: Document role design, segregation of duties and periodic access reviews.
- Change management: Record upgrades, custom module releases and emergency fixes with approvals.
- Data export for assessors: Test the exports auditors will request from both systems during migration.
- Scope of certification: Confirm with the certifying body which controls and environments are in scope.
Before migration, ask your auditor which evidence they expect from the first period after cutover and whether the old system must remain readable for the retention period.
Questions to answer before replacing Business Central
How long does a Business Central to open-source ERP migration take?
The duration depends on the volume and complexity of what you move, so no fixed timeline applies to every company. The main drivers are the number of companies and entities in scope, how many years of ledger history you keep, how many AL extensions and reports need rebuilding, and how many integrations sit around the ERP. Each migration phase, from data mapping through test cycles to cutover, adds effort that grows with those factors. Ask for a timeline only after a written scope lists each entity, data set and customization, so the estimate reflects your actual environment.
Can our internal team run this migration without outside help?
Some teams can, particularly where they already administer databases and have a developer who knows Python and the chosen platform's framework. Internal teams usually struggle with data mapping, reconciliation of opening balances and rebuilding customizations under deadline pressure. Assess three things honestly: whether you have someone who can run a test migration and reconcile totals to the cent, whether finance can sign off each data set, and whether anyone can operate the hosting after go-live. A fixed-scope engagement can cover the parts your team does not have capacity for, and the written scope should state who owns each deliverable.
What does it cost to rebuild AL customizations in Python?
Rebuild cost depends on how much logic lives in AL extensions, not on the number of extensions alone. Costs rise with custom posting logic, bespoke reports, document layouts, approval workflows and integrations that call your extensions through events or APIs. Each one needs requirements, a Python module or configuration equivalent, tests and user acceptance. Some functions may map to standard features on the target platform, which lowers the effort. Ask each vendor or partner to itemize rebuilds by function, and separate one-time build work from recurring hosting, upgrades and support.
Is a BACPAC file enough to bring over our full history?
A BACPAC file alone is usually not enough to produce a working system. Microsoft documents that Business Central online databases can be exported as BACPAC files to an Azure standard storage account, but only with a paid subscription and up to 10 times per month per environment. Microsoft also states it does not support creating a working on-premises Business Central environment from a BACPAC exported from Business Central online. The practical route is to extract ledgers, items, customers and open documents as structured files, then import them with the target's templates. Confirm with Microsoft which export rights your subscription provides before planning the extraction window.
Should we choose Odoo or ERPNext based on our team's skills?
Choose based on the skills you can staff, not on feature lists alone. Odoo is published under LGPLv3 and its documentation describes Odoo Community as the core on which Enterprise is built, so your team should be comfortable with its module structure and Python customization. ERPNext is GPL-3.0 licensed and built on the Frappe Framework, with MariaDB or PostgreSQL support and Docker self-hosting, so it suits teams comfortable with that stack. Test both against a sample of your real ledgers and items, and check which platform your existing developers and integration partners can maintain for years.
What does the migration need from our internal IT and finance teams?
Both teams carry work that no external provider can complete on their behalf. IT must supply access to the source tenant, decide where the new system will run, provision environments, manage identity, and own backups and monitoring after go-live. Finance must define the chart of accounts mapping, approve opening balances, agree on which history stays in the archive, and sign off reconciliations for each entity. Expect both teams to run parallel testing before cutover. Confirm named owners, review dates and sign-off criteria in the written scope before work starts.
What does DeployOpen cover in a Business Central replacement?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Business Central replacement, that can include the target environment, data extraction and import, rebuilt customizations, security testing and compliance readiness evidence. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so request a quote based on a written scope. Ongoing support and upgrades are available as retainers.
What changes for finance, IT and users after cutover
Finance will see a different ledger interface on day one, and the change is larger than a new login page. Business Central users are used to a specific chart of accounts layout, dimension handling, posting routines and role-based pages. In Odoo or ERPNext, journal entries, reconciliation, payment matching and period closing are reached through different menus and different validation rules, so finance staff should walk through a full month-end close in a test environment before the first live period. Ask the implementation partner to document every posting screen that your team uses daily, and confirm which of your Business Central reports have a direct equivalent and which must be rebuilt as custom reports or spreadsheet exports.
IT takes on responsibilities that the Business Central cloud service currently handles for you. Your team will own database backups, restore testing, access control, TLS certificates, patching of the operating system and database, and monitoring of the application server. On the application side, upgrade cadence is a standing duty: Odoo states that each major version is supported for three years, followed by two more years to complete the upgrade, and minor versions are usually released every two months. Confirm which version your partner recommends, who applies minor releases, and how upgrades are tested against your custom Python modules before they reach production. Document who may grant and revoke administrator roles, since that decision no longer sits with a vendor console.
End users need training that matches their actual tasks, not a generic product tour. Sales order entry, purchase approvals and inventory adjustments will each feel different, and the users most affected are those who relied on Business Central extensions or Power Platform integrations that now need replacement. Plan role-specific sessions, a short reference guide per role and a support window for the first two or three closing cycles. Budget for these items in the written scope, because training and hypercare are effort that continues after the data has moved.
How DeployOpen scopes, migrates and supports the replacement
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source ERP platforms inside your own cloud accounts, data centers or air-gapped networks. For a Business Central replacement, that means turning the export, mapping and customization work into a written scope that your finance, IT and security teams can review before any build starts.
How we scope
- Inventory the Business Central extensions, reports, and integrations that your finance and operations teams rely on today.
- Agree in writing which ledgers, items, customers and open documents move, and which history stays archived.
- Confirm the deployment target, hosting location, and data residency requirements before selecting Odoo or ERPNext.
How we build
- Map Business Central AL extension behavior to Python modules or configuration in Odoo or ERPNext, and flag gaps early.
- Prepare import templates and External IDs so migrated records keep traceable links to their Business Central source.
- Run test migrations and reconciliation checks on ledger balances, item quantities and customer totals before cutover.
How we hand over
- Deliver architecture notes, configuration records, custom module documentation, and runbooks for your own administrators.
- Document the reconciliation results, cutover steps, and rollback plan so your auditors and controllers can review them.
- Train named administrators on user access, backups, and version upgrade procedures for the platform you chose.
How we support
- Ongoing support, upgrades, and continuous testing are available as retainers after the initial handover.
- Upgrade the platform on a planned cadence, retesting custom modules and reports against each new release.
- DeployOpen prepares systems, controls, and evidence for compliance assessments, while independent auditors issue any formal opinion.
