# How to implement Odoo in a mid-sized company: phases, data migration, cut-off, go-live and adoption > An Odoo implementation in a mid-sized company runs through six phases: process and gap analysis, configuration, testing with real data, data migration, cut-off and go-live, and stabilization until the team runs the system on its own. The go-live date is tied to the accounting calendar: the Odoo 20 documentation names the end of the fiscal year as the easiest moment to move the books and advises against doing it in the middle of a tax period. The project is finished when the system becomes the normal way of working, not on go-live day. - Author: Fabio Soto, Business Analyst, Quantum Garage - Published: 2026-10-17T00:00:00-06:00 - Updated: 2026-10-17T00:00:00-06:00 - Odoo version: 20 - URL: https://web.quantumgarage.io/en/guides/odoo-implementation-mid-sized-company/ ## What an implementation is Implementing Odoo means moving the company's operation onto a single system, where sales, purchasing, inventory and accounting work on the same data. In a mid-sized company that involves several departments that depend on one another, an accounting team whose tax obligations keep running for the whole project and, in most cases, a previous system with years of history. Configuration is the technical part; the change in how people work is what decides the project. If your company operates in Mexico, one more element runs through the whole project. Invoices are issued as a [CFDI](https://web.quantumgarage.io/en/glossary/cfdi/) (Comprobante Fiscal Digital por Internet, Mexico's electronic invoice), stamped through an authorized certification provider, the [PAC](https://web.quantumgarage.io/en/glossary/pac/) (Proveedor Autorizado de Certificación), following the filling rules published by the SAT (Servicio de Administración Tributaria, Mexico's tax authority). Odoo handles this through its Mexican localization, and it shapes the work from the first analysis to the first month-end close. - **Gap analysis (fit-gap)**: The process-by-process comparison between how the company operates and what Odoo covers out of the box, to decide what is configured, what is developed and what is decided. - **Data migration**: Moving into Odoo the master data and balances the operation needs to keep running on go-live day. - **Cut-off**: The moment from which transactions are recorded in Odoo and the previous system stops being the source of truth. - **Go-live**: The day Odoo goes into production and the team starts working in it. - **Stabilization**: The period after go-live, with close support, when the adjustments that only show up under real operation are resolved. - **Adoption**: The point at which the team works in the system out of habit, without going back to side spreadsheets or to the previous system. ## The phases, in order Every implementer names the phases its own way, but the work inside them is the same: Table: What each phase decides and who takes part on the company side | Phase | What gets decided | What it leaves | Who takes part on your side | | -------------------------- | ----------------------------------------------------- | ----------------------------------------------------- | ----------------------------------------- | | Process and gap analysis | How you will work and what Odoo covers out of the box | Documented processes and each gap with its resolution | Management, project lead and key users | | Configuration | How Odoo is set up for those processes | A test database configured with your own master data | Project lead and key users | | Testing with real data | Whether each process works end to end | Processes accepted by the people who run them | Key users and accountant | | Data migration | What is brought over, and at what quality | Clean master data and balances that reconcile | Owners of each master list and accountant | | Cut-off and go-live | When the switch happens | Odoo in production | Management and the whole team | | Stabilization and adoption | What is adjusted under real operation | A team that runs the system on its own | Key users and end users | The phases overlap. Data cleaning is best started during the analysis, because it is done by the people who run the operation and moves forward alongside their daily work, and every round of testing sends adjustments back to configuration. At Quantum Garage this arc has a name: Quantum Ready gets processes clear before you start, Quantum Sequence is the implementation itself, which moves forward in cycles, and Quantum Success supports adoption after go-live. ## The gap analysis decides the rest The analysis compares each company process with what Odoo covers out of the box. Its result says what the standard covers, what is solved through configuration and where there is a real gap, which is closed in one of two ways: adjusting the process to how Odoo works, or developing what is missing. That list is the project scope, and three decisions come out of it that are best not made earlier. The first is hosting. The official Odoo 20 documentation states that Odoo Online is incompatible with custom modules and with modules from the Odoo Apps Store, so a single development leaves the choice between [Odoo.sh](https://web.quantumgarage.io/en/glossary/odoo-sh/) and on-premise. The guide [Odoo Online, Odoo.sh or on-premise](https://web.quantumgarage.io/en/guides/odoo-online-vs-odoo-sh-vs-on-premise/) explains how to choose. The second is the timeline, because how many processes are in scope, how much development is needed and how much data has to be migrated are only known once the analysis is done. The third is the cut-off date, which is tied to the accounting calendar, as explained below. In Mexico, the analysis covers the tax side from the start. To set up electronic invoicing, the Odoo 20 documentation for the Mexican localization requires the company to be registered with the SAT under a valid RFC (Registro Federal de Contribuyentes, the Mexican tax ID), to hold its [CSD](https://web.quantumgarage.io/en/glossary/csd/) (Certificado de Sello Digital, the certificate used to seal each CFDI) and to choose a PAC. Each customer must also carry, in Odoo, its business name exactly as registered with the SAT and its tax regime (régimen fiscal). For a foreign company running a Mexican entity, these data come from the SAT registration of each party, so they belong in the analysis, not in the week before go-live. ## Configure and test with real data Configuring means translating the agreed processes into Odoo: journals and taxes, warehouse routes, price lists, access rights for each role. It is done in a test database, never in production, and it is tested with the company's own master data rather than sample data, because the errors that matter live in real data: the product with two units of measure, the customer with two legal entities, the invoice paid in installments. The Odoo 20 accounting documentation recommends exactly this for moving the books: > “It is recommended to practice this process in a test database and work in parallel with your prior accounting workflows in case there are any issues.” Odoo, “Get started”, official Odoo 20.0 documentation (Accounting), accessed October 17, 2026. The tests that count are acceptance tests, and they are run by key users, not by the implementer. Each one runs their full process —from quotation to collection, from purchase order to vendor payment— with their own data and confirms it works. That is how go-live day avoids being the first time anyone in the company uses the system. ## Data migration: what moves and what stays Migration does not move everything the previous system holds: it moves what the operation needs to keep running. The Odoo 20 accounting documentation asks you to prepare, from the previous system, the opening account balances, the open customer invoices and vendor bills with their credit notes and refunds, and the opening inventory count. Table: What is migrated to Odoo and when it goes in | Package | What it includes | When it goes in | | ---------------- | ------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- | | Master data | Chart of accounts, contacts, products with their categories, and bank accounts | Before the cut-off, validated during testing | | Opening balances | Trial balance at the cut-off date, open customer invoices and vendor bills, counted inventory and each bank balance | At the cut-off | | Live documents | Sales and purchase orders that are still open | At the cut-off | | History | Paid invoices, past transactions and old quotations | Stays in the previous system for reference | Order matters. Odoo calls master data the records that other records rely on —an invoice needs its customer—, and its documentation warns that the order in which they are loaded is crucial: master data first, then whatever depends on it. The import tool works with Excel or CSV files, ships templates for the most common data and has a button to test a file before importing it. That test matters, because the same documentation warns that imports are permanent and cannot be undone; this is why every load is rehearsed in a test database first. When data comes from another system, Odoo lets you use the key each record had in the previous system as its external ID, which keeps the links between customers, products and documents intact. The detail, including balances and how to reconcile them, is in the guide [How to migrate to Odoo from another ERP](https://web.quantumgarage.io/en/guides/migrate-to-odoo-from-another-erp/). ## The cut-off: when and how you switch systems The cut-off date is chosen against the accounting calendar, not the project schedule. The Odoo 20 documentation distinguishes three moments to move the books and names the first as the easiest: > “At the end of the fiscal year: this is the easiest option because it minimizes the data that needs to be transferred.” Odoo, “Get started”, official Odoo 20.0 documentation (Accounting), accessed October 17, 2026. The second moment is the end of a tax period, where you can bring over everything posted in the period or only the balance of each account. The third, in the middle of a tax period, is advised against: splitting a period between two systems complicates the tax filing, because the data from both has to be combined. Once the date is set, the form remains. There are three, and each has its cost: Table: Three ways to run the cut-off | Approach | How it works | When it fits | What it requires | | ---------------------- | ------------------------------------------------------ | ------------------------------------- | ----------------------------------------------------- | | All at once (big bang) | The whole operation moves to Odoo on the same date | Contained scope and accepted tests | A full rehearsal of the cut-off and a rollback plan | | In stages | Each department or group company moves on its own date | Large operations or several companies | Bridges between the two systems while they coexist | | In parallel | Transactions are recorded in both systems for a period | Low tolerance for accounting risk | Double entry and a fixed date to end the parallel run | Whatever the approach, the cut-off has an hour: from that moment, whatever was migrated stops being captured in the previous system. Before that hour, the full cut-off is rehearsed on a copy, with real data and in the real order. And the decision to go live is made against written criteria —balances that reconcile, trained users, invoice stamping tested with the production certificate and PAC—, not against the date. ## Go-live and stabilization Go-live is the day the operation moves to Odoo, and the weeks that follow concentrate the questions and adjustments that only appear at real volume. That is why support is closest at the beginning and steps back as the team solves things on its own. The test that confirms the cut-off is the first month-end close in Odoo: the trial balance starts from the migrated balances, and Mexico's electronic accounting (contabilidad electrónica) comes out of the system. The Odoo 20 Mexican localization generates, in XML, the chart of accounts, the trial balance and the general ledger journal entries. If that first close comes out clean, the accounting migration was done right. ## Adoption: when the system becomes the way you work A project is measured by adoption, not by its go-live date. Adoption shows in concrete things: management reports come out of Odoo, nobody keeps a side spreadsheet “just in case”, the previous system is opened only to look up the past, and exceptions are resolved inside the system instead of by message. The relationship with the system continues afterwards. According to the Odoo documentation, each major version is supported for three years, so a well-run implementation leaves the database ready to upgrade: documented processes, maintained developments and tests that can be repeated. ## Who takes part on the company side The partner configures, develops what is needed and supports the team; process decisions belong to the company. These are the roles a mid-sized company covers: Table: The company's roles in an implementation | Role | What it does | When it weighs most | | ----------------------------------- | -------------------------------------------------------------------- | ---------------------------------------- | | Executive sponsor | Sets the scope, backs process decisions and frees up the team's time | Analysis and cut-off | | Internal project lead | Single point of contact: gathers answers, schedules and follows up | The whole project | | Key users | Describe their process, test it and train their department | Analysis, testing and go-live | | Accountant or tax lead | Validates the accounting and tax setup and approves the balances | Configuration, migration and first close | | Master data owners | Clean up customers, vendors and products | Migration | | IT, if the company has the function | Integrations, access and equipment | Configuration and go-live | One person can cover two roles; what counts is that every role has an owner. With a project lead, decisions converge on one person, and with key users who have time set aside, testing gets done in full. ## Signs to read the project's progress Table: Signs of a project on track and signs that call for attention | Topic | On track when | Calls for attention when | | ------------ | ------------------------------------------- | ------------------------------------------------ | | Decisions | Made the week they are requested | Pile up for the next meeting | | Key users | Have hours set aside for the project | Test in their spare time | | Data | Cleaning moves forward from the analysis on | Master data is completed the week of the cut-off | | Scope | Every change is weighed against the date | Changes come in without checking their effect | | Testing | Full processes are tested with real data | Isolated screens are reviewed with sample data | | Go-live date | Tied to the accounting calendar | Set by a commitment unrelated to the operation | ## How to start 1. Name the executive sponsor and the internal project lead before the analysis starts. 2. Write down your processes as they run today, exceptions included. 3. Run the gap analysis before choosing hosting and before committing to a date. 4. Choose the cut-off date against the fiscal calendar: ideally, the end of a fiscal year or of a tax period. 5. Start cleaning master data from day one. ## Frequently asked questions ### How long does an Odoo implementation take in a mid-sized company? It depends on what the gap analysis finds: how many processes are in scope, how much development is needed and how much data has to be migrated. A serious timeline is given once that analysis is done, and it is best tied to an accounting close. ### When is the best time to go live with Odoo? According to the Odoo 20 documentation, the end of the fiscal year is the easiest option because it minimizes the data to transfer. The end of a tax period also works; the middle of a period is not recommended, because the data from two systems has to be combined for the same tax filing. ### Can Odoo be implemented in stages? Yes. Each stage has its own cut-off, and while both systems coexist you need bridges between them, for example when sales are already recorded in Odoo and accounting is not yet. ### What data is migrated to Odoo? Master data (chart of accounts, contacts and products), the balances at the cut-off date (trial balance, open invoices and bills, inventory and bank balances) and the orders that are still open. History stays in the previous system for reference. ### Who needs to be involved on our side? An executive sponsor, an internal project lead who acts as the single point of contact, key users from each department and your accountant. When key users have time set aside, testing is complete and adjustments arrive before go-live. ## Sources 1. Odoo S.A., “Get started (Accounting)”, official Odoo 20.0 documentation. . Accessed 2026-10-17T00:00:00-06:00. 2. Odoo S.A., “Export and import data”, official Odoo 20.0 documentation. . Accessed 2026-10-17T00:00:00-06:00. 3. Odoo S.A., “Odoo Online”, official Odoo 20.0 documentation. . Accessed 2026-10-17T00:00:00-06:00. 4. Odoo S.A., “Mexico (fiscal localization)”, official Odoo 20.0 documentation. . Accessed 2026-10-17T00:00:00-06:00. 5. Odoo S.A., “Upgrade”, official Odoo 20.0 documentation. . Accessed 2026-10-17T00:00:00-06:00. 6. Servicio de Administración Tributaria (SAT), “Anexo 20. Guía de llenado de los comprobantes fiscales digitales por Internet”, SAT, Mexico. . Accessed 2026-10-17T00:00:00-06:00.