Most Odoo implementations that go over budget or over schedule do so for predictable reasons. The scope was underestimated. Legacy data was messier than expected. The internal team didn't have capacity to participate. Custom modules from the previous system had no documentation. A key stakeholder changed their mind after UAT.
None of these are rare. All of them can be surfaced - or at least anticipated - if you ask the right questions before you commit.
This checklist is organized by phase: vendor evaluation, scope and data, internal readiness, technical baseline, contract terms, and post-launch planning. Use it before you sign the implementation contract, not after.
Vendor evaluation (10 questions)#
1. How many Odoo implementations has your team completed in the past 24 months in our industry?
General Odoo experience and industry-specific experience are different things. An integrator with 50 retail implementations has almost no applicable knowledge for a manufacturing or professional services deployment.
2. Will you show us three references we can call - not email - from clients with similar scope?
References who agree to a phone call are more revealing than written testimonials. Ask them: did the project finish on time? What broke after go-live? How was the support experience in month three?
3. Who is the actual project lead assigned to our engagement, and what is their Odoo certification level?
Proposals often feature senior consultants who are not involved in delivery. Confirm the person doing the configuration work, not the person in the sales presentation.
4. What is your standard approach when the project scope expands during discovery?
Scope growth is almost universal. Ask for a concrete example: "Tell me about a project where scope expanded and how you handled the contract and timeline adjustment." Vague answers are a warning sign.
5. How do you handle Odoo version upgrades after go-live?
Odoo releases a new major version every year. An integrator who has never helped a client migrate from version 16 to 17 will not have a reliable upgrade path for you.
6. Do you build custom modules for this engagement, or do you rely on Odoo apps from the marketplace?
Third-party marketplace modules can accelerate timelines but create dependency on a third-party publisher for updates and bug fixes. Know what you are taking on.
7. What is your standard SLA for post-go-live support?
Ask specifically: what is the response time for a critical production issue (payroll blocked, orders not processing)? How is "critical" defined in the contract?
8. What does your typical handover to the client look like at project close?
Good integrators produce documentation: module configurations, custom code with comments, training materials, an admin guide. Integrators who do not document make you permanently dependent on them.
9. Have you worked with our current ERP or accounting system before?
Data migration from Sage, QuickBooks, SAP, or a legacy custom system is categorically different for each source. Integrators who have migrated from your specific source system will have existing transformation scripts and know where the edge cases are.
10. What percentage of your implementations finish within 10% of the original timeline?
This is a direct question most vendors will dodge or inflate. Push for an honest answer; compare it against what former clients say.
Scope and data (12 questions)#
11. Which Odoo modules are in scope, and which are explicitly out of scope?
Get the module list in writing before signing. "We'll implement what you need" is not a scope boundary.
12. Are there any requirements you have not handled in Odoo before?
Ask directly. A consultant who hesitates or qualifies their answer needs follow-up. Unknown requirements are where budgets overrun.
13. How will you handle the gap between what Odoo can do out of the box and what our processes require?
Every implementation has process gaps. The question is whether gaps get resolved by changing the process (cheaper), configuring Odoo (manageable), buying a third-party module (dependency risk), or writing custom code (expensive and ongoing maintenance burden).
14. What data do we need to migrate, and in what format does your team need it?
Get the full list: customers, vendors, products, inventory, open purchase orders, open sales orders, account balances, assets, employee records. For each one, ask what format and what validation rules apply.
15. What data will not be migrated and why?
Historical transactions that are not migrated need to be accessible somewhere - even if it is just a frozen CSV export. Know the plan before go-live.
16. How much cleanup will our data require before migration can start?
Most companies discover their data is inconsistent, duplicated, or formatted differently across sources. This cleanup typically falls on your internal team and is never in the integrator's budget.
17. Are there any regulatory or compliance requirements that affect the implementation?
Industry-specific requirements (FDA validation, financial audit trail, GDPR data residency, SOC 2 controls) can add months and cost to an otherwise standard implementation. Surface these early.
18. How will you handle open transactions on cutover day?
Orders in progress, invoices pending approval, partially completed manufacturing orders - these need a clear cutover protocol. Some integrators hard-cut on a weekend; others run parallel systems. Know the plan and its risks.
19. What integrations with external systems are in scope?
Every integration with a third-party system (shipping carriers, e-commerce platforms, payment processors, warehouse management systems, banking feeds) is a project within the project.
20. What happens to the integration if the third-party system changes their API?
This is ongoing maintenance, not a one-time build. Understand who owns it after go-live.
21. Will we own the custom code at project close?
The answer should always be yes. Some integrators use proprietary modules that you license but do not own. Verify IP ownership in the contract.
22. What is the testing plan and who is responsible for UAT?
User acceptance testing is largely your team's job - the integrator cannot test your business processes. Ensure you have internal capacity allocated for this work.
Internal readiness (8 questions)#
23. Who is our internal project owner, and what percentage of their time is allocated to this project?
A project owner who is "doing this on the side" of their regular job is the single most reliable predictor of a delayed implementation. This role needs real capacity - typically 30–50% for a mid-size implementation.
24. Which department heads are involved in scope validation, and have they committed time in the project plan?
Accounting, operations, HR, and sales all have requirements. If you cannot get the accounting manager in a room to validate the chart of accounts mapping before the project starts, you will revisit it after go-live.
25. Do we have someone internally who can serve as the Odoo administrator after go-live?
The Odoo administrator manages users, security, basic configuration, and module updates. If your entire Odoo knowledge walks out the door when the integrator finishes, you are fully dependent on external support for routine changes.
26. What is the change management plan for end users?
Odoo changes workflows. Users who are not trained, not bought in, and not supported will find workarounds outside the system. Change management is not a training event - it is a sustained effort that starts before go-live.
27. Do we have a parallel run strategy, and what is the minimum period?
Running the old and new systems simultaneously is expensive but reduces risk. Even a two-week parallel run catches discrepancies that only appear in real operations.
28. What is our fallback plan if go-live is delayed?
If the project slips by four weeks, what happens to payroll, billing, and order management? Know the contingency before you need it.
29. Which business processes will be disrupted during the implementation, and have we communicated this to affected teams?
Configuration workshops, training sessions, and data cleanup all pull people away from their normal jobs. Communicate this in advance, not during.
30. Have we internally agreed on which business processes we will adapt to Odoo's standard workflow?
The most expensive Odoo implementations are the ones where every process gap gets resolved with custom code. Decide upfront which processes are worth customizing and which processes the business will adapt to Odoo's defaults.
Technical baseline (8 questions)#
31. What is the current state of the codebase if we are upgrading from an older Odoo version?
Older Odoo codebases often have undocumented customizations, deprecated modules, and technical debt. A code audit before the project starts is money well spent.
32. How many custom modules does our current Odoo instance have?
If you are coming from an existing Odoo installation, get the exact number. More than 20 custom modules on a standard edition typically signals a multi-month migration effort.
33. Are there any custom modules with no source code available?
Custom modules built by a previous integrator may exist only as compiled .pyc files. Without source code, migration to a new version is a rewrite.
34. What hosting environment will Odoo run on post-go-live?
Odoo SaaS, Odoo.sh, self-hosted on cloud infrastructure, or on-premises each have different implications for maintenance, backup, uptime, and cost. Understand the hosting model before you go live.
35. How will the production environment differ from the test environment?
Differences in database size, server specs, and network configuration between staging and production cause surprises at go-live. Ask specifically what is different.
36. Who manages the hosting and database backups?
This should be in writing. If the answer is "the cloud provider handles it," ask when the last backup restore was tested and what the recovery time objective is.
37. What is the process for applying Odoo security patches?
Odoo releases security patches on a roughly monthly schedule. Understand who monitors these, who applies them, and how quickly they get deployed.
38. Do we have a disaster recovery plan for the Odoo database?
In a hardware failure or ransomware scenario: where is the backup, how old is it, and how long does restoration take? If nobody knows the answer, this is a risk to address before go-live.
Contract terms (5 questions)#
39. What is the change order process and typical pricing?
Every change to scope after the project starts should go through a formal change order. Ask for a sample change order and understand how scope changes are priced and how long approval takes.
40. Is there a cap on the number of revisions included in the fixed-fee engagement?
"Unlimited revisions" in a fixed-fee contract is a fiction. Ask what specifically is included and what triggers additional fees.
41. What happens to the project if a key consultant leaves mid-engagement?
Consultant turnover is common. The contract should address knowledge transfer and the integrator's obligation to staff the project with qualified replacements.
42. Is there a warranty period for delivered customizations, and what does it cover?
A 30–90 day warranty for custom code is standard practice. If the integrator does not offer any warranty, that is a signal about their confidence in their own work.
43. What are the payment milestones, and what deliverables trigger each payment?
Payment milestones should be tied to verifiable deliverables, not to calendar dates. "25% on project start" gives you no recourse if the project stalls after the check clears.
Post-launch planning (4 questions)#
44. What support model applies after go-live, and what does it cost?
Many implementations are sold with a go-live support package that has a fixed end date. Know what happens when it expires and what ongoing support will cost.
45. How will we handle Odoo version upgrades in the next 18 months?
If you implement Odoo 17 today, Odoo 18 will be stable within 12 months. Have a conversation about the upgrade path before you sign the implementation contract.
46. What documentation will be delivered at project close?
Ask for a list. At minimum: module configuration guide, custom code documentation, user training materials, admin runbook for common tasks, and a data dictionary for custom fields.
47. How will we measure whether the implementation was successful?
Define success metrics before the project starts: order processing time, invoice error rate, inventory accuracy, month-end close duration. Without measurement, "success" is whatever the integrator says it is.
Using this checklist#
Print it. Bring it to your first vendor evaluation meeting. Any integrator who is uncomfortable with these questions is not the integrator you want.
The questions that generate vague or defensive answers are the ones to press on. In most cases, a project that fails post-go-live had a clear warning signal in the pre-contract conversation - it just wasn't followed up on.
If you are in the discovery phase and trying to understand what custom code exists in an existing Odoo instance - what it does, what it touches, where the risks are - ERPeek gives your implementation team a structured way to ask those questions before the project plan is finalized.