In this piece
Odoo Enterprise upgrades: what still needs a project budget?
Your Enterprise subscription includes an upgrade service. A partner then proposes a migration project with discovery, custom work, testing and training. Before deciding whether the proposal is reasonable, establish which work the subscription covers and which business responsibilities remain.
Treat the Enterprise upgrade service as one evidenced workstream inside the migration project. Price the additional responsibilities your agreement does not settle, including uncovered adaptations, business validation, cleanup and enablement. Give each line a delivery owner, acceptance output and commercial reference. Keep unknown fees visibly unpriced instead of assuming they are zero.
Research checked: 5 November 2026. We inspected the official 20.0 agreement and upgrade documentation. The effort ledger is a hypothetical planning example, not a quotation, market-rate benchmark or executed upgrade. Check your applicable agreement and order before treating a work item as covered.
What does the included upgrade service cover?
The useful boundary is the deliverable covered by the agreement. Establish what the technical conversion includes, then identify who validates business behavior and adapts anything outside that coverage. An included conversion line can coexist with a substantial project; it does not establish that every proposed project line is necessary or separately chargeable.
The published Enterprise agreement, version 13 dated 24 September 2026, covers technical database conversion and covered extra-module conversion. It assigns validation and adaptation of non-covered extensions to the customer.
The upgrade guide excludes pre-existing cleanup, uncovered extra modules and training. Studio coverage has stated installation and subscription conditions. These distinctions are reasons to check coverage, not to label all customization either included or excluded.
Ask the delivery team to map its proposal to the applicable documents. A line described as “migration” is too broad for comparison. Is it the conversion request, an uncovered module adaptation, a reconciliation exercise or business training? Each has a different completion condition and may have a different delivery owner.
How do you turn that boundary into a statement of work?
Create a scope ledger before arguing about the total. Every workstream needs a concrete output, a delivery owner and a reference establishing whether it is covered, additional or unresolved. Separate technical delivery from business acceptance. A supplier can complete a work item while your process owner still has an acceptance decision to make.
| Workstream | Question to settle | Reviewable output |
|---|---|---|
| Technical database conversion | Which service and agreement cover this database and target? | Converted test database and recorded conversion issues |
| Customizations | Which items are covered, maintained elsewhere or to be retired? | Named module/configuration inventory with responsibility |
| Interfaces | Who checks the external system and the resulting business state? | Agreed interface acceptance evidence |
| Data and reporting | Which differences need explanation and who approves them? | Reconciliation record and explicit exceptions |
| People and procedures | Which roles must learn a changed workflow? | Updated procedure and named readiness owner |
| Cutover and stabilization | Who controls the window, handoffs and unresolved incidents? | Approved runbook and support responsibility |
Use three commercial states: confirmed covered, confirmed additional and unresolved. Record the evidence date and the person who can settle an unresolved line. Do not subtract a cost from the project merely because someone believes it belongs in the subscription. Equally, do not pay a second time for the same output without understanding the additional work being offered.
Keep customer effort visible. Finance, sales, operations and the integration owner may need to judge results that a conversion service cannot accept on their behalf. If their time is absent from the schedule, the project can appear technically ready while nobody is available to decide whether the business can use it.
Which customizations need an explicit coverage decision?
Inventory the actual customization before deciding its budget category. Record what it does, how it was created, its maintained version and its coverage evidence. Then decide whether to retain, replace or retire it. A module count alone does not describe the adaptation effort or prove that the existing maintenance arrangement covers the target work.
Do not turn “custom” into a single commercial bucket. A Studio change, a maintained extra module, an uncovered connector and a report adjustment can have different responsibilities. Ask for the exact item and the relevant maintenance or subscription reference. If a workstream is already covered, specify any separate coordination or acceptance service being quoted.
Odoo’s customized-database guide separates installation compatibility from runtime testing and rehearsal. That supports an important procurement distinction: “the module installs” and “the business accepts its behavior” are different outputs.
For a fictional discount extension, the inventory might record a retained business rule, the module maintainer, confirmed conversion coverage and a sales-owner acceptance case. For an obsolete report, the decision might be retirement after users approve a standard replacement. Neither example supplies evidence about your modules; both show what a useful scope entry should resolve.
How does a hypothetical project budget add up?
Price explicit work assumptions and preserve the unknowns. The example below assigns 84 external delivery hours and 20 internal acceptance hours. Its rates are invented, not market guidance. It produces a known-work subtotal; maintenance adjustments, subscription changes and other unpriced commercial lines remain outside that subtotal until written evidence resolves them.
| Workstream | Assumed hours | Assumed rate | Amount |
|---|---|---|---|
| Inventory and coverage review | 8 external | €120/hour | €960 |
| Uncovered custom adaptation | 24 external | €120/hour | €2,880 |
| Integration verification | 16 external | €120/hour | €1,920 |
| Data reconciliation support | 12 external | €120/hour | €1,440 |
| Training and procedure updates | 8 external | €120/hour | €960 |
| Cutover preparation | 8 external | €120/hour | €960 |
| Stabilization allowance | 8 external | €120/hour | €960 |
| Business-owner acceptance | 20 internal | €60/hour | €1,200 |
| Known-work subtotal | 84 external + 20 internal | Mixed | €11,280 |
A separate, conditionally authorized reserve of 16 external hours at €120 would add €1,920. That produces a known-work ceiling of €13,200 before unpriced lines. It is a chosen example allowance, not a statistically justified contingency or permission for a supplier to consume it automatically.
Download the scope and budget ledger and Python subtotal calculator. Run python3 upgrade_scope_budget.py scope-budget.csv. The calculator uses the standard library, makes no Odoo connection and reports the three unpriced lines explicitly.
Replace hours and rates only after reviewing your scope. The unpriced lines are maintenance or coverage adjustments, subscription or hosting changes, and other third-party fees. Taxes and additional exclusions also need their own treatment. Calling €11,280 the complete project price would conceal those open inputs.
How can two proposals describe different projects?
Normalize scope and acceptance outputs before comparing totals. One proposal may stop at a converted database; another may include interface checks and business enablement. A higher total can represent more work, while a lower total can leave necessary work with your staff. Neither price alone establishes the better offer.
| Proposal wording | Question to ask | Required clarification |
|---|---|---|
| “Upgrade included” | Which conversion output is covered, and who validates the business? | Separate service coverage from customer acceptance effort |
| “All customizations migrated” | Does the inventory include external connectors and retired features? | Named items, exclusions and acceptance conditions |
| “Fixed migration price” | Which assumptions can trigger a change request? | Scope baseline, change process and unpriced dependencies |
Ask both providers to price the same ledger. If one excludes an item, identify who will deliver it and how its acceptance joins the rest of the project. If one includes a redesign, make that an explicit option. Otherwise a comparison of prices becomes a comparison of different ambitions.
Use the Odoo migration acceptance and reconciliation guide to define substantive acceptance evidence. This article owns the purchasing boundary, not a replacement test plan. For API constraints and release timing, use the Odoo integration limits guide.
What should be settled before the go-live date is booked?
Settle the work owners, acceptance owners and commercial unknowns that can change the plan. Confirm who is available to make each business decision and who handles a failed check. A proposed date becomes credible when the remaining work has a bounded scope and evidence, not merely when a technical conversion request can be submitted.
The approval record should link the coverage inventory, accepted target scope, remaining defects and commercial decisions. It should state who controls the cutover and the conditions for proceeding. Keep the actual rehearsal and migration acceptance work in the implementation plan; this budget ledger only makes the responsibility visible.
If AI features are part of the target scope, add the separate Odoo 19-to-20 AI readiness review. If the project already lacks a reliable owner or usable evidence, the Odoo rescue and partner-change guide addresses that different decision.
What would we approve first?
Approve a bounded inventory and coverage review before committing to a full project price or date. Require a named output and owner for each line, then price the confirmed additional work. Keep the included service visible, customer acceptance scheduled and unpriced fees explicit until the evidence supports a complete purchasing decision.
If the upgrade becomes a redesign discussion, use the standard software versus custom development guide to decide that scope separately. The Twinsoft AI case study offers separate delivery context; it does not establish these hypothetical Odoo hours or rates.
Wavect’s technology consulting can help make the scope reviewable. Discuss an Odoo upgrade proposal with the current agreement, customization inventory and draft statement of work.