How to export your data from Acumatica before the renewal notice deadline
A finance or IT leader who needs a full copy of Acumatica data before the contract changes should plan two extraction paths. Acumatica provides a backup copy of the database as a SQL Server database, and API-based extraction covers the data that the copy does not give you in usable form, such as records that must be reshaped for another system. Keep the backup as the record for audit and recovery, and use the API as the working source for loading a new platform. Before you rely on either, confirm in writing with Acumatica which data the backup includes, how it is delivered, who can request it, and whether attachments, customizations and audit history are part of it.
The renewal notice deadline sets the schedule, and the subscription lapse terms set the risk. Confirm in your contract and with Acumatica how long your data stays available after a subscription lapses, what happens to it at the end of that period, and whether a late request for a copy is possible. Do not work from memory or from a sales summary. Once the dates are fixed, work backward: request the backup first, restore it to a SQL Server instance you control, and check that it opens and that record counts match the source. Then run API extracts for masters, open transactions and balances, and reconcile each set. Schedule at least one full dry run before the notice date so a failed extract still leaves time to request another copy.
Plan the extract around the import method of the target system. ERPNext's Data Import tool loads CSV or Excel files built from downloadable templates, and its ERPNext Data Import documentation advises importing only a few thousand records at a time, so export each entity into separate files that can be split into batches. Odoo imports Excel (.xlsx) and CSV files into any business object and recommends External IDs when data comes from a third-party application, so keep the Acumatica record keys in a dedicated column from the first extract. Log each run with its date, row count and control totals, and have finance sign off on that log. The log becomes the evidence that balances on the new system match the old ones at cutover.
Which Acumatica data you can export and by which path
This table compares the main ways to get Acumatica data out: the full backup copy, API extraction of master data and transactions, report and list exports, and attachments and customizations. Read each row as a list of questions for Acumatica, because the exact formats, sizes, frequencies and entity coverage must be confirmed in writing before the renewal notice deadline.
| Data type | Export path | Format | Limits to confirm |
|---|---|---|---|
| Full company data | Backup copy delivered as a SQL Server database | SQL Server database | Delivery frequency, file size, retention period and how to request a copy outside renewal |
| Master data (customers, vendors, items, accounts) | API-based extraction | Structured records returned by the API | Which entities the API exposes, paging behavior and any request limits |
| Open and posted transactions | API-based extraction | Structured records returned by the API | Which document types are exposed, history depth and whether closed periods are included |
| Reports and list exports | Report or list output available in your edition | Depends on edition and report design | Which exports your edition offers, file formats and whether output covers full history |
| Attachments and customizations | Backup copy or API, to be confirmed | Files as stored, plus customization code and scripts | Whether attachments are included in either path and how customization code is handed over |
What does not export cleanly and how to work around it
Much of what teams lose during an exit is not stored as table rows. Customizations, settings, connector credentials, audit logs and attached files sit in other layers of the application, and each needs a named owner before the extract starts. Treat them as separate work items in the plan rather than as leftovers from the data load.
Custom code and customizations
Custom screens, extension code and business logic built on Acumatica are part of the application layer, not the rows in a database backup. A restored copy holds the data those customizations wrote, but not a runnable version of the logic that produced it. Inventory every customization with its owner and purpose, then decide per item whether to rebuild it as an Odoo module or ERPNext feature, or to retire it. Ask Acumatica which source artifacts your subscription lets you keep and how to export them.
Configuration and workflow rules
Numbering sequences, approval routes, posting rules, document states and screen layouts are settings that control how records behave. They are easy to miss because they are not business data, yet every migrated record depends on them. Write each rule as a decision table with its trigger, owner and exception path before building anything in the target. Confirm with Acumatica which configuration tables appear in the database copy and which exist only in the administration interface.
Integrations and stored credentials
Connectors to banks, tax engines, e-commerce sites, warehouse systems and reporting tools hold endpoints, field mappings and service credentials. Secrets should not travel in an export file. List each integration with its direction, frequency, data objects and system owner, then issue new credentials in the target from a managed secrets store. Ask Acumatica how API users, tokens and integration settings appear in the backup and whether any values are encrypted in a way that needs separate handling.
Audit and change history
Auditors often ask who changed a price, reversed a posting or released a batch, and when. Full change history rarely maps one to one onto the history model of a new ERP, so most teams keep it as a read-only archive alongside the migrated data. Decide which audit trails your regulator or internal audit requires, extract them with timestamps and user identifiers, and store them with the backup. Confirm with Acumatica which audit tables the backup includes and how long they are retained.
Attachments and linked documents
Contracts, signed purchase orders, certificates and scanned invoices are often stored as files that a record points to. An export of records can arrive without those files, leaving open invoices with no supporting document. Map each attachment to its parent record identifier, copy the files into your own object store, and keep the link as a reference in the target. Confirm where attachment files live and whether they sit inside the SQL Server backup or in a separate file store, and how to export them in bulk.
Restoring the backup outside Acumatica
A SQL Server backup is a copy of a database, not a working Acumatica environment. Restoring it lets your team query history and reconcile balances, but its structure reflects Acumatica's application logic, so it needs mapping before any data reaches Odoo or ERPNext. Treat the restored copy as a reference source for reporting and checks, and run the migration through the API or a controlled extract. Confirm with Acumatica which SQL Server version the backup requires and what license terms apply to restoring it elsewhere.
Choosing between the database copy, API extraction or both
This path fits a team that needs a complete reference of how the business ran, including closed periods, archived documents and audit history. The database copy that Acumatica provides is a SQL Server database, so the full record arrives in one place. It is not a running Acumatica instance, and application logic, screen configuration and customization code stay outside it. Someone who can restore and query SQL Server, and who can map tables back to the business objects the team knows, must own this work.
- Complete history. The copy holds the transactional record for the period it covers, which suits audits and long-term reference.
- No running application. Reports, workflows and customizations do not run from the copy, so each report needs to be rebuilt or queried directly.
- Schema interpretation. Table and column names reflect the vendor's design, so a data dictionary is needed before anyone trusts a query.
- Restore environment. You need an isolated SQL Server host, storage sized for the database, and access controls that match the data's classification.
- Retention decisions. The team must decide how long the copy is kept, who can read it and how it is destroyed.
Before relying on this path, ask Acumatica in writing which backup format, frequency and delivery method your subscription includes.
This path fits a team moving to Odoo or ERPNext that needs clean master data and open transactions, not every historical record. Extraction runs through Acumatica's API, and the output is shaped for the target system's import tools. The team gets current customers, vendors, items, warehouses and open documents, but it must do the mapping work between two data models. Expect the largest effort to sit in chart of accounts decisions, unit of measure conversions and deciding which closed history is migrated at all.
- Current masters. Customers, suppliers, items and locations are extracted in the form the target needs.
- Open documents and balances. Open orders, invoices and inventory quantities can be loaded so work continues on day one.
- Mapping workload. Each Acumatica entity needs a target object, and identifiers need a consistent approach.
- Batch loading. ERPNext's Data Import documentation advises importing only a few thousand records at a time, so large sets are split into batches. Odoo's import documentation recommends External IDs when importing from a third-party application, which keeps links traceable.
- Reconciliation. Totals, balances and record counts are compared before the cutover is signed off.
Confirm with your implementation partner who owns the mapping specification and the reconciliation sign-off.
This path fits a team whose subscription or access will change before the migration is ready, so the priority is a secure, complete capture now. Start with the database copy and a full inventory of what the subscription provides, then add API extraction for anything the copy does not hold in usable form. The main risk is assuming access will remain after a change in subscription status. Confirm the suspension and deletion terms in the contract before planning anything else, and set internal dates that come well before any notice deadline.
- Written terms first. Get the suspension window, deletion timing and renewal notice deadline confirmed by Acumatica in writing.
- Fixed snapshot date. Freeze one cut-off date so the database copy and API pulls describe the same point in time.
- Verified restore. Restore the copy to an isolated environment and run a sample of reports to prove it is usable.
- Secure storage. Store extracts encrypted, with access logged and a named owner.
- Gap list. Record anything that cannot be captured in time so it can be recovered later through a documented exception.
Before the snapshot date, ask Acumatica what it will still provide after a subscription change and document the answer.
The export sequence and the checks at each step
This sequence turns Acumatica's database copy and an API extract into a verified, signed baseline that the migration team can rely on. Each step names the check that proves it finished and the person accountable for it. Nothing loads into a target system until the final sign-off is complete.
Confirm entitlements and export options in writing
Before anything is requested, ask Acumatica to confirm in writing which data copies your subscription includes, the format and delivery method, who on your side may request them, and whether any fee applies. Also confirm how the 30-day suspension window after a lapsed subscription applies to your agreement, since that window sets how long you have to extract. Owner: the executive sponsor, with the contract owner in finance. Done when the written confirmation is filed with the project records and every open question is closed.
Request or generate the database copy
The IT administrator requests or generates the database backup that Acumatica provides, delivered as a SQL Server database. Record the request date, the company or tenant identifier, the Acumatica version in use, and the file size. Restore the copy on an isolated SQL Server instance that no business user can reach, then confirm the database opens and core tables are populated. Done when the restore succeeds and the restore log is saved.
Secure and checksum the copy
The security lead moves the backup into encrypted storage with restricted access, then records a cryptographic hash of the file (SHA-256 is a common choice) and stores that hash separately from the file. From this point, access to the copy is logged so the team can show who handled it and when. Recompute the hash after every transfer to confirm the file has not changed. Done when the hash matches at every copy and the custody log names each handler with dates.
Run API extraction for masters and open documents
The integration engineer uses Acumatica's API to pull the entities the migration needs, such as customers, vendors, items, warehouses, the chart of accounts, and open sales and purchase documents. Confirm entity names, endpoints and any request limits for your version against the vendor documentation before running the extraction. Save each entity to a dated file, log pages retrieved and errors, and record a row count per entity. Done when every entity has a count and a log, and every failed page has been retried and resolved.
Load both sources into a controlled staging area
The database administrator loads the API extracts into a staging schema beside the restored backup, keeping production systems out of this step. Tag every staged table with its source and extract timestamp so each figure traces back to where it came from. Limit write access to the migration team and freeze the staging schema before reconciliation begins. Done when both sources sit side by side in staging and the schema freeze is recorded in the project log.
Reconcile counts, control totals and sample records
The finance controller and implementation lead compare the backup with the API extract entity by entity. Check record counts first, then control totals such as open receivables and payables, inventory quantities and value by warehouse, and the general ledger trial balance by period. Select a sample of customers, items and open orders and compare each one with its record on the Acumatica screen. Log every variance with an owner and a resolution. Done when all variances are explained or corrected and the reconciliation workbook is complete.
Sign off the extract as the migration baseline
The business owner and finance controller review the reconciliation report and sign the extract version as the approved baseline. The signed record names the extract version, its hash, the counts, the control totals, and any variances accepted with reasons. Retain the backup, the API logs and the signed report under your retention policy, because every later load will be traced to this baseline. Done when the signed report is filed and the baseline is locked for the migration.
How to verify an Acumatica extract before anyone relies on it
An export that runs without errors proves very little. The extract is only useful once finance and the system owner can show that it matches Acumatica at a fixed point in time, and that the gaps they accept are small, known and written down. Verification is the stage where a silent truncation, a dropped child row or a mis-mapped currency becomes visible, so plan it as a deliverable in its own right rather than a step at the end of the export. Start by agreeing the cut-off date and the tolerances before anyone runs a query. Pick a single as-of date for the source, freeze or note the transactions posted after it, and have the finance lead and the system owner sign off on what counts as an acceptable difference for each check, for example zero tolerance on the trial balance by account and period and a stated, documented tolerance on rounding in open receivables or payables. Then reconcile by entity: record counts and control totals for customers, vendors, items, open sales and purchase documents, and general ledger balances, comparing the source against the restored copy or the API extract. Where the export came from the SQL Server backup, confirm the database version and restore log before trusting any figure derived from it.
Totals alone can hide errors that offset each other, so sample records across branches, companies and periods. Choose a set that includes older closed periods, the most recent month, and every branch or legal entity, then trace each sampled document through its header, lines, taxes, payments and applied credits. Check that open receivables and payables aging matches the source at the cut-off, and that each trial balance by company agrees before any dimension mapping is applied. Record every exception, its cause and the fix, and re-run the affected reconciliation. Keep a dated, signed record of the whole process: the extract method and version, the cut-off timestamp, the reconciliation queries, the tolerances, the sample list, each exception and its resolution, and the names of the people who accepted the result. This record is what auditors and later users will ask for, and it should be stored outside the system being retired. Confirm with your auditors and your Acumatica administrator which evidence they expect, since DeployOpen prepares this evidence but does not issue audit opinions on it.
What to plan before the Acumatica contract renewal or termination
The export depends on dates that Acumatica controls and your contract sets, not on the migration itself. Each item below names a decision or a document you need, and who holds it, so the copy and API access are secured before the notice period closes.
Renewal notice deadline and owner
Find the last day on which you can give notice of non-renewal, and name one person who owns that date. Take the exact notice period and the method of notice from your signed subscription agreement and order form, not from memory or a sales summary. Ask your Acumatica account contact to confirm the date in writing, and put it in your finance and IT calendars with a reminder well ahead of it. Missing this date usually means another billing term, so treat it as the first item on the plan.
Suspension window after lapse
Confirm how long your data stays available after a subscription lapses and before deletion. Take the length of the suspension window from the contract and written vendor correspondence, and ask Acumatica what access you keep during it, such as read-only login or export rights. Ask whether the window starts at expiry, at the end of a grace period or at a notice date. Plan the export to finish inside this window with a margin, since a lapse can end your access to the live system before you have the files.
Database copy and API access in writing
Request the SQL Server database copy and the API access you need as a written item before the notice deadline, and record the agreed delivery format and date. Ask Acumatica whether the backup is delivered as a SQL Server database, what customizations and data it includes, and whether it is provided at no extra cost under your current terms. Confirm which API endpoints and credentials you will receive, and whether any tier or application limits affect extraction volume.
Retention and deletion terms
Read the data retention and deletion clauses in your agreement, including what Acumatica deletes, when, and whether backups of your tenant are kept after deletion. Ask for written confirmation of the deletion date and how you will receive a certificate or notice that your data was removed. Your privacy and compliance team should check whether this matches your own retention obligations, because you may need to keep certain financial records for longer than the vendor does.
Freeze date for transactions
Choose a cutoff after which no new transactions, adjustments or period closes are entered in Acumatica, and tell the finance, sales and warehouse teams in advance. Set it with enough time to run the final extract, reconcile balances and load open documents into the target system. Confirm with your controller which period is closed, which open orders and invoices carry over, and how inventory counts are reconciled on the freeze date. Without a fixed cutoff, the extract and the reconciliation will never match.
Extract ownership and sign-off
Assign who runs the extract, who checks record counts and balances, and who accepts the output. Usually this is an IT lead for access and file handling, a finance lead for ledgers and open items, and an operations lead for item and warehouse data. Agree on the sign-off criteria in writing before the extract begins. Ask your implementation partner for the scope of this work in a fixed-scope statement of work, so responsibilities for extraction, validation and storage of the export files are clear before the deadline arrives.
Questions teams ask before exporting Acumatica data
How much effort does an Acumatica data export take?
Effort depends mainly on the volume and shape of your data. The main drivers are the number of entities you move (customers, vendors, items, warehouses, chart of accounts), how many years of transaction history you keep, how many companies and branches sit in one database, and how much customization adds fields, screens or logic to the standard data model. A single-company database with standard entities and two years of history is a small job. A multi-company database with heavy customization and a decade of history needs far more mapping, validation and reconciliation. Ask the provider to list entities and record counts in the written scope before agreeing on the work.
Can our own team export Acumatica data without outside help?
Yes, a team with SQL Server and API skills can extract standard entities without outside help. An internal developer can work from the SQL Server backup copy or the API and produce flat files for the most common masters. The harder parts are reconciling balances, handling custom fields, deciding which history to keep and proving that totals match after the load. Teams often underestimate the reconciliation work. If internal staff are committed to other projects, consider a fixed-scope engagement for the mapping and validation steps. DeployOpen plans and implements these extractions inside your own environment, with scope and deliverables agreed in writing before work starts.
What does an Acumatica export need from finance and IT?
The export needs decisions from finance and access from IT, and both must be named before work starts. Finance should:
- Approve the chart of accounts and the cutoff date for transactions
- Confirm which open documents and balances carry over
- Sign off on the reconciliation reports that prove totals match
IT should:
- Provide access to the SQL Server backup copy or the API credentials
- Set up a secure location for extracts with restricted access
- Prepare a test environment for the target ERP, either Odoo or ERPNext
Both teams should agree who decides exceptions, because unresolved exceptions are the most common cause of delayed sign-off.
How long does an Acumatica export project take?
No single duration fits every export, so request a timeline built from your written scope. The main factors are the entity count, the condition of the source data, the amount of customization, the number of test extracts and reconciliation cycles, and how quickly finance can review results. Work back from the renewal notice deadline in your Acumatica agreement, and confirm that date with Acumatica in writing. The notice period sets the latest point at which you can decide not to renew, so plan a test extract, a validated trial load and a final cutover extract before that date. Ask any provider to show the milestones and the decisions each one depends on.
Can the Acumatica SQL Server backup load straight into Odoo or ERPNext?
No, the backup cannot load directly into either system. The backup is a SQL Server database that uses Acumatica's schema, while Odoo runs on PostgreSQL and ERPNext runs on MariaDB or PostgreSQL. Each entity must be mapped to the target data model and exported as flat files. Odoo can import data into business objects from Excel or CSV files and recommends External IDs when importing from a third-party application, which helps keep relationships intact. The ERPNext Data Import tool loads CSV or Excel files with downloadable templates, and its documentation advises importing a few thousand records at a time. Plan batches and validate each one before loading the next.
What should we do if our Acumatica subscription has already lapsed?
Act immediately and confirm the status in writing. Acumatica's suspension window after a lapsed subscription is 30 days before deletion, but confirm the exact dates with Acumatica and check your agreement, because the terms decide what applies to you. Request your data copy while the account is still accessible. Once you have the copy, extract the entities in priority order: customers, vendors, items, chart of accounts and open documents first, then history. Store the extracts and the source backup in a secured location with a record of checksums. Legal and finance should confirm which retention obligations apply before any data is moved or deleted.
What belongs in a written scope for an Acumatica export?
A written scope should name every entity to extract, the source (the SQL Server backup copy, API extraction or both), the target ERP, and the cutoff date for transactions. It should state which history is kept and which is archived, the reconciliation checks that prove balances match, and who signs off each stage. Ask for deliverables in writing: extract files, mapping documents, validation reports and a rollback plan. List what is excluded, such as customization in the target system or user training, so no one assumes it is included. Most DeployOpen engagements are fixed-scope, and scope, deliverables and timelines are agreed in writing before work starts.
Loading the extract into Odoo or ERPNext
The extract is only the first half of the move. Pulling data out of Acumatica gives you files or a database copy, but nothing is usable in the new system until those records are mapped, loaded in the right order and reconciled. Both candidate platforms accept spreadsheet-based loads, so the work is less about tooling and more about preparing clean, staged input. Odoo can import data into any business object from Excel (.xlsx) or CSV files, and its documentation recommends using External IDs when the source is a third-party application. Those External IDs give each Acumatica record a stable reference, so later corrections and re-imports update existing records instead of creating duplicates. ERPNext's Data Import tool works the same way in principle. It imports and updates records from CSV or Excel files using downloadable templates and supports child table rows, which matters for sales orders, purchase orders and journal entries that carry line items. The ERPNext documentation advises importing only a few thousand records at a time, so a large item master or customer list should be split into batches. Confirm the current batch guidance and template fields for your ERPNext version before you build the files, because the templates change with each release.
Load master data before transactions, and reconcile after every batch. Customers, vendors, items, warehouses, chart of accounts and branches or companies have to exist before open orders, invoices or stock balances can reference them. Plan the load in dependency order, and keep each batch small enough that a failed row is easy to find and fix. After each load, compare record counts and control totals against the Acumatica extract: customer balances, open AR and AP totals, item quantities by warehouse and general ledger balances by period. A mismatch found after one batch is cheap to correct, while the same mismatch found after go-live is not. Agree in writing with your implementation partner who signs off each reconciliation, and keep the reconciliation workbooks as part of the cutover record.
How DeployOpen works on this
DeployOpen treats an Acumatica data exit as a fixed-scope engagement: the extract, the target platform and the validation evidence are agreed in writing before work starts. We plan the export inside your own infrastructure, so the data stays under your control from the first backup copy to the final reconciliation.
How we scope
- Inventory the Acumatica applications, customizations and integrations that hold data you need to keep
- Confirm which backup copy, API endpoints or exports will feed the extract, and who holds access to each
- Agree in writing the deliverables, timelines and renewal notice dates that shape the cutover plan
How we build
- Restore the SQL Server backup copy in a controlled environment and map its tables to the target entities
- Script API-based extraction for records the backup does not cover, with logs of every batch exported
- Test imports on a copy of the target platform and reconcile record counts and balances before each run
How we hand over
- Document the extract scripts, mapping tables, reconciliation reports and known gaps for your team
- Walk your finance and operations staff through the validation evidence before the source is retired
- Store the export archive in your own storage so it remains available after the subscription ends
How we support
- Offer ongoing support, upgrades and testing as a retainer after the handover is complete
- Re-run the extract scripts against refreshed backup copies if the cutover date moves
- Confirm with your team which records must be retained under your own retention policy
