Before you approve an Odoo upgrade, ask your partner to walk through what the move will mean for your business: what will change for users, which customizations need work, what your team must contribute, and how you will decide the system is ready.
You do not need to arrive with a list of technical problems. Bring the processes your business depends on and ask the partner to explain how they will assess them. A useful planning meeting should leave you with a clearer scope, named responsibilities, and a short list of uncertainties to resolve before committing to a budget or launch date.
Use the questions below as a conversation guide. They follow the decisions you need to make together, from choosing the target version to agreeing support after launch.
First, agree what you are trying to achieve
1. “Why do you recommend this version for our business?”
Ask your partner to connect the target version to your priorities. Which problems would it solve? Which improvements would your staff actually use? Are there support or hosting deadlines that affect the decision?
If the proposal is to move to Odoo 20, ask for a demonstration of the relevant workflows in that version. A presentation of new features is a starting point; seeing how your sales, finance, or operations team would use them is more useful for deciding what belongs in the project.
Also ask whether the proposal includes changing edition or hosting. Those choices can introduce additional work and should be explicit in the scope.
Leave with: an agreed target version, the reasons for choosing it, and a clear distinction between the upgrade and any wider changes you are considering.
2. “What will change for our users—and can we simplify anything we customized?”
Give your partner a few examples of work that is awkward today: a manual approval, a spreadsheet used alongside Odoo, or a report that only one person knows how to produce. Ask whether the target version offers a better way to handle it.
Then ask the partner to review your existing customizations with you. Which should be kept? Which could be replaced with standard functionality? Which are no longer used?
For example, if you commissioned a custom approval process several years ago, ask the partner to demonstrate whether the target version can meet the same requirement without it. Agree any differences with the people who use the process before deciding to retire the customization.
This gives technical discovery a practical purpose: the team assesses the behavior you need to preserve and the improvements you might choose to make. You do not have to identify the underlying fields or methods yourself.
Leave with: a list of customizations to keep, replace, retire, or investigate, plus the user-facing changes that will need explanation or training.
Next, make the proposed work visible
3. “What do you need to inspect before you can give us a reliable quote?”
Ask what the partner has already reviewed and what remains unknown. A proposal based on a conversation and an app list has a different level of certainty from one based on your configuration, custom code, integrations, and representative business processes.
Useful material to prepare includes:
- Your installed apps, third-party addons, and the names of their maintainers.
- Custom reports, automated actions, Studio changes where applicable, and bespoke modules.
- Connections to your website, bank, shipping providers, payment services, and other business systems.
- Devices involved in daily work, such as scanners, printers, or POS equipment.
- Business exceptions: returns, partial deliveries, cancellations, unusual pricing, or approval rules.
You may not have a complete inventory. Ask the partner to explain how they will build one and what access they need. Agree how production data and credentials will be handled during discovery.
A useful follow-up: “Which unknowns could change the estimate most, and can we investigate those before approving the full project?”
Leave with: a defined assessment step and a list of dependencies to resolve, particularly third-party addons and external services that the partner does not control.
4. “What exactly is included in your upgrade proposal, and who owns the rest?”
Ask your partner to walk through the proposal as a division of responsibilities. For every activity, someone should be named—even if the answer is your own team or another supplier.
| Ask about | Clarify together |
|---|---|
| Database upgrade | Who performs it, prepares the test environment, and investigates migration issues? |
| Customizations | Who adapts retained modules, reports, views, and automated actions? |
| Third-party addons | Who confirms target-version availability and deals with the vendor? |
| Integrations and devices | Who updates them and arranges testing with external providers? |
| Business testing | Who prepares scenarios, runs them, fixes defects, and accepts the result? |
| Training and launch | Who prepares staff, manages the cutover, and supports the first days? |
Odoo's published Enterprise upgrade coverage includes standard applications and qualifying maintained customizations. Uncovered addons, data cleanup, and training need separate consideration. Ask the partner to explain what your actual subscription and service agreements cover. For Community, confirm the database migration approach and supplier explicitly. Odoo upgrade service scope
Leave with: a written scope showing included work, exclusions, assumptions, and responsibilities. Ask how additional work will be estimated and approved if discovery or testing reveals something new.
5. “How much time will you need from our team?”
An upgrade plan needs customer availability as well as developer availability. Ask when your department leads will need to explain processes, answer questions, test changes, and approve results.
Request a schedule showing those commitments. Who must attend discovery? How long is the testing window? How quickly will the partner need answers? Who can decide whether a changed workflow is acceptable?
Discuss periods when your staff cannot realistically participate: month-end, stocktaking, seasonal peaks, or planned leave. If only one person understands a critical customization, make their availability part of the plan early.
Leave with: named customer contacts, planned testing time, and a decision process for questions that would otherwise delay the work.
Then agree how you will know it is ready
6. “Can you show us how we will test our own business processes?”
Ask for a test plan built around the work your staff actually perform. Start with a few critical journeys and include the exceptions that matter to you.
For a business that sells and ships products, that might mean taking an order through delivery and invoicing, then handling a return or credit. A manufacturer might need to follow a production order through consumption and completion. A retailer might need to demonstrate a sale, payment, refund, and the preparation or printing steps used in its stores.
The partner should help connect these workflows to the configuration, customizations, and integrations they depend on. This is where technical findings belong: as reasons to add or adjust a relevant test, explained in terms your process owner can assess.
Ask what your team will receive before testing begins: access, representative data, instructions, expected outcomes, and a place to record defects. Agree who decides whether each issue blocks launch.
Odoo test databases neutralize certain external actions, including outgoing mail and scheduled jobs, and use test settings for payment and carrier services. Ask which connections will be tested safely and which checks must be completed during controlled production activation. Odoo testing guidance
Leave with: a workflow-based test plan, a business owner for each scenario, and agreed evidence of acceptance.
7. “What has to be true before we agree a go-live date?”
Ask your partner to distinguish a target date from a date supported by completed preparation. Which dependencies could still move it? Has the cutover been rehearsed? Are the required third-party modules available? Has your team accepted the critical workflows?
A simple decision sequence helps keep the conversation concrete:
- Scope understood: responsibilities, exclusions, and unresolved questions are recorded.
- Testing completed: business owners have accepted the critical workflows.
- Cutover rehearsed: the team has reviewed timing, communications, and the recovery approach.
- Launch agreed: named decision-makers have reviewed the evidence and agreed to proceed.
- Support ready: users know who to contact and what support is available after launch.
Agree the evidence needed at each checkpoint with your partner.
Also ask: “How long might the system be unavailable, what work must stop, and what happens if we cannot proceed as planned?” The answer should reflect your hosting setup and include who can make recovery decisions. Odoo specifically warns that a completed Odoo Online upgrade cannot be reverted to the previous version. Odoo production upgrade guidance
Leave with: the conditions for committing to the date, a cutover plan, and a named person on each side who can approve or stop the launch.
8. “Who will help us after launch, and when does the project end?”
Ask about the first working day as well as the launch window. Who will be available when staff begin processing real transactions? How should an urgent issue be reported? What response coverage is included?
Agree how the partner will distinguish an upgrade defect from a new request, and how unresolved issues will be handed over. Identify any activities that only happen later, such as a periodic report or month-end process, and decide how those will be covered.
Request updated operating instructions where workflows change. Your support team should know what was changed, what remains open, and who maintains each customization or connection.
Leave with: a support arrangement, ownership of remaining issues, and clear criteria for closing the upgrade project.
Send this before your planning meeting
You can adapt the following message for your partner:
We are preparing our Odoo upgrade and would like to agree the scope before committing to a delivery date.
Please come ready to discuss the recommended target version, changes our users should expect, and what you need to inspect to assess our customizations and integrations.
We would also like to understand what your proposal includes, the time required from our team, how we will test our business processes, and the conditions for agreeing go-live and post-launch support.
We will bring our critical workflows, known customizations, external systems, and business calendar. Please identify anything else you need from us and any uncertainties that should be resolved before a firm estimate.
Download the partner planning worksheet (CSV) to record answers, owners, and next steps during the conversation.
You do not need every answer in the first meeting. You do need to know which answers are missing, who will obtain them, and which decisions depend on them.
Give technical discovery a place in the plan
When custom addons are involved, ask your partner for an assessment of their compatibility with your actual source and target versions. They can use VersionBridge's free code scan to support that work, then explain the findings in relation to the workflows you have agreed to preserve.
For a move to Odoo 20, the 19→20 technical migration guide and the other version-specific guides provide further detail for the developer doing that assessment. Your customer-facing deliverable should be a clear explanation of affected processes, proposed work, and tests—not an unexplained list of code changes.