从 Odoo 17/18 迁移到 Odoo 19：完整指南

升级到 Odoo 19 Enterprise 可显着改进性能、用户体验和 AI 辅助功能。但迁移是 ERP 生命周期中风险最高的操作之一——数据丢失、自定义模块损坏和停机时间延长都是真正的风险，需要仔细规划和执行。

本指南为从 Odoo 17 或 Odoo 18 迁移到 Odoo 19 Enterprise 的组织提供了实用的分步迁移方法。它涵盖了从初始评估和数据映射到自定义模块更新、测试程序和上线切换计划的所有内容。

要点

• Odoo 19 迁移需要一次升级一个主要版本（17→18→19 或 17→19 直接使用 OpenUpgrade）
• 自定义模块兼容性必须根据 Odoo 19 的 API 更改进行验证
• 数据迁移通过Odoo官方升级平台或OpenUpgrade运行
• 生产切换前必须有并行测试环境
• 根据复杂程度规划 3-8 周的总迁移时间
• 切换前必须关闭财务周期以避免对账问题
• 所有第三方集成在迁移后都需要重新验证
• 回滚计划必须在上线前记录并测试

---

迁移规划：评估阶段

在编写单个迁移脚本之前，请花时间进行彻底评估。迁移失败最常见的原因是规划不充分，而不是技术复杂性。

第 1 步：清点您当前的环境

记录当前 Odoo 安装的每个组件：

Current Environment Inventory:
- Odoo version: 17.0.x or 18.0.x
- Edition: Community or Enterprise
- Database size: X GB, Y records in sale.order, Z in account.move
- Installed modules: [list all modules]
- Custom modules: [list with developer contact]
- Third-party connectors: [Amazon, Shopify, etc.]
- Active integrations: [API, webhooks, cron jobs]
- Customized reports: [list]
- Custom fields (Studio or code): [list]
- Server specs: RAM, CPU, disk
- PostgreSQL version: (minimum 15 required for Odoo 19)

步骤 2：对自定义模块进行分类

对于每个自定义模块，确定：

第 3 步：确定 Odoo 19 重大变更

Odoo 17/18 和 Odoo 19 之间影响自定义模块的主要变化：

• OWL 3.x：前端组件必须从 OWL 2.x 模式迁移
• Python 3.12：某些Python 3.10/3.11语法可能需要调整
• PostgreSQL 15+：所需的最低版本；一些查询模式发生变化
• API 弃用：删除了多个 _legacy 方法；检查 _multi → _create_multi
• 报告引擎：一些 QWeb 报告变量已重命名
• 帐户移动重构：account.move 行结构更改影响会计自定义

---

选择您的迁移路径

路径一：Odoo官方升级服务

Odoo SA 在 upgrade.odoo.com 提供自动升级服务。您提交数据库，他们运行由 Odoo SA 开发和维护的迁移脚本，然后您会收到升级后的数据库。

优点：

• Odoo SA 的官方支持和测试
• 自动处理数据库模式更改
• 适用于标准 Odoo，只需最少的定制

缺点：

• 不处理自定义模块
• 需要将生产数据提交到 Odoo 的服务器
• 对迁移过程的控制有限
• 自定义模块迁移是您的责任

路径 2：OpenUpgrade（社区工具）

OpenUpgrade 是一个开源项目，为社区和企业提供迁移脚本。

# Clone OpenUpgrade for Odoo 19
git clone https://github.com/OCA/OpenUpgrade.git -b 19.0

# Install upgrade dependencies
pip install openupgradelib

# Run migration
python odoo-bin --config=upgrade.conf \
    --update=all \
    --load=base,web,openupgrade_framework

路径 3：全新安装并导入数据

对于高度定制的实例或非常旧的版本：

1. 设置新的 Odoo 19 Enterprise 实例
2. 重新配置所有模块和设置 3.从旧系统导出关键数据 4.通过Odoo的导入工具或自定义迁移脚本导入
3. 手动重新输入期初余额进行会计处理

这条路径速度较慢，但​​提供了最干净的起点。

推荐用于大多数 Odoo 17/18 → 19 迁移：路径 1 或 2 与并行自定义模块重新开发工作相结合。

---

迁移前准备（第 1-2 周）

数据库准备：

-- Run on source database before export
-- Identify orphaned records
SELECT id, name FROM res_partner WHERE active = FALSE AND id NOT IN (
    SELECT partner_id FROM sale_order
    UNION SELECT partner_id FROM account_move
    UNION SELECT partner_id FROM stock_picking
);

-- Archive old draft records (reduces migration time)
UPDATE sale_order SET active = FALSE
WHERE state = 'draft' AND date_order < NOW() - INTERVAL '2 years';

