Migrate from Business Central to Odoo: what the move involves
A move from Business Central to Odoo is a data extraction, a functional mapping and an extension rewrite, not a file copy. Renewal quotes, licensing changes, data residency rules or simple lock-in concerns usually trigger the decision, but the work starts with the data. Business Central keeps its ledgers, items, customers and dimensions in a SQL-based schema with AL extensions layered on top, and Odoo organizes the same business objects differently. Internal finance and IT staff typically own the decisions about chart of accounts, open items and cut-over dates, while an implementation partner usually handles extraction scripts, import sequences and the rebuild of custom logic. Effort and risk depend mostly on how much AL code the company has written and how many years of history it must carry over. Ask any partner to size those two factors from your own environment rather than from a generic estimate. On the licensing side, be precise about what you are adopting. Odoo Community is published under LGPLv3, according to the LICENSE file in the odoo/odoo repository, and it is the open-source core. Odoo Enterprise is a separate paid subscription that adds features and support, and its source code is not publicly available. Confirm which features your Business Central processes depend on, such as multi-company consolidation or Studio-style configuration, and check whether they sit in Community, Enterprise or the Custom plan on the Odoo pricing page before you plan the target architecture. For the extraction, pick your source path early. Online tenants can export a BACPAC file, but only on a paid subscription, up to 10 times per month per environment, and Microsoft does not support restoring that file into a working on-premises Business Central environment, so the BACPAC is a data source for SQL Server, not a rebuild route. Load it into SQL Server, validate row counts for each table you migrate, and write the export queries against that copy. Odoo's documentation recommends External IDs when importing from a third-party application, so give every extracted record a stable key from Business Central before you import anything.
Which Business Central capabilities map cleanly to Odoo
This table compares the main Business Central areas against Odoo applications and marks each as clean, needs rework or gap. Use it to scope a migration: the clean rows can move with standard configuration, while rework and gap rows need design decisions and custom development before cutover. Confirm module coverage against the Odoo version you plan to run, because application scope changes between releases.
| Business Central area | Odoo equivalent and fit | Status |
|---|---|---|
| General ledger and chart of accounts | Odoo Accounting covers the chart of accounts, journals and fiscal periods; map account numbers and account types before loading opening balances | Clean |
| Items and inventory | Odoo Inventory handles products, variants, locations and valuation methods; confirm costing method and lot or serial tracking match your Business Central setup | Clean |
| Customers and vendors | Odoo Contacts and partner records cover customers and vendors; import with External IDs so later loads update rather than duplicate | Clean |
| Sales and purchasing | Odoo Sales and Purchase cover quotes, orders, invoicing and receipts; approval chains and pricing rules often need reconfiguration | Needs rework |
| Dimensions and posting groups | Odoo uses analytic accounts and plans, not Business Central dimension codes and posting groups; the mapping must be designed before data load | Needs rework |
| Manufacturing | Odoo Manufacturing covers bills of materials and work orders; routings, subcontracting and shop-floor detail need functional review against your Premium setup | Needs rework |
| Service management | Odoo Field Service and Helpdesk cover parts of service work; contract, resource and service item logic may not match and should be confirmed with a fit-gap review | Gap |
| Microsoft 365 integration | Outlook, Excel and Teams links in Business Central have no direct Odoo equivalent; plan replacement connectors or Odoo's own integrations and confirm them for your version | Gap |
| AL extensions | AL extensions must be rebuilt as Odoo Python modules; each custom object, report and event subscriber needs a design, a test plan and an owner | Needs rework |
How to extract ledgers, items and customers from Business Central
Extraction starts with choosing the source. Business Central online can be exported as a BACPAC file to an Azure standard storage account, but only with a paid subscription and up to 10 exports per month per environment, according to Microsoft Learn on exporting databases. If you run Business Central on premises, you already hold the SQL Server database and can skip the export. Confirm which path applies to your tenant and which admin role will run the export before you plan the timeline, since the monthly limit is per environment and a failed or test export uses up one of those slots.
A BACPAC is a data source, not a restore target. Microsoft does not support creating a working on-premises Business Central environment from a BACPAC exported from Business Central online, so do not try to restore it as a replacement tenant. Instead, import the file into a separate SQL Server instance that you control, using a restore environment that is not connected to any production Business Central service. From that copy, query the tables that hold the general ledger entries, the G/L account and dimension setup, the item and item ledger entry tables, and the customer and customer ledger entry tables. Record row counts and control totals per table, such as the sum of ledger amounts by period, so you can prove the extract matches the source.
The extraction is also where you decide what you will not carry across. Open-ended history, posted documents and closed periods have different migration needs than open items and current master data. Tie the extracted ledger balances to the trial balance in Business Central at the cut-over date, and keep the table-level extract scripts under version control. Those scripts become the basis for the CSV files you load into Odoo, where Odoo's export and import documentation describes the External ID approach for third-party data. Ask your implementation partner to confirm how they will reconcile these totals, because the reconciliation evidence matters more to your auditors than the extraction itself.
Which data and integrations move, and which must be rebuilt
Business Central holds master data, balances, documents, users and connectors, and each one follows a different path into Odoo. Some move as data through files, some are recreated in the target, and some need a decision about whether they still belong in the new system.
Master data: customers, vendors and items
Customers, vendors and items are the first records to extract, usually from a BACPAC loaded into SQL Server or from the on-premises database. Export them to CSV or Excel, clean duplicate codes and missing tax or address fields, and keep the original Business Central number in a column. Odoo's import recommends External IDs for data from a third-party application, so each record can be matched later without relying on sequential IDs. Check that item units of measure and product categories map to Odoo's structure before importing.
Open balances and posting history
Opening balances should be loaded as a cutover entry, not as years of replayed transactions. Agree with the finance lead which fiscal periods stay in Business Central as read-only reference and which open items (receivables, payables, inventory on hand) are imported. Historical ledger detail usually stays in an archive so auditors can trace it. Reconcile trial balances and open item totals in both systems before go-live, and confirm with your accountants how the Odoo chart of accounts maps to the existing one.
Documents and attachments
Posted invoices, orders, contracts and scanned receipts sit in Business Central as attachments linked to records. Odoo's CSV and Excel import handles structured fields, not the binary files, so plan a separate export of attachments and a process to link them to the migrated records or store them in a document archive. Decide which documents must be retained for legal or tax reasons and confirm the retention period with your compliance team, since that period is set by your obligations and not by the migration tool.
Users, roles and permissions
Business Central permission sets do not transfer to Odoo. Rebuild access from the role matrix you already have, mapping each permission set to Odoo access rights and record rules, and remove accounts for people who have left. For identity, Odoo documents LDAP authentication in its 19.0 documentation, so you can connect it to your directory, but confirm LDAP support and the required edition for your target version before committing to a design. Plan segregation of duties for posting, approval and bank functions.
Microsoft 365 and third-party connectors
Business Central connections to Outlook, Excel, Power BI, banking feeds, payment processors and tax services each need a decision. Some are standard features you must replace with an Odoo app or a custom module, and some are third-party extensions built as AL code that will not run in Odoo. List every connector from the Business Central admin and extension inventory, classify it as replace, rebuild or retire, and confirm the availability of each target integration with its vendor before the design is final.
Custom AL extensions and reports
AL extensions, custom reports and page changes need to be rebuilt as Odoo Python modules rather than converted line by line. Start with an inventory of every extension, note which ones your business still uses, and remove the rest from scope. Each retained item becomes a design task with its own test cases, and the Odoo custom modules feature is only available on the Custom plan, so confirm the license tier your rebuild needs during planning.
The migration sequence from inventory to decommission
This sequence moves a Business Central company to self-hosted Odoo in controlled stages, so each stage produces evidence that the next one can rely on. The outcome is a cutover the finance team has reconciled and signed off, followed by a managed retirement of the Business Central tenant or server.
Inventory customizations, reports and integrations
Before any data moves, list every AL extension, customized page, report, posting rule, scheduled job and integration that touches Business Central. Record who uses each item, how often it runs and whether Odoo covers it through standard apps, configuration or a custom Python module. Finance, operations and IT leads should review the list together. The output is a mapping workbook that assigns each item to one of four outcomes: standard configuration, Odoo app, custom module, or retire. The step is done when every item has an owner and an outcome.
Extract and map master and opening data
Restore the Business Central database from a BACPAC export into SQL Server, or query the on-premises SQL database directly, and extract chart of accounts, customers, vendors, items, dimensions and open balances. Map each Business Central dimension, posting group and number series to its Odoo equivalent, and assign External IDs so that later loads can update records rather than duplicate them. Confirm with the vendor and your own environment what the export does and does not contain before relying on it. The output is a set of staged files and a signed mapping sheet that finance has approved.
Build and load the pilot on a neutralized test copy
Create the Odoo environment from the chart of accounts and master data mapping, then import the staged files using the Excel or CSV import with External IDs. Load a small set of companies or a single period first, and check the results against the source. Use database duplication with neutralization for any test copy so that test outbound email, payment connectors and integrations cannot reach live parties. Document every import error and the fix applied. The output is a pilot database and an error log showing that each fix was repeated successfully in a clean rerun.
Rebuild custom logic and test it against pilot data
Rewrite the retained AL extensions as Odoo Python modules, configuration or approved standard workflows, then run the business processes that depend on them: invoicing, purchasing, inventory moves, month-end close and reporting. Compare outputs with Business Central results for the same transactions. Involve the users who run these processes, since they will catch differences that technical testing misses. The output is a test log with pass or fail results for each process and a list of accepted differences that the business has signed.
Run parallel periods and reconcile ledgers
Keep Business Central open for transactions while the same activity is posted in Odoo for an agreed number of periods. Reconcile trial balances, customer and vendor open items, inventory valuation and bank balances between the two systems at each close. Investigate every variance until its cause is known and documented. The output is a reconciled trial balance and open item report for each period, with a variance register that shows zero unexplained differences before cutover is approved.
Execute cutover with a signed checklist
Freeze Business Central postings, run the final extraction, load the closing balances and open items into the production Odoo database, and confirm integrations, user access and external IDs. Confirm Odoo's current version and support status before go-live, using the vendor's standard and extended support documentation, and plan for the upgrade cadence that applies to your deployment. The output is a cutover checklist signed by finance, operations and IT, showing the final reconciliation, the time of the freeze and the rollback point.
Decommission Business Central and retain evidence
After a stabilization period agreed in advance, make Business Central read-only, export the records your retention policy requires, and disable integrations and scheduled jobs that still point at it. Confirm with your licensing agreement and Microsoft's documentation what happens to the tenant or on-premises database when subscriptions end. Archive the mapping workbook, reconciliations, test logs and signed checklist together. The output is a decommission record and a retention archive that auditors and future staff can read without Business Central.
Replacing AL extensions with Odoo Python modules
Start by inventorying every AL extension as one of four types: configuration, report, workflow or code. Configuration covers things like number series, posting setups, dimensions and approval thresholds, and usually maps to standard Odoo settings rather than new code. Reports need a decision about whether the standard Odoo report templates cover the layout, while workflows such as approval chains or document status rules may be handled by standard Odoo features or by a small custom change. Only the code items, meaning new tables, page extensions and event subscribers that change posting logic, become candidates for an Odoo Python module. For each item, record the business owner, the users who depend on it and whether it still runs in production, because many extensions from years past no longer earn their maintenance cost.
The decision for each item is one of three outcomes: drop it, replace it with standard Odoo features, or rebuild it as an Odoo Python module. Custom modules are only included in Odoo's Custom plan, according to Odoo's pricing page, and that plan is also the only one that can be hosted on Odoo.sh or on premise. Before design starts, confirm in writing which features your chosen plan includes, including multi-company, Odoo Studio, external API access and custom modules, because a design that assumes a plan without custom modules will need to be rebuilt. Ask the vendor or your implementation partner to confirm how the plan applies to your hosting model, since the Odoo Online options differ from self-hosted installs.
Plan the Python modules as maintained code, not a one-time port. Each module adds a version dependency on Odoo, so every major upgrade will need regression tests for the posting and reporting paths your auditors rely on. Odoo's standard support covers each major release for three years, and the upgrade service moves a database to a newer version through a test copy that must be validated before production, so budget for that test cycle from the start. Keep modules in version control, document which Business Central behavior each one reproduces, and get sign-off from finance on the ledger outputs before go-live. Confirm with your partner who owns the code after handover and how fixes are delivered.
Running both systems in parallel and cutting over
The pilot loads a recent extract into a non-production Odoo database so the team can test the mapping before any business depends on it. Use the extract from the BACPAC or the on-premises SQL database, load it into a scratch environment, and import a limited set of ledgers, items and customers with External IDs. The goal is to find mapping errors while they are cheap to fix, not to prove the whole dataset at once.
- Pick a representative subset: Include open invoices, items with variants or units of measure, customers with several addresses, and at least one closed fiscal year.
- Record every External ID scheme: Keep a written rule for each object so later imports update existing records instead of creating duplicates.
- Test the AL replacements: Confirm that each custom field, report and posting rule you plan to rebuild as an Odoo Python module behaves as expected on the sample data.
- Log every rejected row: Keep the error file from each import, because the pattern of failures shows which source fields need cleaning.
- Repeat the load: Run the same import twice to confirm that re-imports update records rather than duplicating them.
Before leaving the pilot, confirm with your finance lead which balances must match exactly and which exceptions they will sign off on.
In the parallel period both systems hold live data, and the team reconciles balances from each source before trusting the new one. Business Central stays available for reference while Odoo receives the full load and the first real transactions. Plan this period around accounting closes, because a reconciliation that spans a period end is harder to explain to auditors.
- Reconcile trial balances: Compare account balances, open receivables and payables, and inventory valuation between the two systems at agreed dates.
- Compare item and customer counts: Check that record counts and key identifiers match, and document every record deliberately excluded.
- Run test transactions in Odoo: Post sales orders, purchase orders and payments in Odoo to confirm posting, tax and inventory behavior.
- Validate on a test database: Odoo's upgrade documentation describes building an upgraded test database and testing it before production. Apply the same discipline to your migration by running the full import on a copy and testing it before the final load.
- Keep a reconciliation log: Record each difference, its cause and the approver, so the audit trail explains every adjustment.
Confirm with your auditors and tax advisers which reconciliation evidence they expect and whether they accept parallel-period balances as support.
Cutover day is the point where transactions stop in Business Central and start in Odoo. The sequence matters: freeze the source, run the final extract, load and reconcile, then open Odoo to users. Agree the timetable and rollback criteria in advance, because a partial cutover is difficult to unwind.
- Freeze transactions in Business Central: Lock posting and stop order entry before the final extract so no late entries fall outside the migrated data.
- Run the final extract: Export a fresh BACPAC or query the on-premises SQL database after the freeze, and check the file against the reconciliation targets from the parallel period.
- Load and reconcile again: Import the final data with External IDs and repeat the balance comparison before users receive access.
- Set the rollback point: Define the condition under which the team returns to Business Central, and the last moment that condition can be checked.
- Confirm access and integrations: Verify user accounts, roles and any interfaces to banks, payroll or tax tools before go-live.
Confirm with your Microsoft partner or internal administrator how the BACPAC export is scheduled, because the monthly export limit may affect how many final extracts you can take.
After cutover, Business Central should remain accessible in read-only form for historical lookup, audit requests and tax queries. The archive is a separate deliverable from the migration itself, and it needs its own owner, retention rule and access list. Decide what happens to the Business Central environment before the cutover date, not after.
- Keep the final extract: Store the BACPAC or SQL backup from the final freeze in a controlled location with checksums and access logging.
- Restrict write access: Remove posting and setup permissions from all users once Odoo is live, and keep read rights only for named archive users.
- Map retention periods: Align the archive with the record retention periods set by your tax, finance and sector regulators, and ask your legal team to confirm them.
- Document how to query the archive: Write a short guide showing how to restore the file into SQL Server and locate common records.
- Plan the exit date: Set a review date for decommissioning Business Central, and confirm the terms of your Microsoft agreement before you stop paying for the environment.
Confirm with your compliance lead which records must remain readable, for how long, and who may approve their deletion.
What drives migration cost and duration
This table lists the factors that most change the effort and spend of moving from Business Central to Odoo, with the reason each one matters and how to keep it under control. Read it before requesting a written scope, because the same driver often appears in both internal time and partner fees. No durations or prices are given here, so ask for them in the scope document.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Companies, entities and dimensions | Each legal entity needs its own chart of accounts mapping, fiscal calendar and multi-company setup. Odoo's multi-company feature is included only in the Custom plan, so confirm the edition before you map entities. | Consolidate entities where legal structure allows. Document the dimension-to-analytic-account mapping once and reuse it for each company. |
| Years of history carried over | Long transaction histories multiply reconciliation work and raise the number of records to import and check. Opening balances alone may not satisfy audit trail needs. | Migrate summarized opening balances plus open items, and keep closed history in an archived export. Agree the cut-off date in writing. |
| Count and complexity of AL extensions | Each AL extension must be rebuilt as an Odoo Python module, configured, or dropped. Complex posting logic, custom reports and event subscribers usually take the most engineering time. | Inventory every extension and classify it as keep as standard, rebuild, or retire. Retire unused objects before scoping. |
| Integrations and interfaces | Connections to banks, payment gateways, e-commerce, shipping and tax engines must be re-pointed or rebuilt against Odoo's interfaces. Odoo's external API access is part of the Custom plan. | List every endpoint, its data direction and its frequency. Confirm which ones an existing connector already covers before writing custom code. |
| Data quality | Duplicate customers and items, inconsistent units of measure and orphaned records slow cleansing and cause failed imports. Odoo recommends External IDs for third-party imports, which only works if the source keys are clean. | Run duplicate checks and cleanse masters in Business Central before export. Keep a stable External ID per record so reloads update rather than duplicate. |
| User count, roles and training | Permission design, role mapping and user training scale with headcount and the number of distinct job roles. Odoo's per-user pricing applies to the subscription if you choose Odoo Online or Odoo.sh. | Map roles to a small set of Odoo access groups. Train by role, using test databases before go-live. |
| Hosting choice and environments | Self-hosting adds server, backup, monitoring and patching work that Business Central online handles. Odoo Enterprise on-premise requires a subscription code, and the Community edition has no upgrade service. | Decide hosting before scoping. Ask for separate test and production environments in the written scope, and confirm the Odoo edition you need. |
| Odoo edition and subscription | Enterprise adds features, functional support and upgrade access, which carry a recurring subscription. Community is free to use but leaves upgrades and vendor support to you or your partner. | Compare the features you need against each edition and price both options. Ask the partner to state which costs are one-time and which recur. |
| Partner fixed-scope fee and internal time | A partner fee covers agreed deliverables, while internal staff time covers decisions, data owners, testing and sign-off. Scope gaps usually appear as change requests after go-live. | Ask for a written scope listing data objects, extensions, integrations, environments, test cycles and acceptance criteria. Name who on your side approves each step. |
What usually goes wrong and how to prevent it
Most failed Business Central to Odoo migrations do not fail in the final import. They fail earlier, when balances are not reconciled, extensions are not inventoried, or test environments hold live customer data. The cards below cover the risks that recur on this path and the check that prevents each one.
Unreconciled opening balances
Opening balances for receivables, payables, inventory and bank accounts often differ slightly from the Business Central trial balance once transactions are imported by file. A difference that is left open becomes a permanent variance in the first Odoo period. Before loading transactions, agree the opening position for each account in writing, load it as a balanced entry, and compare the Odoo trial balance and aged lists to the signed-off Business Central extract. Repeat this comparison after every test load.
Incomplete extension inventory
Business Central often runs AL extensions that change posting, pricing, approvals or document layouts, and some of them are no longer documented. Each extension that is missed becomes a process gap on go-live day, not a data problem. Build a list from the tenant or the source repository that records each extension, the business rule it enforces and its owner, then mark each item as replaced in Odoo, dropped or still open. Ask the business to confirm every dropped item.
Importing without External IDs
Odoo's documentation recommends External IDs when importing from a third-party application. Without them, a second import run creates duplicate customers, items and invoices instead of updating existing records. Assign a stable External ID from the Business Central primary key (for example, the customer number) to every record in each file, and keep the same IDs across test and production loads. Confirm the count of records in each Odoo object after each run against the source extract.
Production data copied into test
A test database restored from production contains live customer contacts, bank details and open invoices, and it may be reachable by people or integrations that should not see them. Odoo documents database duplication with neutralization for test copies, which disables outgoing mail, scheduled actions and payment connectors in the copy. Use neutralization every time a production copy is made, restrict access to the test environment, and confirm in writing who can reach it before data is loaded.
Underestimating user training
Finance, sales and warehouse staff who have used Business Central for years will meet different navigation, approval paths and document numbering in Odoo. Training that is scheduled after cutover leaves users to learn on live transactions, which is when errors are posted. Build role-based training around the processes each team runs daily, run it on the test database with real sample documents, and plan a period of parallel review for the first close. Ask for the training scope in writing before the project starts.
Cutover without a rollback plan
A cutover that switches users to Odoo without a documented way back leaves the business with no safe option if a load fails or a balance does not reconcile. Keep the Business Central environment read-only but intact until the first Odoo period is closed, record the export date and the last transaction loaded, and agree the decision point at which the team returns to Business Central. Test the rollback steps on the test environment before the production date is set.
How the migration changes by starting point
When Business Central runs on premises and the SQL Server database sits in your own data center or cloud account, you control the extraction. Your team or DeployOpen can attach a copy of the company database to a SQL Server instance, query the ledger, item, customer and vendor tables directly, and export them to CSV or Excel for Odoo's import. Direct access allows full-fidelity extraction, including dimension values, posting setups and historical entries, without the monthly limits that apply to cloud exports.
- Extraction: Work from a copy of the production database, never the live one, and document the query or view used for each object.
- Scope: Confirm which companies, fiscal years and open items are migrated, and whether closed history is loaded or kept as an archive.
- Custom tables: Identify extension tables that hold business data, since they will not appear in standard object lists.
- Testing: Reconcile trial balances and open customer and vendor balances between the source copy and the Odoo test database before any cutover.
- Access control: Keep the extracted files on encrypted storage with named access, because they contain full financial history.
Before starting, ask your Business Central partner or internal DBA to confirm which database version and backup you can legally and technically copy.
Business Central online stores data in the Microsoft cloud, so extraction depends on the export options the service offers. The database export described in Microsoft's admin documentation produces a BACPAC file in an Azure standard storage account, and this route is available only with a paid subscription and up to 10 times per month per environment. You then restore the BACPAC into SQL Server or read it directly for extraction. Microsoft does not support creating a working on-premises Business Central environment from that file, so the BACPAC is a data source, not a migration target.
- Export permissions: Confirm who in your tenant can run the export and where the Azure storage account is configured.
- Timing: Plan the export around the monthly limit so a failed or incomplete run does not block cutover.
- Scope: Expect the file to contain the database as exported, so verify which tables and companies it covers before relying on it.
- Delta loads: Plan a second export or a CSV extract of recent transactions to close the gap between the final export and go-live.
- Testing: Reconcile against the live tenant on the export date, since the source keeps changing.
Confirm your subscription tier and export quota with Microsoft before you commit to a timeline.
Estates with many AL extensions, custom reports, workflows and integrations need the most analysis, because the business logic lives in code rather than in data. Each extension must be classified as retained, replaced by standard Odoo features, rebuilt as a Python module, or retired. Extraction is only part of the work: custom fields, posting logic and automated postings must be reproduced, or the migrated ledgers will not reflect the way the business operates.
- Inventory: Build a register of every extension, report, page and integration, with its owner and business purpose.
- Data model: Map custom fields and table extensions to Odoo models, and decide whether they are stored or derived.
- Scope: Separate configuration that can be recreated by hand from logic that needs a Python module, and budget for the second group separately.
- Testing: Run parallel postings for a full period, comparing outputs from AL and Odoo for the same source transactions.
- Integrations: Confirm each external system's dependency on web services or APIs before choosing an interface pattern.
Ask any proposed partner to show a written mapping of the extension inventory to Odoo features and modules before agreeing a fixed scope.
A single company with a standard chart of accounts, few or no extensions and a modest number of customers and items is the simplest migration. The data can usually be extracted through standard lists, and the Odoo import can handle masters and open balances with External IDs so records can be updated later without duplication. The main risks shift from technical extraction to business decisions about what history to keep and how the chart of accounts is restructured.
- Extraction: Standard lists for customers, vendors, items and open documents are often enough, supplemented by a trial balance export.
- Import: Load masters first, then open balances, and use External IDs to keep references to the source system.
- Scope: Decide whether to migrate only open items and a summary balance, or the full transaction history.
- Testing: Compare the opening trial balance and open receivables and payables line by line before go-live.
- Cutover: Freeze source postings for a short, agreed window so the final extract is complete.
Do not assume simplicity from the number of users alone. Check the extension list and report catalog before deciding the migration is a standard data load.
Questions buyers ask before moving from Business Central to Odoo
How much effort and time does a Business Central to Odoo migration take?
The effort depends on the drivers rather than on a fixed figure, so no duration can be given here. The main drivers are the number of companies and legal entities, the volume of open and historical ledger entries, how many item, customer and vendor records need cleansing, how much of the Business Central setup (dimensions, posting groups, number series, approval workflows) must be recreated, and how many AL extensions have business logic that has to be rebuilt as Odoo Python modules. Ask any implementation partner for a written scope that lists each of these drivers and the data sets in scope, and confirm how many test migration rounds are included before cutover.
What does the client team need to provide for the migration?
The work needs decisions and access from people who know the business, not only from engineers. Plan for a named finance owner who signs off the chart of accounts mapping, a data owner for each master record type, and an IT contact who can provide a SQL Server environment or a BACPAC file. Users who run month-end close in Business Central must also confirm which reports, dimensions and approval steps they need in Odoo. Ask for these responsibilities in writing before the scope is agreed, because delays usually come from unresolved mapping decisions.
Can our internal staff run the migration without an outside partner?
Internal staff can do it if they have experience with both Business Central data structures and Odoo's data model, and if they have time to run several test imports. The usual gaps are extracting data from the Business Central schema correctly, loading records in dependency order with External IDs so that relationships resolve, reconciling control totals, and rebuilding custom logic. Odoo's documentation recommends External IDs when importing from a third-party application, which makes repeated loads safer, but teams still need a reconciliation method. Many organizations split the work: internal staff own business decisions and validation, and an outside partner handles extraction, import tooling and testing.
Can a BACPAC exported from Business Central online be restored on premises?
Not as a working on-premises Business Central environment. Microsoft 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 restore the BACPAC into SQL Server as a read-only source for extraction, then load the data into Odoo through CSV or Excel files. Business Central online exports are limited to a paid subscription and up to 10 times per month per environment, so plan the export schedule around test and cutover runs. Confirm the current export rules in the Microsoft documentation before you commit to a timeline.
How does Odoo Enterprise licensing change the migration plan?
Odoo Enterprise is a paid edition with extra features and support, and its source code is not publicly available. Odoo states that Community is the core on which Enterprise is built, so a Community-only plan limits which applications and features you can use. Only the Custom plan on Odoo's pricing page can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company, Odoo Studio, external API access and custom modules. Before design, confirm which applications, companies and integrations you need, because those choices determine the edition, the per-user subscription cost and whether custom modules are possible. On premise Enterprise databases are activated with a subscription code.
How do Odoo's support windows affect the target version?
Odoo's standard support covers the first three years after a major release, including security updates and bug fixes, and paid extended support is limited to Odoo.sh for select versions and on-premise. Security patches are only provided during standard support, so the target version matters for the long term. Odoo 20.0 has standard support planned until September 2029, and Odoo 19.0 until September 2028. Odoo 17.0 standard support ended in September 2026. Choose a version that is still in standard support at go-live, and plan the upgrade path, because on Odoo Online and Odoo.sh major upgrades are mandatory every two years. Confirm the current dates in Odoo's support documentation before you sign.
How does DeployOpen scope a Business Central to Odoo migration?
DeployOpen plans, implements and hardens self-hosted open-source platforms inside the client's own infrastructure, and most engagements are fixed-scope. The written scope usually covers the data extraction approach, the object list (ledgers, items, customers, vendors and dimensions), the import method with External IDs, the rebuilt customizations, test rounds, cutover steps, backup and documentation. Deliverables and timelines are agreed in writing before work starts, and a quote follows from that scope. DeployOpen does not publish a price list. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.
How DeployOpen scopes and runs this migration
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Business Central to Odoo, that work typically covers standing up the Odoo environment, mapping the extracted ledgers, items and customers to Odoo objects, running the External ID import, rebuilding the AL extension behavior as Odoo Python modules, and writing the runbooks your team needs afterward. Before any work starts, the scope should name the source of the extract (the BACPAC file or the on-premises SQL database), the Odoo edition and version, the hosting location, and the test cycles that must pass before cutover.
Most engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work begins, so the decisions that drive cost are visible up front: how many AL extensions must be rebuilt, how many companies and posting groups must be mapped, which reports and integrations must be replaced, and how much history must be loaded. DeployOpen does not publish a price list, so the reader should ask for a quote that follows from that written scope and that separates one-time migration work from recurring items. Ongoing support, Odoo version upgrades and continuous testing are available as a retainer. Confirm with Odoo which edition and support terms apply to your deployment, because standard support, security patches and the mandatory upgrade cadence on Odoo.sh and Odoo Online differ from on-premise use.
DeployOpen prepares systems, controls and evidence for compliance assessments, such as reconciliation reports, access role records, change logs and backup restore tests. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments, so your finance and compliance leads should agree early which evidence the auditor will request and confirm that the auditor accepts the format DeployOpen delivers.
