Failed ERP implementation: rescue the project or switch partners

An ERP project that is late, over budget, or live and unusable has four ways out: continue under a corrected plan, cut the scope back to something deliverable, replace the implementation partner, or restart the build. The decision rests on two things you can establish within a month: what you control (your data, your licenses, your configuration, your code) and what each option costs from today forward.

The failure rates that still circulate in blog posts do not survive contact with the current data; our ERP implementation statistics and success rates breakdown separates the two. The number worth carrying comes from Panorama Consulting Group's 2026 ERP Report: more than a quarter of organizations reported their project ran over budget, most often because of an unexpected need for additional technology, which the report connects to poor system selection. Median annual revenue in the respondent profile is USD 200.5 million, so the sample is large companies, not a 25 to 100 person company. The report does not say a late or unusable system is the norm. The useful question is which exit fits your situation, and the sections below supply what the decision needs: the symptoms, the matrix, the 30 day assessment, the ownership checklist, and the briefing pack for a replacement partner.

Symptoms that tell you a project is in trouble

A late project shows symptoms, and each one points to a cause you can name. One symptom with a credible explanation behind it is ordinary. A pattern of them means the project is managing you, and the assessment in the next section is overdue.

• The go-live date has moved more than once (What it usually means: The plan had no float and the estimate was optimism · Severity: Serious)
• Status reports describe activity and never decisions (What it usually means: Nobody is managing scope week to week · Severity: Serious)
• Invoices now exceed the signed proposal, change order by change order (What it usually means: The fixed price became a license to re-estimate · Severity: Serious)
• Key users still do their daily work in the old system (What it usually means: The design fits how they work less well than promised · Severity: Serious)
• Data migration keeps slipping (What it usually means: The hardest work item has no owner · Severity: Serious)
• No discovery or audit documents exist (What it usually means: Work began without a baseline, so nothing holds anyone to anything · Severity: Critical)
• Testing keeps waiting for the next build (What it usually means: The build may not survive contact with a test · Severity: Critical)
• Nobody outside the partner can log into the environments (What it usually means: You do not control your own project · Severity: Critical)
• You cannot get a written completion estimate (What it usually means: Your partner cannot see the end either · Severity: Critical)

A serious symptom calls for a corrected plan and a closer look this week. A critical one means start the 30 day assessment now and hold new spend until it is done.

A buyer on an r/Odoo pricing thread puts it plainly: "If you don't have any audit/discovery materials, that's a big red flag." (Custom Module Cost, Reddit r/Odoo). The same thread advises taking the proposal and any audit or discovery materials produced and shopping them to other partners. Another buyer posted a quotation that "has just one line item with no task breakdown" (Odoo in charging 30000 GST for accounting module, Reddit r/Odoo). Documents you can point to are how you judge work you cannot personally inspect, and their absence is how a project stays opaque until the money runs out.

The four options: continue, repair the scope, replace the partner, or restart

Every troubled project lands in one of four options, and two of them can combine. Here is when each fits and what it requires from you.

Continuing fits when the problems are managerial. Dates slipped because decisions on your side took weeks, the deliverables match the design when you check them, and the team is competent. The conditions: a written recovery plan with dates and named owners, a weekly decision meeting, and a 30 day checkpoint where you decide again on fresh evidence.

Repairing the scope fits when the build is sound and the budget cannot absorb the full design. Phase one shrinks to finance plus one operational flow, and deferred scope moves to a second phase with its own estimate. Budget for the knock-on work: a smaller phase one changes the test plan, the data migration scope and the training outline.

Replacing the partner fits when the platform is right, the build has value, and the problem is the team doing the work. It is feasible when you hold the access and the artifacts; the checklist below tells you whether you do. Expect a takeover partner to re-verify the basics before committing to a number.

Restarting fits when the foundation is wrong: the data model cannot support how you operate, the configuration contradicts the design documents, or there is no testable build to assess. You pay for discovery and the build a second time, and the licenses stay yours. The data stays with you when you already hold a restored backup, or when an Odoo agreement ends and you instruct Odoo SA to return the data at termination.

