New: Odoo and Dynamics 365 cost calculators.Estimate your costs

Odoo implementation rescue: taking over from another partner

An Odoo implementation rescue means taking over a live or half-built Odoo project from a partner that is late, over budget or delivered a system your team cannot run.

FlecticUpdated 13 min read

An Odoo implementation rescue means taking over a live or half-built Odoo project from a partner that is late, over budget or delivered a system your team cannot run. A new partner can usually do that job. It works only when your company holds the hosting access, the admin rights, the custom code and the Odoo subscription before anyone quotes, and when the custom modules have been audited against standard Odoo. This guide sets out that handover in the order we would run it, and names the cases where a rescue is the wrong route.

What a new partner needs before it can take over

Most takeovers stall on access, not on code. Before a new partner estimates anything, list the six items below and confirm who holds each one today.

  • Hosting access (What the new partner needs: Admin or collaborator access to the Odoo.sh project, the Odoo Online database or the server · Where it often sits: The former partner's account or your IT team's login)
  • Admin rights (What the new partner needs: An administrator user inside the database, with the password under your control · Where it often sits: Inside the database itself)
  • Custom code (What the new partner needs: Source code for every custom module, in a repository your company can read · Where it often sits: A former partner's own GitHub account)
  • Odoo subscription (What the new partner needs: The subscription and database linked to your company's Odoo account · Where it often sits: The account of whoever signed the original order)
  • Data migration scripts (What the new partner needs: The scripts, mapping files and load logs used to bring historical data in · Where it often sits: A laptop or a personal drive)
  • Open issue list (What the new partner needs: Every bug, change request and unfinished item, with a status · Where it often sits: The former partner's ticket tool)

Ownership is where takeovers usually get stuck. Odoo's guidance on custom code ownership for Odoo.sh projects says the customer organization should own the project, and that this is recommended even when the partner does all the custom development. The same guidance says the partner should hold collaborator access, while your company owns the primary repository and keeps it private. The Odoo.sh infrastructure and custom code ownership guidance lists the full set of recommendations.

Odoo.sh projects

The project owner adds people by GitHub username. New collaborators get the Developer role by default. Only the Admin role has access to the project settings and the audit logs, and Developers cannot connect to the production or staging databases. The Odoo.sh settings documentation for Odoo 19.0 describes the roles. For a takeover, give the new partner the role it needs to do the work, and keep the Admin role with your company.

Odoo Online databases

On Odoo Online, ownership moves through Odoo Support. Create a support ticket and use the Transfer Ownership option in the database manager. Before you start, download a ZIP backup with the Download Backup option. Odoo's Odoo Online documentation says databases are backed up daily under its Cloud Hosting SLA, but a backup you hold yourself is the copy you control during the handover.

Subscriptions and admin accounts

Check the subscription and the admin accounts together. If the Odoo subscription sits in a former partner's account, ask for the transfer before the new partner starts, so that the people who can reach your data are people your company still employs or contracts. For the wider ERP scope, see Flectic's ERP services.

Audit the custom modules against standard Odoo

Odoo's upgrade guide for customized databases defines a custom module as any module that extends standard Odoo code and was not built with the Studio app. The same guide notes that Studio customization, customized website pages, email templates and translations are not intrinsically related to the custom modules. Audit them as a separate list, so a Studio change is never mistaken for code.

Run the audit in this order:

  1. Inventory every custom module. List the apps it touches, who last changed it and the version of Odoo it was written for.
  2. Check standard coverage. For each module, ask whether the version you run now covers the feature with settings. Odoo's guide asks teams to challenge their developments and find functional workarounds, because code that overlaps standard Odoo adds technical debt that every upgrade has to re-test.
  3. Install each module alone on an empty database of the same version. Odoo recommends installing modules one by one and fixing every traceback and warning before going further.
  4. Test what each module changes. Odoo's list includes views, email templates, reports, server actions, automated actions, changes to standard workflows and computed fields.
  5. Run the standard tests of the modules each custom module depends on. A failing standard test means either the test describes a workflow you changed, or the customization misses a standard flow.
  6. Record a verdict for each module, using the table below.
  • Keep (When it applies: Installs cleanly, the tests pass, and standard Odoo does not cover the feature · Next step: Document it and move the code into a repository your company owns)
  • Replace with standard settings (When it applies: Standard Odoo now covers the feature with configuration · Next step: Remove the module, move the data and retest the workflow)
  • Rewrite (When it applies: The module installs but breaks in use, or depends on standard code that has changed · Next step: Rewrite the affected part and add tests before the next release)
  • Remove (When it applies: Nothing in the business depends on it · Next step: Remove it and log the decision in the issue list)

Review the data migration scripts with the same care. Odoo's upgrade guide says that renamed models, fields and external identifiers should be renamed with upgrade scripts, so the module update does not lose data. A migration script that loads values into the wrong fields often stays hidden until a report looks wrong weeks later, so test each script against a copy of the data before it runs on the live database.

Fix in place, re-implement a phase or move version

Once the audit is done, each module and each app falls into one of three routes. The choice depends on the state of the data and on the version you run.

  • Fix in place (Fits when: The data is correct, the bugs sit in a few modules, and the version is still supported · Main risk: The fix hides a design problem that returns in the next phase)
  • Re-implement one phase (Fits when: One app's design is wrong and the rest of the database holds sound data · Main risk: Rebuilt data needs a clean migration and a rehearsal before go-live)
  • Move version (Fits when: The current version is near the end of its support, or the custom code must run on a newer release · Main risk: The custom code must run on the target version before the database upgrade can proceed)

Odoo's upgrade documentation says each major version is supported for three years, and that the deadline to upgrade depends on the hosting type and the version. Check the deadline for your database before you choose the move-version route, because it sets how much time the rest of the plan has.

Odoo's guide also sets the order for a customized upgrade. Freeze development, with bug fixes exempt, and request an upgraded test database. Make the custom modules installable on an empty database of the target version, move them onto the upgraded database, test them, rehearse, and only then upgrade production. The upgrade documentation adds that a database with custom modules can be upgraded only once the custom source code is up to date with the target version.

A worked example of the three routes

Assume a 35-person distributor with Odoo Sales, Inventory and Accounting live for 14 months, 30 users, and eight custom modules written by the former partner. The audit gives these verdicts:

  • Two modules add a discount rule that standard pricing settings now cover. Both get the replace verdict, and the rule moves into standard configuration.
  • Three modules install cleanly and pass their tests. They get the keep verdict, and their code moves into a repository your company owns.
  • One module breaks the stock valuation report after a standard change. That needs one report rewritten, so the Inventory app keeps its current design.
  • One module holds a quote-to-order workflow built around a custom model the business no longer uses. It gets the remove verdict.
  • One module was built for a warehouse the distributor has closed. It also gets the remove verdict.

With those verdicts, Inventory and Accounting are fixed in place, because the data is correct and the bugs sit in single modules. Sales is re-implemented as one phase, because the module its quote-to-order workflow relied on is removed and that workflow needs a new design. Assume the version is still supported. Then no move is needed yet, but the support date still goes on the plan.

When the Odoo choice is the problem

A rescue assumes the chosen platform can carry the business once the project is repaired. Sometimes it cannot. Ask these questions before you sign with any partner:

  • Which core process needs custom modules because the standard apps do not cover it?
  • Would a change to that process remove most of those modules?
  • Would your team still choose this platform if the project were finished today?

If the first question has a long answer and the second has no, the platform is the problem, and rescuing the project only moves it. A platform review comes first. Flectic's ERP selection service compares Odoo and Microsoft Dynamics 365 on your requirements in a platform-neutral way, and then implements the platform you choose.

The guide on rescue versus switching partners covers when to change partner and when to keep the current one. To check how far the project has drifted, the ERP project warning signs guide lists the signals worth checking first.

When the current partner can still deliver

A current partner can still deliver if the scope is reset in writing. Ask for a reset scope with the named people who will work on your database, the hours each one will give, a phase plan and a price for each phase. If the partner cannot name those people, the reset is a new sale, and you should weigh it as one.

Stage the recovery plan

Run the recovery in six stages. Each stage closes with a written sign-off before the next one starts, because work skipped at one stage returns later as a change request.

  1. Freeze and back up. Pause new feature work while keeping bug fixes running, since Odoo's guide exempts bug fixes from its freeze, and download a backup you hold before any change.
  2. Secure access. Move hosting ownership and the admin rights to your company, then grant the new partner the role it needs.
  3. Audit. Run the module audit on the full list of custom modules, data scripts and open issues, and record a verdict for each module.
  4. Decide the route. Assign each module and app to fix in place, re-implement or remove, and choose a version move only if the audit requires it.
  5. Rehearse on a copy. On Odoo Online, a duplicate expires after 15 days, and each database can have up to five duplicates. By default the For testing purposes option is enabled, which disables external actions such as emails, payments and delivery orders on the copy.
  6. Approve one phase at a time. Sign each phase with a fixed scope, a price and an acceptance test, go live when the rehearsal passes, and open the next phase only then.

Mistakes that restart the clock

  • Quoting before access is secured. A new partner that estimates without admin rights and the source code has to price the unknowns, so the number moves later.
  • Building new features during the audit. Every new module adds code the audit must cover again.
  • Skipping the empty-database install. A module that works on a live database can still fail on a clean install, and Odoo's guide names that install as the first test.
  • Leaving the former partner as the only admin. Until ownership and admin rights move, your company cannot change who reaches the database.

How Flectic can help

Flectic implements Odoo for companies of 20 to 100 people in the US and Canada that want sales, stock and finance in one Odoo database at a lower license cost, starting with a few apps. We implement one app at a time on the same database, use standard Odoo settings first, and customize only where your process differs from Odoo's defaults. Flectic sends a written proposal with a fixed price for each phase before work starts. Bring your late or half-built Odoo project to a free 30-minute discovery call and you leave with a recommended first phase or a clear reason to wait. Flectic's Odoo implementation page shows how that work is scoped.

Sources

Frequently asked questions

Can a new Odoo partner take over a project another partner started?

Usually yes, if the new partner first gets admin access to the hosting, the code repository and the Odoo subscription. Most of the risk sits in custom modules nobody has documented, so the module audit comes before any fixed quote.

Who should own the Odoo subscription and the code repository?

Your company should own both. Odoo's guidance for Odoo.sh projects says the customer organization should own the project, with the partner holding collaborator access rather than ownership.

Should we fix the current Odoo project in place or re-implement a phase?

Fix in place when the data is correct and the bugs sit in a few modules. Re-implement a phase when one app's design is wrong and the rest of the database holds sound data. Compare both routes in writing before you choose.

What does a custom module audit check?

It checks whether standard Odoo now covers each feature, whether each module installs cleanly on an empty database of the same version, what each module changes and whether its standard tests pass. Each module then gets a verdict to keep, replace, rewrite or remove.

When is a platform review a better first step than a rescue?

A platform review comes first when the core process needs custom code the standard apps do not cover, and a process change would not remove that code. Repairing the project in that case only moves the same problem into the next phase.

Related guides

More on odoo

  1. OdooShopify Odoo integration for ecommerce brandsA Shopify Odoo integration keeps Shopify as the storefront and puts Odoo behind it when stock, purchasing, wholesale orders, returns and accounting need one owner.14 min read
  2. OdooKatana MRP alternative: when your stack has outgrown KatanaThe best Katana MRP alternative for a small maker is usually Odoo, and only once the Katana and QuickBooks Online stack costs more than it saves.13 min read
  3. OdooOdoo vs Procore for general contractors: where job costs belongIn the Odoo vs Procore choice, Odoo can be the single system where a general contractor of 20 to 100 people runs estimates, job budgets, purchasing, subcontracts, progress billing and job cost.14 min read

Where to go from here

Talk to a consultantBook a free discovery callA 30-minute call on whether Odoo fits your operation, ending with a recommended first phase or a clear reason to wait.Run the numbersEstimate your Odoo cost$24.90Odoo Standard, per user a month in year onePlan, users, hosting and implementation, with first-year and three-year totals.
Read first