What is an ERP rescue or takeover?

A second firm assumes an implementation that another supplier started and could not finish. The work begins with an audit of what was configured and whether the numbers it produces are correct, because a takeover priced before that audit repeats the original mistake at a higher price.

How do I know whether our ERP project is actually stalled?

Take one finished transaction and follow it from order to ledger, then run one month-end close. If the numbers are right and late, you have a schedule problem and the existing team can usually recover it. If the numbers are wrong, you have a configuration problem and continuing with the same firm rarely works.

Can we keep any of the work already paid for?

Usually more than you expect. Master data, the chart of accounts, user training and process documentation frequently survive. What tends to be rebuilt is anything resting on a wrong costing or valuation decision, plus custom modules written because nobody found the native mechanism.

What happens to custom modules the previous firm built?

They are audited before anything else, because they carry the longest tail. Odoo's documentation states a database with custom modules cannot be upgraded until versions exist for the target release, and standard support runs three years per major version. A module that duplicates native behaviour is usually removed rather than carried forward.

Should we switch partners or push through?

Push through when the configuration is sound and the plan slipped. Switch when the configuration itself is wrong, when the firm cannot name who is doing the work, or when the same defect has been reported twice and explained twice without being fixed. The second is a capability signal rather than an effort signal.

How long does a takeover take?

The audit is usually days rather than weeks, because it is a defined piece of work with a defined output. The remediation depends entirely on what the audit finds, which is why an honest firm will not quote the remediation before running the audit.

What if the previous supplier still holds our system access?

Establish administrative access, the database backup, and the source repository for any custom modules before anything else. Those three are the practical dependencies of a takeover and they are easier to obtain while a commercial relationship is still civil.

Taking Over a Stalled ERP Project

Quick answer: before changing anything, establish whether your numbers are wrong or merely late. Late is a schedule problem the existing team can usually fix. Wrong is a configuration problem that rarely survives the same firm attempting it twice. That single test decides whether a takeover is warranted.

Local Context

A stalled system gets expensive fast in a market this industrial. Edmonton holds 1,872 manufacturing businesses with employees against Calgary’s 1,688, and 505 against 419 in the 20 to 199 employee band, on Statistics Canada’s July 2025 counts. Edmonton reaches those figures from a smaller base, 55,906 businesses against Calgary’s 65,639.

Most of that population is make-to-order. A shop running a wrong inventory valuation or an unreliable work order does not have a reporting inconvenience. It has jobs quoted from costs that were never accurate, which compounds into every subsequent quote off the same reference.

Seven Ways a Project Stalls

Recovery differs by cause, so name the one you have.

1. The supplier went quiet. Responses slow, then arrive weekly, then stop. Usually a resourcing problem at their end rather than anything about your account. Diagnostic: ask for the name and availability of the person assigned this week.

2. Go-live slipped repeatedly with no new information. Each delay is announced close to the date and nothing about the plan changes. This usually means the remaining work was never estimated.

3. It went live and the numbers are wrong. The system runs and the reports disagree with reality. The most serious case, and the one most often mistaken for a training problem.

4. The person who knew your build left. The firm continues and nobody remaining can explain why something was configured that way. Common with small suppliers and with large ones after a reassignment.

5. Scope grew until nothing shipped. Every session added requirements, none were traded away, and phase one never closed.

6. The custom modules outgrew the team. What began as a small extension became a system nobody wants to touch, and the next Odoo version now looks unreachable.

7. The supplier is capable, and not at this. An MSP or development firm doing genuinely good work in its own field, learning your ERP on your project. Nobody misled anybody. The staffing was wrong from the start.

The One Test That Decides Everything

Before any decision about suppliers, establish which of two problems you have.

Take one finished transaction and follow it end to end. A real customer order through to the ledger entry it produced. Then run one month-end close, or reproduce the last one.

Numbers correct, dates late: a schedule problem. Recoverable, usually with the existing team, usually by cutting phase one scope rather than changing supplier.
Numbers wrong: a configuration problem. The system is faithfully executing decisions that were incorrect. Continuing with the same firm rarely works, because they would have to find an error they could not see the first time.

This is checkable rather than a judgement call, and it is the single most useful hour a stalled project can spend.

What a Takeover Actually Involves

Stage one: the audit, before any proposal

A firm that quotes remediation before auditing is repeating the original error at a higher price. The audit establishes:

Whether the numbers are right. Inventory valuation, costing method, tax configuration, the chart of accounts, and whether stock reconciles to the ledger without a human.
What was customised, and why. Every custom module gets read. The question for each is whether native behaviour already covered it.
What data condition you are in. Duplicates, orphans, balances that do not tie.
What is genuinely finished. Usually more than the client believes.

Output is a written finding: what is sound, what is wrong, what it costs to correct, and what should be abandoned.

Stage two: secure the dependencies

Three things decide whether a takeover is straightforward or painful, and all three are easier to obtain while the existing relationship is still civil:

Administrative access to the production system.
A database backup you hold yourself.
The source repository for any custom modules, with its commit history.

Establish these early. A supplier relationship that deteriorates later makes each of them slower.

Stage three: correct, in dependency order

Valuation and costing first, because everything downstream inherits them. Then the transactional flows. Then reporting, which is usually the symptom rather than the disease.

Stage four: close phase one

The most common cause of a second stall is a takeover that inherits the original open-ended scope. Something has to go live, whatever else remains.

What You Can Keep

Clients routinely assume everything paid for is lost. It usually is not.

Usually survives	Usually rebuilt
Master data: customers, suppliers, products	Anything resting on a wrong costing or valuation decision
Chart of accounts, if it was designed well	Custom modules duplicating native behaviour
Process documentation and decisions made	Configuration built around an unresolved process dispute
User training and familiarity	Reports built on incorrect underlying data
Cleaned migration data	Integrations built without error handling

The custom modules are audited first because they carry the longest tail. Odoo’s documentation states that a database containing custom modules cannot be upgraded until a version of those modules exists for the target release, and standard support runs three years per major version with extended support carrying a mandatory fee. A module that duplicates something native is a permanent bill for nothing, and removing it is often the highest-value hour in the whole recovery.

Questions for the Incoming Firm

A takeover is a harder engagement than a fresh implementation, so the bar is higher.

How many takeovers of this product have you completed, and how many are live now?
What does your audit produce, how long does it take, and what does it cost?
Will you quote remediation before or after the audit? (Before is the wrong answer.)
Name the person doing the configuration work, and their last three projects on this product.
What have you found in a previous takeover that you chose to leave alone, and why?
What would make you tell us to stay with our current supplier?
How will you tell us something we paid for has to be discarded?

Question five and question seven matter most. A firm that rebuilds everything is selling a second implementation, and a firm that never delivers bad news will not deliver it to you either.

Handling the Existing Supplier

Two practical points, and this guide takes no position on any individual dispute.

Keep it civil until access is secured. The three dependencies above are far easier to obtain from a supplier who is not yet in a dispute.

Establish what your contract says about deliverables and ownership before raising the problem, particularly who owns custom code and what happens to it on termination. That is a question for your own counsel rather than for either supplier.

MRP and MES Software for Job Shops covers what a make-to-order shop actually needs configured.
Choosing an Odoo Partner for an Edmonton Shop covers the decision before a contract exists.
Why ERP Implementations Fail covers the causes in detail.