• Continue (Choose it when: The plan is credible and delivery improves on a new cadence · Signals the audit should confirm: Missed dates trace to decision delays on your side; deliverables match design · Main risk: The same failure mode returns after the checkpoint)
• Repair the scope (Choose it when: The build is sound; budget or timeline cannot absorb the scope · Signals the audit should confirm: Configuration matches design; overruns come from breadth · Main risk: Cutting something phase one needs)
• Replace the partner (Choose it when: The platform is right; the artifacts are yours · Signals the audit should confirm: Work products exist; quality or velocity is the problem; access is in your hands · Main risk: Knowledge loss during handover)
• Restart (Choose it when: The foundation is wrong · Signals the audit should confirm: No testable build; data model conflicts with operations; configuration contradicts design · Main risk: Paying for discovery and build twice)

A replacement and a scope repair often travel together: the new team's first deliverable is the smaller phase one. If the audit finds no testable build, stop comparing and start the restart conversation, because every week on an unassessable build is spend without evidence.

A 30 day assessment: what to audit and who does it

Four weeks, one owner on your side, and a written pack that feeds the matrix above. Work through it in this order.

1. Week 1 is paperwork and access. Collect the signed proposal, the statement of work, every change order, and the invoice history beside them. Inventory every environment, license and repository, and confirm your own admins can log into all three today.
2. Week 2 is the build. Compare the configuration to the design documents, separate what runs in production from what is configured only, and record the test evidence and the state of the data migration: mapped, loaded, reconciled, or untouched.
3. Week 3 is the numbers. Ask the current partner for a written completion estimate with a task breakdown. Ask a second partner for an independent takeover estimate from the briefing pack below. Those two estimates are the core of the decision.
4. Week 4 is the decision. Score the four options against what the audit found, decide, and write the decision down with its assumptions for whoever funds the next phase.

Your project lead or COO owns the assessment, with an outside consultant when your team lacks the platform depth or the spare cycles. The current partner supplies the materials and the completion estimate, and the independent takeover estimate in week 3 is your check on the number.

Pricing is a fair question, and the fee tracks the materials you can hand over, so ask each bidder to price the assessment as its own line with the deliverables and duration named. A number quoted before anyone reads your statement of work is a guess. If you want the assessment done by the team that would also do the rescue, that is how Flectic structures its ERP implementation services: a fixed-scope assessment of the current build, then a recovery plan you can accept or shop elsewhere.

Take control of credentials, licenses, documentation, data and code

Do this section before any negotiation, whatever you decide next. The replace and restart options are only real when you hold the artifacts. Without them, switching means paying someone to reconstruct what you already paid for.

• Admin access to every environment under your own accounts: You can grant and revoke access the day the relationship ends
• License records for your Microsoft tenant: Business Central cloud is bought through a partner, and the licenses sit in your tenant
• A database backup you hold, restored somewhere you control: The asset a takeover or a restart builds on
• Ownership of the Odoo.sh project and the primary GitHub repository: The owner grants and revokes collaborator access and keeps the custom code
• Design documents, discovery materials, test scripts, data mappings, integration specs: The raw material of the briefing pack
• The statement of work and every change order, with the invoice history: The baseline for both estimates

What you own on Odoo

The subscription is yours. A partner switch on Odoo runs on public terms: the Odoo Enterprise Subscription Agreement lets you decide at any time to work with a different Odoo partner or with Odoo SA directly, subject to prior notice, and it requires 30 days of written notice to Odoo SA before your main point of contact changes (as of October 2026, agreement version 13). Give notice on November 1 and you should plan for the change to take effect around December 1. One condition matters: if you work with Odoo SA directly, services for Covered Extra Modules are provided only while you host on the Odoo Cloud Platform.

What you own on Business Central

