How a Xero to Odoo migration starts with the data you keep
For a finance team running Xero that wants Odoo Accounting, often alongside sales, purchasing or inventory apps, the move is a data mapping and cutover project. Exporting a file from Xero and loading it into Odoo is one step inside that project. The effort depends mainly on three things: the quality of the data you keep, the number of entities you run, and the integrations that depend on Xero today. This section sets out where to start. The rest of the page covers what maps, the import paths, the sequence with a parallel run, and the effort drivers and risks. No price or duration is stated because none has been supplied for this page. A quote should follow from a written scope that you can review.
Inventory the data before choosing an import path. List what Xero holds that you need after cutover: customers and suppliers, the chart of accounts, tax rates, open sales invoices and bills, items, and the bank accounts whose reconciliations must carry forward. For each dataset, decide whether the history comes across or stays in Xero as a read-only record for audit requests. Look for duplicate contacts, dormant accounts, and tax rates that no longer match the returns you file. Name one owner per dataset and one approver for the opening balances. Those decisions shape everything that follows, and they are easier to make before any file is exported.
Count the entities, currencies and hosting choice early. Confirm how many legal entities, currencies and companies will sit in one Odoo database, because that count affects both design and plan selection. Odoo's pricing page states that multi-company support, Odoo Studio, external API access and custom modules are included only in the Custom plan, and that Odoo.sh and on-premise hosting are also limited to Custom. Confirm which plan and hosting model fit your target setup before the mapping work begins, and ask the implementer to put that choice in the written scope.
Xero to Odoo: what maps cleanly and what does not
This table compares the main Xero objects with their Odoo equivalents and marks each mapping as direct, a decision for the project team, or history that must be recorded as opening entries. Use it to plan which data you migrate, which you rebuild and which you summarize. Confirm each Odoo object name and menu path against the Odoo version your organization will run, because these change between releases.
| Xero object | Odoo equivalent | Mapping type | Migration notes |
|---|---|---|---|
| Contacts | Contacts (customers and vendors) | Direct | Export customers and suppliers with stable IDs. Use External IDs so invoices and payments can link back to them during import. |
| Chart of accounts | Chart of accounts | Decision | Map Xero account codes and types to Odoo account types. Agree on code structure and confirm the account types available in your version before importing. |
| Tax rates | Taxes within the fiscal localization | Decision | Map each Xero tax rate to an Odoo tax with the correct scope and tax accounts. Review the fiscal localization for your country before you rebuild rates. |
| Invoices and bills | Customer invoices and vendor bills | Decision | Import only open items if you are cutting over at a date. Settled history usually becomes opening entries, so agree the cutoff and reconcile totals to the Xero aged reports. |
| Bank transactions | Bank statements and reconciliation | Decision | Confirm which bank feeds or statement imports your Odoo version supports. Unreconciled items must be matched after import, and older transaction history is often not carried over. |
| Items | Products | Direct | Map item codes, sales and purchase prices, and tax defaults to Odoo products. Check whether inventory-tracked items need stock opening quantities as a separate step. |
| Tracking categories | Analytic accounts or analytic plans | Decision | Xero tracking categories do not map one to one. Decide whether each category becomes an analytic plan, an account dimension or a reporting tag, and confirm the menu names in your version. |
| Multi-currency balances | Currencies and currency rates | Decision | Confirm the currencies you need are active in Odoo and decide how historical exchange rates are represented. Open balances in foreign currency need a revaluation check after loading. |
| Reports and history | Opening entries and trial balance | Not carried over | Historical transactions and Xero report layouts are not rebuilt. Record the closing trial balance at cutover as opening entries and keep the Xero exports as an audit archive. |
Which documented import paths move Xero data into Odoo
Odoo gives teams several documented ways to bring Xero data in, and each suits different records. This section sets out the four paths and one decision check that ties them together. Treat them as options to test on a duplicate database, not as a ranking.
Built-in CSV and Excel import
Odoo's import function in list views accepts CSV and Excel files for master data such as contacts and accounts. Use it for records that have few links to other records, and load parent records before the records that reference them. Run a small sample file in a test database first and check how each column maps to a field. Confirm the supported file formats, field names and import behaviour for your target version in the Odoo documentation, because these can change between releases.
External IDs for linked records
Xero exports often reference contacts, invoices and tax rates by name or code, while Odoo links records by internal database ID. External IDs give each imported record a stable identifier, so invoice lines and open items can point to the correct customer, account or tax during import. Assign identifiers in the source file, keep them unique per record type, and load parents before children. Confirm in the documentation for your version how external IDs are referenced in import files and how re-imports treat existing records.
Database duplication with neutralization
Odoo documents database duplication for on-premise deployments, and neutralization is intended for test copies so they do not act on live systems. Use a duplicate to rehearse the Xero load, reconcile the trial balance and open items, and record how long each step takes in your environment. Confirm in the on-premise documentation for your version exactly what neutralization switches off and what stays active on the copy before you rely on it for testing.
Third-party Xero connectors on the Apps Store
The Odoo Apps Store lists third-party connectors that read Xero data and load it into Odoo. A connector can cover records that file imports handle poorly, but it adds a vendor, a licence and a dependency on Xero's API access that you must govern. Review the listed supported Odoo versions, the objects the connector migrates, its handling of tax and currency, and whether a run can be repeated safely. Ask the vendor for references you can verify, and test the connector on a duplicate before any production run.
Choosing the path per data set
Choose the import path for each data set, not once for the whole project. Contacts and the chart of accounts often suit file imports, while open invoices with tax lines and foreign currency balances need closer testing whichever path you pick. Record each decision, the Odoo version tested and the reconciliation checks in the cutover plan. Confirm each import behaviour, format and field name in the documentation for the version you will run, and treat any limit you have not verified as unknown until it is tested.
How tax rates map to the Odoo fiscal localization
The tax mapping is the part of a Xero to Odoo migration most likely to cause a failed return, so settle it before any data is imported. Each Xero tax rate has a rate, a set of components (for example, a sales tax and a surcharge that are reported separately) and a place on the return where its amounts are reported. Each of those has to correspond to a tax configured in the Odoo fiscal localization for the company's country, with the same rate, the same tax computation and the same report line. If a Xero rate that is applied to two different reporting boxes is mapped to one Odoo tax, the period totals will not agree to the return, and the error often only appears at the first filing.
Start by exporting the full list of Xero tax rates, including inactive ones that still carry historical transactions, and listing the reporting box each one feeds in the current return. Compare that list with the taxes the fiscal localization creates in a test database for the same country. Where a Xero rate has no direct equivalent, record the decision explicitly: map it to an existing tax, create a new tax with its own report line, or retire it and remap historical lines. Each choice changes how past periods will read in Odoo, so each needs a written reason. Confirm with the vendor's current localization documentation which taxes a given country version creates by default, rather than assuming the list is complete.
Opening balances go in as a single dated opening entry, dated the day before the cutover date, so that the Odoo ledger starts from the same position as the closing Xero ledger. Trial balance accounts are mapped through the chart of accounts mapping, and the opening entry must balance. Open customer invoices and supplier bills are a separate matter. They should not sit in the opening entry as plain journal lines. They need to be imported as open items against the receivable and payable control accounts, so that customers and suppliers can be allocated and reconciled as they are paid. The total of the open items per control account must equal the balance of that control account in the opening entry. Any difference is a gap to resolve before go-live, not after.
Agree the trial balance at cutover as a formal check. Run the Xero trial balance at the cutover date, run the Odoo trial balance after the opening entry and open items are loaded, and compare them account by account, including tax accounts. Differences in tax accounts are the most common and should be reconciled to the tax report, not written off. The client's accountant or tax adviser should sign off the tax mapping, the treatment of inactive rates and the agreed trial balance before the cutover is approved. The migration partner prepares the mapping, the load and the evidence, but the accountant or tax adviser owns the accounting and tax position the business files under.
Migrate from Xero to Odoo: file imports or an Apps Store connector
Odoo's import tools read files you export from Xero, typically CSV or Excel, and load them into matching Odoo records. You control every step, and no third-party module is installed. This path suits teams with a clean chart of accounts and a manageable volume of contacts, products and open items.
- What it moves: contacts, the chart of accounts, products and opening balances, provided the files match the column layout Odoo expects.
- What it leaves to manual work: mapping Xero tax rates to the Odoo fiscal localization, matching open invoices and bills to their payments, and re-attaching documents.
- Edition and hosting: the import tools run in the database you already have. Confirm which import features your plan and hosting type expose before you export anything.
- History and open items: balances usually arrive as opening entries rather than full transaction history. Agree the cutover date early so the cut-off figures line up.
- What to test: load into a test database first, then compare the trial balance and receivable and payable totals with Xero, line by line.
Confirm with your implementation lead which template your Odoo version expects before you export, because mismatched columns are the most common reason a load is rejected.
A connector is a third-party module from the Odoo Apps Store that links Odoo to Xero through an API and moves records on a schedule or on demand. Because it is installed as a custom module, it adds code, a vendor relationship and an upgrade dependency to your environment. It can save effort when the data set is large or when the team needs to run the load more than once.
- What it moves: this depends on the listing. Check which objects it covers (for example contacts, invoices, payments) and which direction the sync runs.
- What it leaves to manual work: tax mapping still needs review, and draft or deleted records, attachments and any object outside the connector's scope need separate handling.
- Edition and hosting: Odoo's pricing page places custom modules in the Custom plan, which is also the only plan that can run on Odoo.sh or on-premise. Confirm the connector's supported Odoo versions against your target version.
- History and open items: some connectors keep syncing live transactions. Decide which system is the source of record during any parallel period, or you will create duplicates.
- What to test: run repeated loads into a non-production database, confirm the module still works after an Odoo version upgrade, and check behavior after restoring a backup.
A connector saves the most effort when Xero data is large or your team needs repeated test loads, so compare its cost with the file-import hours it replaces.
Both paths need the same decisions about cut-off dates, tax mapping and reconciliation. The difference is who builds and maintains the data movement, and who you depend on when something breaks. Settle these four checks before you commit to either path.
- Listing: read the scope, supported objects, known limitations and recent update history on the connector's Apps Store page.
- Supported Odoo versions: match the connector's stated versions to the version you will run. Odoo 19.0 standard support runs until September 2028, so plan your target version against that window.
- Vendor support terms: ask what response the vendor commits to, whether upgrades are included, and who supports the module after go-live.
- Data handling: ask where Xero credentials are stored, whether any copy of your data leaves your infrastructure, and how the vendor handles it.
- Repeatability: confirm that a test load can be rerun cleanly without leaving duplicate records.
Ask the vendor these questions in writing and keep the answers with your migration plan.
The sequence for a Xero to Odoo cutover with a parallel run
This sequence moves master data, opening balances and open items from Xero into Odoo in an order that can be reconciled at each stage, then runs both systems side by side before Xero access is closed. The output is a set of signed-off reconciliations and a dated cutover that the business can rely on.
Inventory Xero data and integrations
List every Xero data set in scope: contacts, chart of accounts, tax rates, products, bank feeds, open invoices and bills, fixed assets and reports the business relies on. Record every app or connector that reads from or writes to Xero, along with the process it supports, since each one needs a replacement or a retirement decision. Who does it: DeployOpen with your finance lead and accountant. Done when the inventory is agreed in writing and every data set has an owner and a target location in Odoo.
Decide chart of accounts and tax mapping
Map each Xero account and tax rate to an Odoo account and to the tax configuration of the Odoo fiscal localization that applies to your jurisdiction. Resolve duplicates, retired accounts and accounts that combine several purposes before any data is loaded, because later corrections are harder to trace. Who does it: your accountant approves the mapping, and DeployOpen prepares the draft. Done when the accountant has signed off the mapping document.
Load master data in dependency order
Import records in an order that respects their references: accounts and taxes first, then contacts, then products, then any other records that point to them. Use External IDs so that related records can be linked during later imports without manual matching. Who does it: DeployOpen runs the imports in a test database, and your team checks samples from each import. Done when record counts and sample checks match the Xero exports for every master data set.
Build a test database and load opening balances
Create a test database from the same Odoo version intended for production and load the trial balance as opening entries as of the agreed cut date. Load open customer invoices and vendor bills as opening items so that they can be settled in Odoo after cutover. Who does it: DeployOpen builds and loads the test database. Done when the opening entries post without errors and the balances are visible by account.
Reconcile the trial balance and open items
Compare the Odoo trial balance and each open item listing against the Xero reports for the same date, account by account and contact by contact. Investigate and document every difference before accepting it, including rounding and tax differences. Who does it: DeployOpen prepares the reconciliation, and your accountant signs off each one. Done when every reconciliation is signed off and no unexplained differences remain.
Run both systems in parallel
Keep Xero live for the agreed period while transactions are entered in Odoo, and compare outputs such as invoices, payments, bank reconciliation and tax returns between the two. Record each difference, its cause and its fix in a shared log. Who does it: your finance team enters the transactions, and DeployOpen supports the comparison. The length of the parallel run and the cutover date are agreed in the written scope. Done when the comparison log shows the agreed checks passing for the full period.
Cut over to Odoo
Load the final data set into the production Odoo database as of the cut date, repeating the imports and opening entries from the tested process rather than improvising them. Confirm that bank feeds, users and integrations point to Odoo. Who does it: DeployOpen runs the cutover with your team present. Done when the production trial balance matches the signed-off reconciliation and users confirm they can post and report.
Decommission Xero access
Once the production data is confirmed, move Xero to read-only for historical reference, export the reports and documents your retention policy requires, and remove connected apps and API credentials. Who does it: your administrator, with DeployOpen providing the checklist. Done when Xero write access is removed, exports are stored under your retention policy and the decommission checklist is signed off.
What drives the cost and duration of a Xero to Odoo move
This table lists the factors that change effort and duration in a Xero to Odoo move, the direction each one pushes, and how to keep it down. Read it before requesting a quote, and ask for each driver as a separate line item with its own assumptions. Data quality, tax setup and the testing capacity your own team can offer usually cause the largest swings, so settle those first.
| Driver | Effort direction | How to keep it down |
|---|---|---|
| Number of Xero organizations or entities | Up with each entity moved | Confirm which entities move and which stay in Xero |
| Chart of accounts complexity | Up with account count and custom reporting codes | Remove unused accounts and agree the mapping before loading |
| Tax rates and multi-currency use | Up with each tax rate, foreign currency and rounding rule | Map tax rates to the Odoo fiscal localization early, with your accountant |
| Open invoices and bills | Up with the number of open items to recreate | Close old items in Xero or agree to carry only balances |
| Contact and item data quality | Up with duplicates, missing fields and inconsistent codes | Clean contacts and items in Xero before export |
| Bank feeds and integrations | Up with each bank feed, payment provider and connected app | List every feed and connector, then decide which Odoo replaces |
| Custom reports or modules | Up with each report or module beyond standard apps | Confirm custom modules are included in your Odoo plan with Odoo |
| Parallel run length and internal testing capacity | Longer parallel runs and fewer testers both extend the schedule | Name testers, agree test cycles and sign-off criteria in writing |
| Odoo edition and hosting | Enterprise, Odoo.sh or on-premise add subscription and hosting work | Ask which edition and plan each quote assumes before comparing |
What usually goes wrong in a Xero to Odoo migration and how to prevent it
Most failures in this migration appear in three places: the data loaded from Xero, the moment the old system is switched off, and the Odoo version the new system runs on. Each card names one failure, why it happens, and the check that catches it before users rely on the new database. Most of these are far cheaper to prevent in a test database than to correct after go-live.
Tax returns that do not reconcile
Xero tax rates do not always map one to one onto the taxes and tax groups in the Odoo fiscal localization, so the first tax return filed from Odoo can differ from the last one filed from Xero. Map every Xero tax rate to an Odoo tax before loading transactions, and confirm which accounts each tax posts to. Run the final Xero tax report for the last period, then compare it with an Odoo report for the same dates before go-live.
Duplicate contacts from repeated test loads
Each test import that creates customers and vendors without a stable external reference adds another copy of the same contact. Those copies then receive invoices and payments, and the duplicates carry into production. Store the Xero contact identifier as an External ID on every contact, and load into a fresh test database for each run. Before go-live, search for duplicate names and tax numbers, and confirm that only the final load reaches production.
Opening balances and open items
Opening entries must agree with the Xero trial balance at the cutover date, account by account. Open invoices and bills must also agree with the aged receivables and payables reports. Open items loaded without their payments or allocations appear unpaid in Odoo, which distorts ageing and bank reconciliation. Load the trial balance first and reconcile totals to Xero, then load open items with their payment history, and compare each aged report with Xero before users start work.
Bank feeds left connected to Xero
If a bank feed stays connected to Xero after cutover, new transactions keep arriving in the old system and Odoo never sees them. Two systems importing the same bank account also create duplicate statement lines. Set a cutover date, complete the final reconciliation in Xero, then disconnect the feeds there. Connect each bank account in Odoo from the first day after that point, and confirm with the bank statements that there is neither a gap nor an overlap.
Lost history for audit purposes
Historic transactions, attachments and reports may become harder to reach once the Xero subscription ends, yet auditors still request them. Before cutover, export the general ledger, journals, invoices, bills, supporting documents and prior-year reports. Store them in an archive your organization controls, with an index that maps each file to its period. Confirm with your auditors which periods and evidence they need, and confirm with Xero what remains accessible after cancellation.
Go-live on an unsupported version
Odoo 17.0 reached the end of standard support in September 2026, and security patches are provided only during standard support. Odoo 18.0 is supported until September 2027, Odoo 19.0 until September 2028 and Odoo 20.0 until September 2029. Confirm the support end date for the chosen version in Odoo's documentation at the start of the project. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years, so plan that upgrade from the outset.
Which Odoo edition, hosting and version to migrate onto
The first decision is which edition and hosting type your Odoo database will run on, because that choice limits which connectors and customizations are possible after the migration. Community is the fully open source edition, licensed under LGPL-3.0 and published on GitHub. Enterprise adds features and support, but its source code is not public, so you need a subscription or partner access to obtain it. Odoo's pricing page lists three plans: One App Free, Standard and Custom. One App Free and Standard run only on Odoo Online. Custom is the only plan that can run on Odoo.sh or on-premise, and it is the only plan that includes multi-company, Odoo Studio, external API access and custom modules. If your Xero files span several legal entities or you expect to call the API, check these requirements before you choose a plan. Confirm current plan contents on the pricing page, because plans change.
Edition and plan also determine how far the Xero migration can go beyond file imports. A third-party connector from the Odoo Apps Store, or a custom module you commission, usually depends on the features and access described above. Before you shortlist a connector, confirm which Odoo versions it supports, whether it needs an Enterprise-only feature, and whether it calls the external API, which only the Custom plan provides. Ask the vendor to show how the connector handles a re-run, since a connector that loads correctly once can create duplicate contacts or invoices on a second sync. If you plan to run Community, the connector list narrows and your team carries more of the integration work. Write these answers into the project scope before you commit to a hosting type.
Choose the version by its support window, not only by the newest release. Odoo 20.0 was released in September 2026, with standard support planned until September 2029. Odoo 19.0, released in September 2025, has standard support until September 2028. Odoo 18.0, released in October 2024, has standard support until September 2027. Standard support for Odoo 17.0 ended in September 2026, so do not go live on it. Standard support covers the first three years after a major release on Odoo Online, Odoo.sh and on-premise, and includes security updates and bug fixes. Security patches are provided only during standard support, so a go-live on a version past that window carries exposure even where paid extended support exists. Count back from the end date of the version you pick to set your cutover window.
Two more facts shape the version decision. Odoo SaaS versions are released every two to three months and cannot use extended support, so a database on Odoo Online moves forward on Odoo's schedule. On Odoo Online and Odoo.sh, major version upgrades are mandatory every two years. On-premise use requires an Enterprise subscription for the Odoo upgrade service, and the Community edition has no access to it, so a Community upgrade path must be planned separately. Ask Odoo or your implementation partner to confirm the upgrade route, the test database steps and the dates for the version you select. Record the chosen version, its standard support end date and the next upgrade date in the project plan, so the migration does not start on a release that will need an upgrade soon after go-live.
Questions buyers ask before migrating from Xero to Odoo
How much does it cost to move from Xero to Odoo?
Cost follows the scope you agree in writing, so no single figure applies to every business. The main drivers are the number of companies and legal entities, how complex the chart of accounts and tax mapping are, how clean your contacts, products and open invoices and bills are, how many years of history you bring over, and how many integrations (bank feeds, payment providers, connectors) you need. The migration work is a one-time cost. Odoo subscriptions are recurring and priced per user, and the plan you need depends on the hosting type and the apps you use, so confirm current pricing with Odoo. DeployOpen issues a quote after the scope is written. Ask for the quote to list discovery, mapping, test loads, cutover, training and post-go-live support as separate lines.
How long does a Xero to Odoo migration take?
Duration depends on three things: how many entities you move, how good your data is, and how long you run Xero and Odoo in parallel before switching off Xero. Entities with clean, reconciled books move faster than businesses with years of unmatched transactions or many duplicate contacts. A longer parallel run adds time but gives your accountant more evidence that balances agree. No standard duration applies to every business. Ask for a timeline in the written scope that shows the test loads, the reconciliation rounds, the parallel run length and the cutover date, and that names who signs off each stage.
Can our finance team move from Xero to Odoo without a partner?
Yes, for a simple single-entity business with clean data, a modest number of open items and a single currency, provided someone on the team is comfortable with Odoo's import tools and reconciliation. Your accountant should sign off the opening balances and the trial balance comparison before go-live. Work becomes harder with several entities, multi-currency ledgers, complex tax treatments, custom reports or several integrations feeding the ledger. In those cases a partner's cost is usually lower than the cost of correcting a flawed opening position after the first month of trading. Decide early which group you are in.
What does our team need to provide for a Xero to Odoo migration?
The migration needs access and decisions more than it needs software. Access: an administrator or accountant login to Xero that can export contacts, accounts, invoices, bills and the trial balance. People: a named accounting owner who can answer questions quickly and approve mappings. Time: staff hours for test reviews and reconciliation checks during each test load. Decisions: how Xero accounts map to the Odoo chart of accounts, how Xero tax rates map to Odoo's fiscal localization, and which open items carry forward. Ask your provider to list each item in the scope so nothing surfaces as a surprise at cutover.
Does a Xero connector remove the need for file imports?
A third-party Xero connector from the Odoo Apps Store can reduce manual loading for some data types, but it does not remove the need for checking. Before you rely on one, confirm in its listing which objects it syncs (contacts, accounts, invoices, bills, payments, journal entries), whether it brings over opening balances and history, how it handles tax and currency, and who supports it after installation. DeployOpen is not a partner or reseller of Xero or of any connector vendor. Compare the connector's coverage against your scope, then decide whether file imports remain necessary for the remaining data.
What happens to our Xero history after moving to Odoo?
Your Xero history can be kept in Xero, archived as exported reports and files, or both. It is not guaranteed to appear in Odoo as individual transactions. Most migrations carry forward opening balances and open items so that Odoo starts from a correct position, while older detail stays in the archive. Confirm with Xero what access remains after you change or cancel your subscription, and agree with your accountant and auditors which records they need to see and in what format. Write the archive decision into the scope before the first test load so retention is planned, not improvised.
Which Xero tax rates need mapping to Odoo?
Every Xero tax rate in use needs a matching tax in Odoo's fiscal localization for your country, or a deliberate decision to retire it. Check the rate, the tax type, whether it applies to sales, purchases or both, how it is reported on your returns, and any reverse charge or exempt treatment. Confirm rates that changed during your history and which periods they apply to. Tax mapping errors often show up later in filed returns, so have your tax adviser approve the mapping table before test loads begin, and reconcile tax control accounts against the last filed return as part of the parallel run.
How DeployOpen works on this
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Xero to Odoo migration, the work starts with a written scope that fixes what moves, how it is mapped and how it is tested before any production data is loaded.
How we scope
- The written scope lists which Xero contacts, accounts, open invoices and bills, and opening balances move into Odoo.
- Tax rates are mapped to the Odoo fiscal localization for your country before any transaction data is loaded.
- Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before the migration starts.
How we build
- Exports from Xero are cleaned and reviewed against the chart of accounts agreed for the Odoo database.
- Master data is loaded in dependency order, with External IDs set so related records link correctly on import.
- Opening balances are loaded and reconciled against the Xero trial balance in a test database before any cutover.
How we hand over
- You receive the mapping workbook, import logs, reconciliation results and a record of every decision on tax and account mapping.
- Runbooks describe the cutover sequence, the freeze on Xero entries and the checks completed before users switch over.
- Your team receives documentation for the Odoo configuration built during the migration so future changes can be traced.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the migration is complete.
- Post-cutover support covers reconciliation questions, corrections to opening entries and reports that differ from Xero.
- Upgrade planning follows Odoo's documented support windows, so the platform version is reviewed on a schedule you can confirm.

