Switching Odoo partners mid-implementation in Bangladesh.

Why This Happens in Bangladesh

A vendor relationship breaking down mid-implementation is not rare in Bangladesh's Odoo market, and it is not always a sign that anyone acted in bad faith. It happens for a handful of recurring reasons, and knowing which one you are dealing with changes how the rest of this transition should go. The vendor missed deadline after deadline until the client's confidence ran out. The delivered work quality was poor, workflows that technically function but do not match how the business actually operates, reports that are wrong, approval chains that were never built. Support went silent, calls and messages unanswered for weeks during an active project. Or, less common but real, the vendor itself went out of business or lost the specific consultants who understood the project, which happens more often than buyers expect in a market where implementation firms are frequently small, thinly staffed, and dependent on one or two senior people.

Whichever of these it is, the business now sits in an uncomfortable middle state: partially configured, partially trained, partially migrated, with money already spent and a live business that cannot simply pause while a new vendor starts from a blank page. This piece is about navigating exactly that middle state without repeating the mistakes that got you here, and without pretending a clean restart is free just because it feels safer than diagnosing what can be salvaged.

A failed vendor relationship is a project problem. Treating it as a shameful secret to hide from staff is what turns it into an organizational one.

The Technical Handover Audit

Before any decision about the future gets made, someone needs to establish, factually and without the outgoing vendor's spin, what actually exists in the system today. This is the single most important step in the entire transition, and it is the one most Bangladesh businesses skip because they are in a hurry to feel like progress is being made again.

A proper technical handover audit, which I run as a distinct, paid engagement before agreeing to anything about the path forward, covers four things specifically. What is actually configured, module by module, compared against what the original scope document or Business Requirements Document promised, because the gap between promised and delivered is usually wider than either side remembers accurately. The state of any custom code: is it documented, does it live in a version-controlled repository the client can access, or does it exist only on the outgoing developer's laptop. The state of data migration: what has been imported, what is still sitting in spreadsheets, and whether historical data that was migrated is actually correct or was imported hastily to hit a milestone deadline. And database and infrastructure ownership: who controls the hosting account, the domain, the admin credentials, and whether the outgoing vendor has any technical lever (an expiring hosting subscription, an un-transferred domain) that could be used as leverage during a dispute.

This audit almost always surfaces at least one uncomfortable finding: a module invoiced as complete that barely functions, a "trained" department that received one demo session, or data migration marked done in a status report that turns out to be a partial import missing two years of transaction history. This is not a reason to panic. It is the actual information you need to negotiate the commercial settlement and to scope the new partner's work honestly, rather than discovering these gaps three months into a second implementation.

The Commercial and Contractual Reckoning

Parallel to the technical audit, there is a commercial conversation that has to happen, and it is usually more emotionally charged than the technical one because it involves money already spent on work that clearly did not deliver what was promised. Two questions matter here: what have you already paid for that was not delivered, and what do you still owe under the contract regardless of how you feel about the vendor's performance.

Go back to the original contract and map every milestone payment against what was actually delivered at that milestone, using the technical audit's findings as evidence rather than argument. If a milestone was paid for "discovery and BRD sign-off" and no usable BRD exists, that is a specific, documentable gap, not a matter of opinion. This mapping exercise is what turns an emotional dispute ("this vendor was terrible") into a commercial negotiation with specific, defensible numbers attached to it.

Separately, review what termination actually requires under the contract's own terms: a notice period, a cure period where the vendor gets a final chance to fix specific issues, and any early-termination penalty clause. Terminating a contract outside its own terms, even when the vendor's performance clearly justifies it, can expose you to a counter-claim. This is uncomfortable when you are eager to simply move on, but it is exactly the discipline that protects you if the dispute ever escalates to a formal legal claim. The escalation sequence covered in the Odoo Vendor Red Flags article, documented memo, senior escalation, formal notice of breach, is the same sequence that should already be in your file by the time you reach the termination conversation, because it is what demonstrates you acted reasonably rather than impulsively.