-- Verify accounting reconciliation
SELECT COUNT(*) FROM account_move_line
WHERE reconciled = FALSE AND debit != credit;

截止财务期：

迁移前：

1. 在 Odoo Accounting 中锁定当前月份之前的所有期间
2. 运行账龄应收账款和应付账款报告并调节差异
3. 核对迁移日期之前的所有银行对账单
4. 过帐应包含在历史数据中的所有草稿发票

备份所有内容：

# PostgreSQL backup
pg_dump -h localhost -p 5433 -U odoo_user -Fc odoo_production > \
    odoo_prod_backup_$(date +%Y%m%d_%H%M%S).dump

# Filestore backup (attachments, images)
tar -czf odoo_filestore_$(date +%Y%m%d).tar.gz \
    /var/lib/odoo/.local/share/Odoo/filestore/

# Configuration backup
cp /etc/odoo/odoo.conf odoo_conf_backup_$(date +%Y%m%d).conf

自定义模块代码审查：

对于每个自定义模块，运行兼容性检查：

# Check for deprecated patterns
grep -r "execute_kw" custom_modules/   # Still valid in v19
grep -r "browse\(\[" custom_modules/  # Should be browse(ids) not browse([ids])
grep -r "_multi" custom_modules/      # Check for renamed methods
grep -r "account\.move\.line\." custom_modules/  # Account refactoring affected
grep -r "@api\.one" custom_modules/   # Removed in v14, ensure not present
grep -r "@api\.multi" custom_modules/ # Removed in v14, ensure not present

---

设置迁移环境（第 2-3 周）

基础设施设置：

# Install Odoo 19 Enterprise on migration server
# Requirements: Ubuntu 22.04/24.04, PostgreSQL 15+, Python 3.12

# Install PostgreSQL 15+
sudo apt install postgresql-15 postgresql-contrib

# Install Python 3.12 and dependencies
sudo apt install python3.12 python3.12-dev python3.12-venv \
    libxml2-dev libxslt1-dev libldap2-dev libsasl2-dev \
    libtiff5-dev libjpeg8-dev libopenjp2-7-dev zlib1g-dev \
    libfreetype6-dev liblcms2-dev libwebp-dev libharfbuzz-dev \
    libfribidi-dev libxcb1-dev

# Clone Odoo 19 Enterprise
git clone https://github.com/odoo/odoo.git -b 19.0 /opt/odoo19
git clone https://github.com/odoo/enterprise.git -b 19.0 /opt/odoo19-enterprise

# Install Python dependencies
pip3.12 install -r /opt/odoo19/requirements.txt

将源数据库恢复到迁移服务器：

# Create target database
createdb -h localhost -U postgres odoo_migration_test

# Restore backup
pg_restore -h localhost -U postgres -d odoo_migration_test \
    odoo_prod_backup_YYYYMMDD.dump

# Run Odoo upgrade
python3 /opt/odoo19/odoo-bin \
    -d odoo_migration_test \
    -u all \
    --without-demo=all \
    --stop-after-init

---

自定义模块迁移（第 3-5 周）

这个阶段是最耗时的。每个定制模块需要：

1.更新清单版本：

# Change from:
'version': '17.0.1.0.0',
# To:
'version': '19.0.1.0.0',

2.更新 Python 兼容性：

# Old pattern (deprecated):
@api.multi
def my_method(self):
    for record in self:
        pass

# New pattern:
def my_method(self):
    for record in self:
        pass

3.更新视图语法：

<!-- Old (v16 and earlier): -->
<field name="state" attrs="{'invisible': [('active', '=', False)]}"/>

<!-- New (v17+): -->
<field name="state" invisible="not active"/>

4.更新 OWL 组件（如果有前端小部件）：

OWL 3.x 引入了反应性更改。如果您的模块使用自定义 JavaScript 小部件：

// Old OWL 2.x:
class MyWidget extends Component {
    static template = 'MyModule.MyWidget';
    willStart() { ... }
}

// New OWL 3.x:
class MyWidget extends Component {
    static template = 'MyModule.MyWidget';
    setup() {
        onWillStart(async () => { ... });
    }
}

5.独立测试每个模块：

# Install and test each custom module
python3 odoo-bin -d test_db -i my_custom_module --stop-after-init
python3 odoo-bin -d test_db --test-enable -u my_custom_module

---

数据验证和测试（第 5-6 周）

财务数据验证：

-- Verify balance sheet balances (assets = liabilities + equity)
SELECT
    SUM(CASE WHEN account_type LIKE 'asset%' THEN balance ELSE 0 END) as assets,
    SUM(CASE WHEN account_type LIKE 'liability%' THEN balance ELSE 0 END) as liabilities,
    SUM(CASE WHEN account_type = 'equity' THEN balance ELSE 0 END) as equity