Business Central cloud is bought through a partner, and the licenses live in your Microsoft tenant, so the tenant stays yours while the partner relationship changes. For a rescue on Microsoft Dynamics 365 Business Central, that split matters: a takeover changes the people and the delegated access, while the tenant, the licenses and the environments stay put. Microsoft's documentation describes the ways a partner attaches to a tenant: claiming partner of record, a CSP relationship, or digital partner of record (Solutions Partner for Business Applications, Microsoft Learn, as of October 2026). It does not spell out removal steps, so treat the change of partner of record as something to resolve through the agreement you signed, and raise it before you give notice. Access is documented: administrative work such as a migration runs under the tenant and Business Central admin, and delegated admins need approval from a licensed user (Dynamics GP migration to Business Central, Microsoft Learn). That approval is what a replacement partner will ask your admin for.

Sorting your code into three piles

Odoo's guidance on Odoo.sh says the customer organization should own the project and the primary repository, grant the partner collaborator access, and keep the partner's proprietary modules in a separate repository (Odoo.sh and custom code ownership, Odoo, as of October 2026). Owned that way, the code follows you when the partner does not.

Standard software is the platform as shipped, and nothing needs recovering there. Covered Extra Modules are Studio customizations and partner code you pay to maintain. Odoo SA's upgrade service upgrades them. Third-party extensions outside that coverage are yours to convert. Partner-proprietary modules are the contract question: the Enterprise agreement does not by itself transfer a partner's proprietary modules to you, so ownership depends on what your agreement with the partner says. If the agreement is silent, the handover becomes a negotiation. If it assigns the code to you, the repository and the deployment instructions belong in the handover file.

Rescue or restart: the comparison that decides it

Start with the missing number: public sources publish no cost for a rescue, a re-implementation, or a restart, and the rescue-to-original ratios in circulation are unverified. The numbers that decide your case are specific to your build, and you manufacture them in week 3 of the assessment: a written completion estimate from the incumbent, and an independent takeover estimate from a candidate replacement.

Both estimates need the same shape so they can be compared line by line: remaining configuration and testing, the state of the data migration, integrations, training, licenses during the delay, and the hours your own team will spend. Ask each side to state its assumptions and its confidence. An estimate without a task breakdown is the one-line quotation problem again, and it deserves the same reaction.

The money already spent cancels out of the comparison, because it is identical under every option. The sunk-cost trap is letting it vote anyway: a build you would not buy again today does not become worth finishing because most of the invoice has been paid. The cleaner test is to imagine the two estimates arriving with no history attached, and to fund the one you would pick as a fresh decision.

Assume the incumbent estimates four months to complete with the current team, and a replacement estimates six months to take over and finish. The comparison is four months on a cadence that has already missed you twice against six months that include re-learning a project you already paid to discover. Either can be the right answer. The assumptions behind each number decide it, which is why they go in writing before you choose.

Where Flectic fits

Flectic is one candidate when the replacement-partner option wins. We implement Odoo and Dynamics 365, earn no vendor quota on either, and hold no certification from either vendor, so our view of your build is not tied to either platform. Each phase has a defined scope and price before it starts, which answers the one-line quotation problem described above.

Choose Flectic if

• Your build is on Odoo or Business Central and your company has 20 to 100 people in the US or Canada.
• You want a second view on whether to continue, repair, replace or restart before you commit.
• You want a named senior consultant and a priced first phase that delivers a working part of the system.

Look elsewhere if

• Your system runs on another platform, such as SAP or NetSuite.
• You need a vendor-certified partner of record.
• You are above about 100 users or need multi-country Finance and Operations.

See ERP implementation services for how we scope a first phase.

How to brief a replacement partner

A replacement partner quotes faster and sharper from a pack than from a discovery call, and the same pack sent to every candidate is what makes their answers comparable. Build it from the assessment.

The briefing pack

1. The signed proposal, the statement of work and every change order, with the invoice history beside them.
2. The design and discovery documents that exist, plus a list of the ones that do not.
3. An inventory of environments, licenses and repositories, marked by who holds access today.
4. A fresh database backup and read access to the code repository.
5. A one-page statement of what runs in production today and what is configured only.
6. Test evidence and the current state of the data migration.