Who Owns the Custom Code

This question surfaces late in almost every transition, usually when the incoming partner asks for the source code to a custom report or automation and the outgoing vendor hesitates. The answer depends entirely on what the original contract said, and this is exactly why the contract clause matters more than it seems to at signing time.

Most reasonably drafted Bangladesh Odoo contracts specify that custom modules built specifically for the client, paid for by the client, become the client's property on payment, while the underlying Odoo platform itself remains under its own license (open-source for Community edition modules, Odoo S.A.'s proprietary license for Enterprise-only code). If your contract says this clearly, the outgoing vendor has no legitimate basis to withhold source code once outstanding invoices are settled, and withholding it anyway is itself grounds for escalation. If your contract is silent on IP ownership, and a surprising number of Bangladesh implementation contracts are, this becomes a genuine negotiation point, sometimes the single hardest point, in the termination discussion. This is the clause I now tell every client to have reviewed explicitly before signing their next implementation contract, specifically because I have watched this exact gap cost a client weeks of delay negotiating for code they had, in every reasonable sense, already paid for. The broader set of contract terms worth locking down before signing, SLA definitions, named resources, termination rights, is covered in Negotiating an Odoo Enterprise Contract and SLA.

The Staff Confidence Reset

The part of this process that gets the least attention, and that I think matters as much as anything technical, is what a failed first attempt does to the people who have to actually use the system every day. Staff who sat through months of confusing configuration, contradictory training sessions, and a go-live date that kept moving are not neutral about a second attempt. They are, reasonably, skeptical, and some of them have quietly gone back to their old spreadsheets and workarounds because those, at least, work.

Ignoring this dynamic and simply announcing "we have a new vendor, training starts Monday" repeats the exact top-down pattern that damaged trust the first time. What actually rebuilds confidence is deliberate and slower than it feels comfortable being: an honest internal communication about what went wrong with the first vendor, framed around the project rather than blaming individuals, and a visible role for department representatives in the new discovery process rather than a repeat of decisions being made about them without them. It also means the new partner needs to demonstrate competence early and specifically, correcting one visibly broken thing that everyone in the department has been complaining about for months is worth more, in trust terms, than a polished new project kickoff presentation.

Setting a conservative, realistic timeline for the second attempt matters more here than it would on a first implementation, precisely because this audience has already learned what an overpromised date looks like when it slips. A team told "12 weeks" who watch the deadline pass without explanation the second time will disengage from the project in a way that is genuinely difficult to recover from a third time. Change management on a recovery project is not the same exercise as change management on a fresh one, and treating it identically is a common, avoidable mistake. For the broader discipline of managing this kind of internal resistance, not as a one-time announcement but as an ongoing process, see Change Management Isn't a Memo.

Salvage or Restart: A Real Framework

This is genuinely the hardest decision in the whole process, and I am suspicious of anyone who gives a blanket answer to it without having seen the specific system. What follows is the actual set of criteria I use, not a universal rule, because the right answer depends on where in the build the failure occurred.

Lean toward salvage when: the foundational configuration, chart of accounts, core master data structure, primary workflow logic, is sound and matches how the business actually operates. The gaps are concentrated in specific modules, missing documentation, or incomplete customization rather than structural problems. Staff have already invested real time learning the current interface and workflows, and a full restart would waste that learning on top of everything else already lost. The data migrated so far is accurate, even if incomplete, meaning the effort to finish it is additive rather than corrective.

Lean toward restart when: the core configuration itself is wrong in a way that will not scale, a chart of accounts that does not match statutory or Mushak reporting requirements, for example, or a data model built around a misunderstanding of how the business's production or sales process actually works. Custom code exists with no documentation and no realistic way to safely modify it without risking data integrity. The migrated data itself is unreliable, not just incomplete, meaning trusting any of it going forward would embed errors permanently. And when the psychological cost of continuing to work inside "the old vendor's system," even under new management, is itself an obstacle to staff genuinely re-engaging with the project.

