Custom Development Migration Audit

0 · About this report

Growdoo has audited eight custom and third-party Odoo addons currently running on ACME Customer's Odoo 18.0 instance, totalling approximately 2,800 lines of code. This report estimates the effort required to migrate these addons to Odoo 19.0, including database schema upgrades. All hour estimates follow a standard methodology (TRIVIAL=0.5h, SIMPLE=1.5h, MODERATE=4h, COMPLEX=8h, MAJOR=16h) multiplied by version-gap risk and code-review overhead; actual effort will vary based on test coverage and deployment readiness. Sections 1–3 are written for business stakeholders and summarize cost, risk, and timeline; Sections 4–6 are for your technical team and detail code patterns, API changes, and migration tactics.

1 · Executive summary

ACME Customer is preparing to upgrade from Odoo 18.0 to 19.0. This audit covers eight addons and forecasts a total migration effort of 40 hours, comprising 32 hours of code rework and 8 hours for database upgrade.

Code distribution

Effective lines of code per language across all 8 addons (blank lines and comment-only lines excluded). Total: 11,368 LOC.

Master table — sorted by risk, then estimated hours

2 · High-priority items

2 addons require attention from project leadership before migration begins.

3 · Strategic recommendations

3.1 What to buy, not build

Five of your eight addons are available on the Odoo marketplace or OCA, representing 9 hours of implementation work that can be purchased rather than built. Buying these reduces custom code surface area, lowers long-term maintenance risk, and ensures you inherit vendor updates. Purchasing removes the need for your team to debug or refactor printnode, label designer, and filter modules during your migration.

3.2 What to drop

No addons in this scan are clearly replaced by Odoo native features. Validate during the technical pass whether the product translation lock (fanatics_disable_product_translation) can be achieved through Odoo's standard language settings, and whether the BOM Excel export can leverage native reporting.

3.3 What to consolidate

The printnode_base and zpl_label_designer_printnode modules form a coupled pair—ensure both are migrated together and tested as a unit to avoid print job failures. No other consolidation opportunities are evident from the scan.

3.4 Suggested migration phases

3.5 Testing strategy

Set up a parallel run environment where both your old Odoo instance and the migrated v18 system process print jobs and BOM exports simultaneously for 1–2 weeks. Assign your warehouse and operations team to UAT on the new system while your finance team validates the ACME Customer integration logic. Automate regression tests for the label designer, print queue, and filter features using the Odoo test framework; run these daily during Phase 2 and Phase 3. Have your vendor or OCA maintainer review the printnode and label designer configurations before going live to catch any environment-specific issues early.

4 · Technical deep dive

Per addon: source version, tier, strategy, key risk patterns and estimated hours. The language-mix totals across all addons are shown in the executive summary above. Risk patterns column lists the methodology detectors that triggered, with their occurrence counts.

5 · Batch migration opportunities

Sets of addons that share patterns and can be fixed in bulk to save engineering hours.

• Marketplace Addons — Direct Purchase Path · ~6–8 hours. Eliminates custom migration coding, ORM refactoring, and frontend compatibility testing. Vendor review+deployment cycle (1.3× multiplier built into final_dev_hours) is already factored; net savings vs. manual migration of ~30–35 hours across the group.
  printnode_base, tree_view_advanced_filter, zpl_label_designer, zpl_label_designer_printnode, and sale_order_line_date. All are available on apps.odoo.com for Odoo 19.0 (or noted as version-available with vendor confirmation required).
• Custom Utilities — ORM Deprecation Refactoring · ~4–6 hours if bundled review and test automation applied. Both modules use similar deprecated patterns; a shared refactoring checklist and test harness can be reused.
  fanatics_x_acme (3 deprecated move-lines) and printnode_base (7 deprecated move-lines if manual). Pattern: move_line.create() / write() on proxied lines must be refactored to account.move.line ORM API changes in v19.
• Trivial Custom Modules — Batch Code Review · ~0.5–1 hour. Group them into a single code-review session and one deployment slot to minimize context-switch overhead.
  fanatics_disable_product_translation (27 LOC) and fanatics_bom_excel_report (97 LOC). Both are TRIVIAL tier with no framework dependencies.

6 · Methodology & assumptions

• Estimates assume a senior Odoo developer (5+ years, migration tooling proficient).
• Hourly rate is NOT included — the customer applies their own rate or vendor quote.
• The 1.3× multiplier (built into per-addon hours) covers code review, staging deployment, regression test execution and client handoff (~23% of total migration effort that is not coding).
• Not included in the technical estimate: project management, customer coordination, requirements clarification and a buffer for unforeseen complications. These are sized separately in §1.5 (20% project management + 10% risk reserve = +30% on top of the technical number). Real-world projects of this kind typically land 20-40% above the bottom-up technical estimate; we use 30% as the default mid-point.
• Estimates cover: manifest analysis, code migration, code review, smoke testing, staging deployment.
• Estimates do NOT cover: data migration, server infrastructure changes, end-user training, UAT facilitation.
• Market availability (apps.odoo.com + OCA GitHub) was checked at audit time — verify before purchase decisions.
• OCA module deltas (differences between OCA standard and your customised version) must be reviewed before switching to OCA.
• Test files are excluded from LOC counts — tests are rewritten, not migrated line-by-line.
• Database upgrade is a fixed line item (8 hours): running the upgrade service, verifying data integrity, fixing upgrade-script failures, smoke-testing core workflows.

Methodology version v3.0 · Audit produced by Growdoo (Radical Fanatics).

Appendix A · Module catalogue

Plain-language description of every audited module and the recommended migration action. Modules are grouped by functional area. The recommendation reflects the strategy chosen by the analyzer based on market availability, code complexity and risk patterns.