3
votes

I have an OpenERP 5.0 installation with a few custom modules, that I wish to upgrade to OpenERP 6.0.

I have some experience with this kind of sofware and I have inspected OpenERP. Sadly, I don't have actual experience with OpenERP, and I like to ask for some help in order to avoid mistakes. When researching this, I found there are several strategies (ETL processes, data-upgrade modules)... I assume I'll need to review all custom modules.

What are the guidelines or best practice in order to upgrade an OpenERP 5.0 installation to 6.0?

2

2 Answers

4
votes

We're still planning our migration from 5.0 to 6.0, so I don't have any personal experience with the process. We are planning to tackle the work ourselves, but we've done a lot of custom development, so we're pretty comfortable with the OpenERP code. If I were inheriting the system from someone else as it sounds like you are, I would be very tempted by the support contract that includes doing migrations for you.

In addition to the paid service, there also appears to be an open-source tool available for running data migrations. It is also discussed in several forum posts. (There really are a lot.)

Our tentative plans are:

  1. Try out the migration tool for a demo database from plain 5.0 to plain 6.1.
  2. Migrate the code for our custom modules to 6.1, following the Pragtech guidelines.
  3. Extend the migration tool's configuration to cover our custom modules and any others that weren't included with the tool.
  4. Run the migration on our full database into a sandbox and test the heck out of it.
  5. Launch and celebrate!

Update:

We've started our migration process, and we're using OpenUpgrade instead of the Domsense tool. We never really looked at the Domsense tool, so I can't say which is better. I'm very happy with OpenUpgrade so far.

In general, I've found version 6.1 much easier to customize than 5.0 was. So far, I haven't had to change any core modules. For example, most places where a core module inserts a record, it calls a helper method to prepare the data. If you add a new column that you want to be populated, you can just override that helper method. For example, we added a grouping field to several tables and then wanted to copy it from sales order line to stock move. We overrode the sale module's version of sale_order._prepare_order_line_move() with our own version.

I posted a separate question about customizing reports.

The down side is that every customized feature we try to migrate requires some change. So far there has always been a change in the core module that somehow breaks our customization. Either a field name changed, or the screen layout changed, or the whole model name changed. You can usually figure out how to fix it, but everything takes time.

4
votes

The best approach is to contract an OpenERP Enterprise. Migrating is quite complex and OpenERP can do the job for you. It's a fixed price for unlimited bugfixes and migrations: http://www.openerp.com/catalog/146