FROM account_account aa
JOIN account_move_line aml ON aml.account_id = aa.id
JOIN account_move am ON aml.move_id = am.id
WHERE am.state = 'posted';

记录计数验证：

比较源数据库和迁移数据库之间的记录计数：

# Run on both source and target to compare
models_to_check = [
    'res.partner', 'product.template', 'product.product',
    'sale.order', 'purchase.order', 'account.move',
    'stock.quant', 'mrp.production', 'hr.employee'
]

for model in models_to_check:
    count = env[model].search_count([])
    print(f"{model}: {count}")

用户验收测试清单：

• 所有菜单和导航项均可访问
• 关键流程：销售订单→发货→发票→付款
• 会计：日记账分录、银行余额调节表、报告
• 库存：收货、交货、库存估价
• 制造：BOM、工作订单、质量检查（如果适用）
• HR：员工、休假管理、工资单（如果适用）
• 业务用户验证的自定义模块功能
• 报告正确生成并与迁移前输出匹配
• 外部集成（API、webhooks）在暂存阶段进行了测试

---

上线切换计划（第 7-8 周）

切换窗口规划：

选择对业务影响最小的切换窗口：

• 周末（大多数企业为周六晚上至周日早上）
• 财政月末（简化期初余额输入）
• 银行假期前最后一个工作日之后（额外缓冲时间）

切换清单：

T-48 hours:
[ ] Final communication to all users about downtime window
[ ] Freeze all non-critical transactions in old system
[ ] Verify migration server is ready
[ ] Complete last data validation run

T-0 (Cutover Start):
[ ] Put old system in maintenance mode (disable user access)
[ ] Create final backup of production database
[ ] Run final migration on this backup
[ ] Verify record counts and financial balances
[ ] Test all critical workflows
[ ] DNS/URL cutover to new system
[ ] Smoke test from user devices (desktop, mobile)

T+2 hours (Go-Live Verification):
[ ] All users can log in
[ ] Create test sale order, confirm, ship, invoice
[ ] Verify email sending works
[ ] Check integrations are receiving/sending data
[ ] Monitor error logs for first 30 minutes

回滚计划：

如果在割接过程中发现严重问题：

1. 将 DNS 切换回旧服务器（< 5 分钟） 2.为用户重新启用旧系统
2. 记录所有发现的问题
3. 安排后续迁移窗口

---

常见问题

我可以从 Odoo 17 直接跳到 Odoo 19，还是必须经过 18？

使用Odoo的官方升级服务，通常可以直接从17升级到19。Odoo SA的迁移脚本可以处理多版本跳转。使用 OpenUpgrade，您可能需要执行 17→18→19，具体取决于可用的迁移脚本。请务必检查 OpenUpgrade 存储库以获取您需要的特定版本。

典型的 Odoo 迁移需要多长时间？

时间表在很大程度上取决于定制级别。具有最少定制的标准 Odoo 实例：2-3 周。适度定制（5-10 个定制模块）：4-6 周。通过复杂的集成进行大量定制：8-16 周。迁移本身（数据库升级）需要数小时；时间是在测试、模块更新和验证上。

迁移期间 Studio 自定义会发生什么情况？

Studio 自定义内容存储为标准 Odoo 数据（视图、字段、自动化），并通过标准数据库升级流程进行迁移。但是，如果 Odoo 19 更改了底层表单结构，某些视图自定义可能需要手动审核。迁移后始终测试所有 Studio 自定义。

迁移后我需要重新输入期初余额吗？

不需要，如果直接迁移数据库。所有历史日记账分录和余额都随数据库传输。如果您选择“全新安装并导入数据”路径，则需要输入截至转换日期的期初余额，这需要与您的会计团队仔细协调。

我的 Odoo Enterprise 许可证会转移到版本 19 吗？

是的。 Odoo Enterprise 订阅与版本无关。您的年度订阅涵盖您运行的任何版本。如果您不使用企业凭据通过 Odoo 的 Git 存储库访问 Odoo 19 Enterprise 代码，请联系您的 Odoo 合作伙伴以获取 Odoo 19 Enterprise 代码。

---

后续步骤

Odoo 迁移是直接影响业务连续性的高风险项目。顺利迁移和痛苦迁移之间的区别取决于准备、专业知识和严格的测试方法。

ECOSIRE 已成功将数十个 Odoo 实例从版本 13、14、15、16、17 和 18 迁移到 Odoo 19 Enterprise。我们的迁移方法涵盖全面评估、自定义模块更新、并行测试以及带有回滚程序的记录转换计划。

向 ECOSIRE 请求 Odoo 迁移评估 →

我们将评估您当前的环境，识别所有迁移风险，并提供固定范围的迁移计划，以便您确切地知道在第一个迁移脚本运行之前会发生什么。