What you can export from Business Central, and what you cannot
If your team must get data out of Business Central online before a renewal or exit, the documented full-database path is a BACPAC export to Azure storage. Only internal and delegated administrators holding the D365 BACKUP/RESTORE permission set can start one, and each export is logged on the Operations page of the admin center. The export requires a paid subscription, can be run up to 10 times per month per environment, and must write to a Standard general-purpose v2 Azure storage account, since V1 and premium accounts are not supported. You also need a shared access signature valid for at least 72 hours, because large databases can take from several minutes to several hours to finish. Confirm the current limits and the exact steps in the Business Central database export documentation before you schedule the work.
The file itself is narrower than many teams expect. The BACPAC holds only your business data, such as ledgers, items, customers and vendors, because application objects and metadata sit in a shared application database that is not exported. Microsoft states that the file can be imported into Azure SQL Database or SQL Server for further processing, which is where extraction for an Odoo or ERPNext migration starts. Treat that as a one-way door: Microsoft does not support building a working on-premises Business Central environment from a BACPAC exported from Business Central online, so the file cannot serve as an exit route back into a self-hosted Business Central instance.
Plan around these limits early. Ask your Microsoft partner or tenant administrator to confirm the subscription tier, the storage account configuration and the export window, and export a test copy before the renewal deadline so that a failed run does not consume your monthly allowance at the worst moment. Also inventory any data that lives outside the database, such as attachments, documents and report layouts, because the BACPAC will not carry it. Those items need a separate extraction plan, which the migration sibling pages on Odoo and ERPNext cover in more detail.
Which exports Microsoft documents and their formats and limits
This table lists the export paths Microsoft documents for Business Central online and what each one produces, with the limits that apply to it. Read it as a closed list: anything not shown here, such as CSV or API exports of a full database, is not documented in the sources used for this page and must be confirmed with Microsoft before you plan around it. The main takeaway is that the BACPAC is the only full-database export path documented, and it carries conditions on storage, permissions and frequency.
| Data or path | Method | Format | Limits and conditions |
|---|---|---|---|
| Full database export (online) | Admin center database export to an Azure storage account | BACPAC file | Standard general-purpose v2 storage only, 10 exports per month per environment, paid subscription required |
| Storage access for export | Shared access signature for the target container | Azure storage blob | Signature must be valid for at least 72 hours; V1 and premium accounts not supported |
| Export duration | Single database export job | BACPAC file | From several minutes to several hours, depending on database size |
| Who can export | Internal or delegated administrator | Not applicable | Requires the D365 BACKUP/RESTORE permission set; every export is logged on the admin center Operations page |
| Business data contents | Included in BACPAC | BACPAC file | Customer business data only, because application data sits in a shared application database |
| Import for extraction | Load into Azure SQL Database or SQL Server | SQL database | Use for further processing and data extraction; a working on-premises environment cannot be created from this file |
| CSV, Excel or API full export | Not documented in the supplied sources | Not documented | Confirm with Microsoft before planning; do not assume a format or limit for these paths |
What the BACPAC does not contain and how teams work around it
A BACPAC carries the customer's business data and nothing that sits in the shared application database. The cards below cover what is missing from the file and the work teams do to rebuild or retain it before they load data into Odoo or ERPNext.
Rebuild from business data tables
The BACPAC holds the business data tables, so ledgers, customers, items and posted documents can be read directly once the file is loaded into SQL Server or Azure SQL Database. Teams map these tables to Odoo or ERPNext records and check row counts and balances against Business Central reports before they accept the extract. Confirm with your Business Central partner which tables hold your company-specific data, since table layouts reflect your configuration and extensions.
Document AL extensions separately
Extensions, custom objects and the application-level metadata that defines them are not in the file. Before you export, inventory every installed extension, its publisher, version and the tables and pages it changes. This inventory becomes the specification for the Odoo Python modules or Frappe apps that replace them, and it shows which customizations you can drop entirely.
Record configuration outside the database
Setup pages such as number series, posting groups, dimensions, tax setup and approval rules are held as application configuration rather than as the business data you export. Capture them as screenshots, configuration worksheets or exported settings where Business Central offers them, and keep a dated copy. These records guide how the chart of accounts and dimensions are rebuilt in the target system.
Extract attachments and documents
Files attached to records and documents stored outside the business data tables may not be in the BACPAC. Ask your Business Central partner or Microsoft support which export path covers attachments in your tenant, and test it on a copy before the cutover. Plan for these files to move separately from the database extract, with a manifest that links each file to its source record.
Retain reports and posting history
Reports, printed statements and the posting audit trail give auditors a fixed reference point. Export period-end reports to PDF or Excel and keep them with the BACPAC and its checksum. Because the BACPAC is a point-in-time copy, record the export date and the last posted entry number so reconciliations after migration have a documented baseline.
Confirm the on-premises limit
A BACPAC from Business Central online cannot be restored to a working on-premises Business Central environment, so the file is an input to another system, not a backup you can restore into Business Central. Treat the export as a one-way extract for migration and archival, and do not plan a fallback that depends on restoring it into Business Central.
Who may run the export and what each role needs
Internal administrators are the people in your organization who hold administrative rights over the Business Central environment and the Microsoft 365 tenant that hosts it. For a database export, the account must also carry the D365 BACKUP/RESTORE permission set. Without that permission set, the export option is not available, regardless of other administrative roles. Microsoft documents this requirement in its admin center guidance, and it applies to every export, not only the first one.
- Permission check: Confirm that the account has the D365 BACKUP/RESTORE permission set assigned in the Business Central admin center before planning the export window.
- Audit trail: Every export is logged on the Operations page of the admin center, so the export is traceable to the operator who ran it.
- Scope of responsibility: Internal administrators are usually the ones who approve the export, confirm the target environment and record the reason for the export in the change log.
- Coordination: Agree on who starts the export and who monitors it, because a large database can take from several minutes to several hours to finish.
- Access limits: Holding the admin role alone is not enough. Check the permission set itself, not only the job title.
Ask your Microsoft partner or tenant administrator to confirm that the named operator holds the permission set before the export is scheduled.
Delegated administrators are partner staff who manage the customer's tenant on the customer's behalf under a partner relationship. They can run a database export only if they also hold the D365 BACKUP/RESTORE permission set in the environment. Their rights come from the partner relationship rather than from a directory account in your own organization, which means their access can change when the partner contract or the delegation changes. Treat the delegation as a dependency to verify, not an assumption.
- Delegation status: Confirm that the partner relationship is active and that the delegated administrator is still assigned to your tenant.
- Permission set: A delegated administrator without the D365 BACKUP/RESTORE permission set cannot export, even if they can manage other parts of the tenant.
- Logged activity: Exports started through delegated access appear on the Operations page in the same way as internal exports, so the record shows that the partner acted.
- Contract alignment: Check whether your partner agreement allows the partner to perform data exports and hand the file to you or to a third party.
- Handover: If the partner will not be involved in the migration, agree in writing on when delegated access ends.
Ask your partner to state in writing which named staff member will run the export, which permission set they hold, and whether that person will still have access after the handover.
The export writes the BACPAC file to an Azure storage account that you or your team controls, not to Business Central itself. The storage account must be a Standard general-purpose v2 account. Version 1 and premium storage accounts are not supported. The export also needs a shared access signature with a validity of at least 72 hours, so that the export has time to finish. Whoever creates the storage account and the signature needs access to the Azure subscription that owns the account, which is often a different team from the one that runs the Business Central export.
- Account type: Create a Standard general-purpose v2 storage account. Do not use a version 1 or premium account for this purpose.
- Signature validity: Generate a shared access signature valid for at least 72 hours, and check that the expiry date covers the full export window.
- Storage ownership: The person who creates the account and signature must have access to the Azure subscription, which may be a different person from the one who runs the export.
- Retention: Decide who keeps the BACPAC after the migration and how long it is retained, since the file holds the customer's business data.
- Access control: Limit access to the container to the named migration team, and remove access once the data has been loaded.
Confirm with your tenant administrator and your Azure subscription owner who will create the storage account and the signature, and who will hold the file after the export.
Most staff in a Business Central business have no export role at all, but they still have a part to play. Finance, operations and IT staff who will validate the data, sign off the scope or receive the file for the Odoo or ERPNext migration need to know what the export does and what it does not do. They do not need administrator rights. Their job is to define which data the migration team must extract and to confirm the result against the source records once the file has been loaded.
- Data owners: Name the people who approve the ledgers, items, customers and open documents that the migration will carry over.
- No admin rights needed: Staff who only review data or receive reports do not need the D365 BACKUP/RESTORE permission set.
- Acceptance checks: Agree on the reconciliation points, such as account balances and record counts, that the data owners will check after loading.
- Restricted files: Tell the migration team who may receive copies of the BACPAC, since it contains the customer's business records.
- Questions to ask: Ask the administrator whether the export is complete and logged before anyone starts loading data.
Before the export starts, ask your administrator to confirm in writing who holds the permission set, who owns the storage account, and who will receive the file.
Export sequence: from storage setup to a verified BACPAC
This sequence takes a Business Central online database from a confirmed admin role and storage account to a BACPAC file that you have checked by importing it and comparing row counts. The export is the first step of an Odoo or ERPNext migration, so the verified file is the input your extraction work depends on.
Confirm subscription and administrator roles
Before anything else, confirm that your tenant has a paid Business Central subscription, since the BACPAC export is only available with one. Then confirm which person will run the export: only internal and delegated administrators holding the D365 BACKUP/RESTORE permission set can export Business Central databases. Ask your Microsoft partner or tenant administrator to verify both points in writing. The step is done when the named operator can open the admin center and sees the database export option for the production environment.
Create a Standard general-purpose v2 storage account
Create an Azure storage account of the Standard general-purpose v2 type in the region and subscription your team controls. Business Central online exports only to this account type, and V1 and premium storage accounts are not supported, so check the account type on creation rather than correcting it later. Restrict access to the people who will handle the file, because the BACPAC contains your business data. The step is done when the account's properties show Standard performance and general-purpose v2, and a container exists to receive the export.
Generate a shared access signature for the container
Create a shared access signature (SAS) scoped to the export container with write permission and an expiry valid for at least 72 hours. Set the expiry with margin, because an export of a large database can take from several minutes to several hours, and a SAS that expires mid-run forces a repeat. Store the token in your team's secrets vault, not in a ticket or email. The step is done when the token's start and expiry times are recorded in your runbook and the token has been tested for write access to the container.
Start the export from the admin center
In the Business Central admin center, open the production environment and start a database export to the storage container using the SAS. Record the start time, the environment name and the operator who triggered it. Because every export is logged, the entry you create here will be the audit reference for the file. Do not start a second export on the same environment while the first is running unless you have confirmed how the first will be handled. The step is done when the admin center shows the export as in progress.
Monitor the Operations log until the export completes
Watch the export entry on the Operations page of the admin center until its status shows completion or failure. A failure reported here should be captured with its message and the environment name before any retry, since repeated attempts count against the monthly export limit of 10 per environment. Keep the operator available during the run so an expired SAS or storage issue can be fixed quickly. The step is done when the Operations entry records a successful export and the timestamp is noted in the migration log.
Verify the file exists and check its size
In the storage account, confirm that the BACPAC file is present in the container, that its name matches the environment and date in your log, and that its size is in line with the database size reported in the admin center. Download a copy into a controlled location with the same access restrictions as the source. The step is done when the file is stored, its checksum is recorded, and the size and timestamp are added to the migration log. An unexpectedly small file is a reason to stop and investigate before the next step.
Import the BACPAC into SQL Server or Azure SQL Database
Import the BACPAC into a non-production SQL Server or Azure SQL Database instance you control. Keep in mind that the file holds only customer business data, because application data sits in a shared application database, so the import gives you tables, not a running Business Central environment. Microsoft does not support creating a working on-premises Business Central environment from this file. The step is done when the import completes without errors and the database opens for querying.
Compare row counts for key tables with source reports
Select the key tables you will migrate, such as general ledger entries, customers, vendors, items and open documents, and compare their row counts in the imported database with counts from Business Central reports or trusted extracts taken at the same cut-off date. Investigate any difference before extraction continues, and document the cut-off and any transactions posted during the export window. Ask your finance lead to sign off the comparison. The step is done when every key table matches or each difference is explained and accepted in writing.
Loading the BACPAC into SQL Server to extract data for Odoo or ERPNext
Import the BACPAC into SQL Server or Azure SQL Database to create a working copy that you use only to extract data. Treat this copy as an extraction source, not a runnable Business Central instance. Microsoft does not support building a working on-premises Business Central environment from a BACPAC exported from the online service, so do not plan posting, reporting or extension testing against it. Before the restore, confirm the SQL Server version with your migration team, then list the tables and fields you need. The BACPAC holds only the customer's business data, so application objects such as pages, reports and AL extensions must be rebuilt separately on the target platform.
Map each business table to a target object before you export anything. Customers, vendors, items, open items and general ledger entries usually need separate files, and each row should carry a stable key from Business Central, such as the customer or vendor number. Odoo imports Excel (.xlsx) or CSV files into any business object, and its import documentation recommends External IDs when the source is a third-party application. Give every exported record a unique external identifier so that related records, such as invoices pointing to customers, can be linked during import. Write the mapping down as a table of source fields, target fields and identifiers, and have finance sign off on it.
ERPNext Data Import works from downloadable templates for each document type, accepts CSV or Excel files, and supports child table rows, so invoice lines and item rows must be flattened to match the template. Its Data Import documentation advises importing only a few thousand records at a time, so split large ledgers into batches and load master data first. After each batch, compare record counts and totals with the SQL Server copy. The mapping of posting groups, dimensions and the chart of accounts is covered in the sibling migration pages for Odoo and ERPNext, which work through the detailed field-level decisions for each target.
Questions buyers ask before exporting Business Central data
How much effort and cost does a Business Central data export involve?
The export itself is a short administrative step, but the work around it is where effort and cost sit. The main drivers are database size, how many companies and tables you need, the Azure storage setup, the SQL Server or Azure SQL environment that receives the file, and how much cleansing and mapping the target system needs. Export is only one line of the total. Ask any partner for a quote that lists each of these as a separate deliverable, with the data scope written down before work starts. Microsoft's licensing for Business Central itself is separate from this work and is not needed to read a BACPAC file, though the export is only available with a paid subscription, as Microsoft's database export guidance describes.
How long does a Business Central database export take?
An export takes from several minutes to several hours, depending mainly on database size. Larger databases with many years of ledger entries and documents sit at the long end of that range. The export runs in Azure against the storage account you provide, so your own network speed matters less than the size of the database and the storage configuration. Plan the window with your operations team, and confirm the current duration for your tenant with Microsoft and with the partner doing the work. Allow time afterward for importing the file into SQL Server and checking record counts against the live system.
Can our own team run the Business Central export without outside help?
Yes, a capable internal team can run the export if it has the right permissions and the skills to handle the file afterward. The export step requires an administrator with the D365 BACKUP/RESTORE permission set, and Azure access to create a Standard general-purpose v2 storage account and a shared access signature. Loading the BACPAC into SQL Server, extracting tables and mapping them to Odoo or ERPNext is the harder part and needs SQL and data migration experience. Many teams do the export internally and bring in help for extraction, mapping and validation. Either way, every export is logged on the Operations page of the admin center, so the activity is visible to your administrators.
What does our side need to provide for the export and migration?
The work needs several roles from your organization, and naming them early prevents delays. You need a Business Central administrator with the BACKUP/RESTORE permission set, an Azure subscription owner or contributor who can create the storage account and the shared access signature, a SQL Server or Azure SQL administrator to host the restored database, and business data owners for finance, inventory, sales and purchasing who can confirm which companies, periods and records matter. Your security team should also approve where the file is stored and who can read it, because the BACPAC contains customer business data. Agree on these owners and access requests in the written scope before the export is scheduled.
Can we get a fully working on-premises Business Central copy from the BACPAC?
No. Microsoft does not support creating a working on-premises Business Central environment from a BACPAC exported from Business Central online. The file holds only your business data, because application data sits in a shared application database, so it cannot stand in for a running Business Central instance. What you can do is import the BACPAC into Azure SQL Database or SQL Server and query the tables for reporting, reconciliation or extraction into a new system such as Odoo or ERPNext. Treat the restored database as a data source, not as a replacement application, and confirm this limit with Microsoft before you plan around it.
What should a quote for a Business Central export include?
Ask for a written scope that lists the companies and tables in scope, the export and storage steps, the SQL Server environment that will receive the file, the extraction and mapping deliverables for the target system, validation checks such as record counts and balance reconciliation, and the documents you will receive at the end. Ask who does each step, what you must provide, and which items are one-time and which recur. DeployOpen works on fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts, and it does not publish a price list. A quote follows from that written scope, so the more precise the scope, the more precise the quote.
Does the BACPAC contain everything we need for a migration?
The BACPAC holds the business data in your Business Central database, but it is not a complete picture of the system. Customizations written in AL extensions, configuration held outside the tenant data, reports, user permissions and integrations are not replaced by the file. Plan to inventory these separately and confirm with your partner how each maps to the target system. Checking what the export covers against what your processes depend on is an early and necessary step, and it shapes the migration scope more than the export does.
What to plan before the Business Central contract ends
Exporting a Business Central database is a sequence of decisions, not a single button press. The cards below cover the entitlement, the timing, the inventory of what must move, the custody of the export files, the retention terms and the acceptance bar for the target system. Work through them in parallel so that no export is the first time anyone tests the file.
Confirm export entitlement and limit
Only internal and delegated administrators with the D365 BACKUP/RESTORE permission set can export a Business Central online database, and exports require a paid subscription. Microsoft limits exports to 10 per month per environment, so a failed or incomplete attempt uses up part of that allowance. Confirm who holds the permission set now, and confirm it will still apply on the date your contract changes.
Schedule early test exports
A Business Central export can take from several minutes to several hours, depending on database size, and it needs a shared access signature valid for at least 72 hours. Run at least one full test export well before the contract end date. Measure the duration, check the file opens in SQL Server, and record which steps needed manual intervention, so the production export has no surprises.
Inventory extensions and custom reports
The BACPAC holds business data, but not the AL extensions, custom reports, Power BI models or integrations that read from Business Central. Build a list of every extension, report layout, API consumer and scheduled job, with its owner and the business process it supports. This inventory defines the rebuild scope for the target system and shows which data sources the export must still cover.
Keep the BACPAC under your control
The export lands in a Standard general-purpose v2 Azure storage account that you own, so access, encryption keys and network rules are your responsibility. Decide who may read the file, where it will be copied, and how long the storage account stays active after migration. Record the storage account name, the access policy and the key rotation owner before the first export runs.
Confirm retention and deletion terms
Ask Microsoft and your Business Central partner in writing how long exported data and any copies remain in Microsoft systems, and who deletes them once you confirm receipt. Ask whether any backup or support copy of the environment is kept after the subscription ends. The answers determine how long your personal data and financial records persist outside your control, and they should be filed with your data protection records.
Define target acceptance criteria
Before extracting anything, agree the tests that the target system must pass. Typical criteria include matching customer, vendor and item counts, reconciled general ledger balances for each period, open invoice totals, and inventory valuation. Odoo can import from Excel or CSV and recommends External IDs for third-party data, and ERPNext's Data Import tool advises importing a few thousand records at a time, so batch sizes belong in the plan too.
How a self-hosted target changes what the export must deliver
When the destination is self-hosted Odoo or ERPNext, the BACPAC export is the first step of a migration, not the migration itself. The file has to land in your own infrastructure, which means the copy you restore into SQL Server or Azure SQL Database for processing must sit in an environment you control, with access logged and retention set by your policies. Plan the target before you request the export, because the export is logged on the Operations page of the admin center and the shared access signature must stay valid for at least 72 hours while the export runs. Decide which SQL Server instance, which storage location and which people will hold the data at each stage.
The BACPAC holds only the customer's business data, since application data sits in a shared application database. That means your extraction work starts from tables that still reflect Business Central's own structure, including dimensions, posting groups and extension tables. DeployOpen works with your SQL Server, storage and target environment, whether that is Odoo or ERPNext on your cloud account, data center or air-gapped network. Confirm with your team who owns the SQL Server instance, who may query it, and how the restored copy is secured and eventually removed. Ask any implementation partner to state in writing which of these steps falls inside its scope.
The export is only part of scope. A fixed-scope engagement would normally also cover mapping source tables to Odoo or ERPNext objects, reconciling balances and record counts after each load, documenting the extraction, and hardening and backing up the target. Agree in writing what "complete" means for the data, such as which ledgers must reconcile to the penny and which historical records move. Ask for the deliverables and acceptance criteria before work starts, because they determine what the export has to contain and how often you must request it.
How DeployOpen works on this
DeployOpen plans, implements and hands over the export and extraction work for a Business Central exit inside your own infrastructure. We agree the scope in writing before work starts, so the export path, the target platform and the evidence you need are settled before any data moves.
How we scope
- Confirm which Business Central deployment you run, online or on premises, and which environments hold live data.
- Agree who holds the D365 BACKUP/RESTORE permission and who will run each database export.
- Define the Azure storage account, shared access signature handling and retention rules for the BACPAC file in writing.
How we build
- Prepare a Standard general-purpose v2 storage account and confirm the export completes within your monthly export allowance.
- Load the BACPAC into SQL Server or Azure SQL Database and extract ledgers, items and customers into staging tables.
- Map extracted records to CSV or Excel files ready for Odoo or ERPNext import, and test each load on a non-production copy.
How we hand over
- Document the export procedure, the extraction queries and the reconciliation checks, with record counts from source and target.
- Record which data the BACPAC does not hold, such as application-level settings and extensions, and list how each gap is handled.
- Deliver the runbook and access records to your team so the export can be repeated without DeployOpen present.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing are available as a retainer after the migration is complete.
- Ask for a written quote that lists each deliverable and the environments in scope, since no price list is published.