Buyers on that r/Odoo thread recommend taking the proposal and any audit or discovery materials to other partners. Send each candidate the same pack so the takeover estimates can be compared.

What to ask each candidate

Score the partner separately from the software. Rand Group's selection guidance scores the implementation partner on the proposed team, the methodology, the data migration approach and the references (ERP selection checklist, requirements, vendor evaluation and scoring template, Rand Group, as of October 2026). Four questions do most of the sorting:

1. Who will work on our project, by name, and what share of their week do we get?
2. What do you read first when you take over another partner's configuration, and what would make you advise a restart?
3. What would you cut from phase one to protect a go-live date?
4. Which takeover references on this platform can we call?

A candidate who cannot describe their first week of reading has not assessed your build. Ask them to quote again after the read, and compare the revised number with the first.

What your contract says when you leave a partner

Read four clauses before you send any notice. The first is termination: the rights, the notice periods, and what counts as cause. The second is payment for work in progress, and which deliverables that payment buys you. The third is ownership of deliverables and custom code, which decides the third pile in your code inventory. The fourth is handover: what the incumbent must provide, in what form, and by when.

The platform agreements set some of the terms for you. The Odoo Enterprise Subscription Agreement lets the customer decide at any time to work with a different partner or with Odoo SA directly, subject to prior notice, and sets 30 days of written notice before the main point of contact changes. On termination, Odoo returns your data or deletes it at your choice, subject to the delays in its privacy policy. On the Microsoft side, Business Central subscriptions bought through a partner stay in your tenant, the cancellation and assignment terms live in the agreement you signed, and the partner of record change runs through that agreement.

This section is orientation from implementation practice and is not legal advice. Have counsel read the agreement before you give notice, and if you operate on both sides of the border, ask them to confirm how each of these clauses behaves under US and under Canadian law.

Mistakes that make a rescue harder, and how to avoid a repeat

1. Announcing the switch before securing access, the backup and the repositories. Your options narrow the moment your access does, so complete the ownership checklist first.
2. Freezing every workstream while you decide. Licenses keep billing and experienced people keep leaving, so pause new scope and keep verifiable work such as data cleanup moving under a corrected cadence.
3. Accepting the incumbent's handover file unchecked. Make the incoming partner verify that the backup restores, the repository builds, and the configuration matches the documents before the final invoice is paid.
4. Skipping discovery on the rescue itself. The missing audit documents that flagged the original project will flag the rescue too, and the next partner inherits the same opacity.
5. Choosing the replacement on price alone. The lowest takeover estimate usually assumes the best about the configuration it inherits, and the assumptions are where overruns live.
6. Keeping the lesson in memory only. Run a structured review once the rescued system settles; our guide to the ERP post-implementation review lists what to ask while the findings are fresh.

Avoiding a repeat comes down to habits you control. Own the artifacts from kickoff: your tenant, your repositories, your backups. Require written discovery and a task-level estimate before work starts. Put a single named owner over a weekly decision cadence, and schedule the post-go-live review before the project starts.

How Flectic can help

Start with what you control: logins, licenses, the latest backup and the repository. Send us the same briefing pack described above, and we will tell you which of the four options the evidence supports. Sometimes that answer is to keep your current partner.

Each phase has a defined scope and price before it starts, and the first one delivers a working part of the system. A named senior consultant leads the work through five stages you approve. Read how we scope a first phase in ERP implementation services. Book a free discovery call.

Sources

• The 2026 ERP Report, Panorama Consulting Group, October 2026
• Odoo Enterprise Subscription Agreement (version 13), Odoo, September 2026
• Odoo.sh and custom code ownership, Odoo, October 2026
• Solutions Partner for Business Applications, Microsoft Learn, October 2026
• Dynamics GP migration to Business Central, Microsoft Learn, October 2026
• ERP selection checklist, requirements, vendor evaluation and scoring template, Rand Group, October 2026
• Custom Module Cost, Reddit r/Odoo, checked October 2026
• Odoo in charging 30000 GST for accounting module, Reddit r/Odoo, checked October 2026