In practice, most of the failed mid-projects I have assessed land closer to salvage than restart, because the technical failure is usually concentrated in specific modules or in support responsiveness rather than in the foundational architecture. But I have recommended a full restart more than once, and in every one of those cases the client's instinct going in was to salvage, purely to avoid feeling like the sunk cost was wasted. Sunk cost is a real psychological pull here and it is worth naming explicitly, because it is exactly the bias that leads businesses to keep patching a structurally broken foundation rather than accepting the more expensive but ultimately cheaper choice of starting the configuration cleanly.

The Transition Sequence, In Order

Pulling the above together, the sequence I recommend to clients navigating this, in order, is: secure the database backup and file attachments immediately, before any confrontation. Run the technical handover audit as a distinct, scoped, paid engagement, not a favor squeezed into a sales pitch from the incoming partner. Reconcile the commercial position, milestone payments against actual delivery, against the original contract terms. Resolve IP ownership of custom code explicitly, in writing, before final payment settlement. Make the salvage-or-restart decision based on the audit evidence, not on sunk-cost instinct. Communicate honestly with staff before the new partner's work becomes visible to them, not after. And only then, begin the new partner's actual configuration or remediation work, with a conservative, evidence-based timeline rather than a repeat of the promise that failed the first time.

None of this makes a vendor transition painless. It makes it survivable, and it meaningfully reduces the odds of ending up in this exact same article again eighteen months from now with a third vendor. If you are still in the selection phase for either your first or your replacement partner, the criteria that would have prevented this in the first place are covered in the Odoo Partner Selection guide.

Frequently asked questions

Can you switch Odoo partners mid-implementation without losing your data?

Yes, in almost every case. Your data lives in a PostgreSQL database that you own regardless of which partner configured it. Request a complete database backup, including file attachments and any custom module source code, before initiating a formal exit conversation with the outgoing vendor. The genuine risk is not data loss but undocumented customization: if the outgoing partner wrote custom code without documentation or a shared repository, the incoming partner needs time to reverse-engineer it before they can safely modify or upgrade it.

Should you salvage the existing Odoo configuration or start over?

This depends on a structured audit, not instinct. Salvage the build when the core configuration is fundamentally sound and the problems are isolated to specific modules, missing documentation, or incomplete customization. Restart when the foundational configuration itself is wrong, for example a chart of accounts that does not match statutory requirements or a data model that will not scale, because incremental fixes on a broken foundation typically cost more in the long run than a clean rebuild.

What should a new Odoo partner check before taking over a failed implementation?

A proper technical handover audit covers: what modules are actually installed and configured versus what was promised in the original scope document, the state and completeness of any custom code and who owns its intellectual property, the current state of data migration including what has and has not been imported, database access and hosting ownership, and a comparison between the original Business Requirements Document and what has actually been delivered. This audit typically takes 1-2 weeks and should be a paid, scoped engagement.

Who owns custom code built by an Odoo partner during a failed implementation?

This depends entirely on the contract signed with the outgoing vendor. Most well-drafted Bangladesh Odoo implementation contracts specify that custom modules built specifically for the client become the client's intellectual property upon payment, while the underlying Odoo framework remains under its own open-source or proprietary license. If the contract is silent on IP ownership, this becomes a negotiation point during termination, which is a strong reason to have this clause reviewed before signing any future implementation contract.

How do you rebuild staff confidence after a failed Odoo rollout?

Staff who have already been through one disrupted rollout are rightly skeptical of a second attempt, and that skepticism needs to be managed deliberately rather than dismissed. This means being honest with staff about what went wrong the first time, involving department representatives visibly in the new vendor's discovery process rather than repeating a top-down rollout, and setting a realistic, conservative timeline for the second attempt rather than repeating the same overpromise that damaged trust the first time.