Contact Us  +1 (650) 307-6736 +32 81813700

Migration of custom modules, behind the scenes

ShareThis !

Migration of DB with custom modules is totally possible and supported by our migration platform. Here are the detailed steps:

1) The partner dumps his customer DB (the whole DB with custom modules)

2) He uploads this DB on our migration platform: http://migration.openerp.com/

3) OpenERP does the migration job:

  •     restore the database
  •     uninstall all custom modules
  •     execute all scripts required  for the server update
  •     execute a server update (-u all)
  •     dump the migrated database
  •     adapt the generic scripts if necessary (error during one of the previous steps or functional   tests not passed)

The important fact is that we migrate the original database in place. All is done in the original database. For example, we restore the v6.0 database and execute all the scripts in this database. At the end of the process, this v6.0 database becomes a v6.1 database.

4) the partner will then receive an email with a link to his migration request status page where he can download the migrated database.

On this page, 2 migrated databases are available:

 * 1 WITH his custom modules data untouched

 * 1 WITHOUT custom modules data (custom views, custom workflows, some attachments, ... and anything which will prevent us from doing functional tests were removed). This database is mostly useful for us, never install it on a production server

He can also access some additional and important information like:

  * a technical log file: all technical changes between original version and the version migrated.

  * a functional log file: describes some important functional differences between the previous version and the new one. Also lists some important data migration we had to perform on the database like adding a new object when it's required.

  * the list of the different migration process we executed on that database with the server, addons and the migration scripts revision numbers listed.

At that point, the job from OpenERP's side is done, all certified modules (and their data) are migrated. Now the partner has the choice for the custom part: he can handle the migration himself or ask OpenERP to do it for him.

If he chooses to do it himself:

5) the partner adds his custom modules in the new OpenERP server environment, restores the DB with custom modules, perform a server update

6) The partner fixes any problem that may occur

It is possible that no work needs to be done on the migrated database regarding custom modules. For example, if you have a custom modules extending the 'product' model by adding a field. If the database schema of the 'product' models has not changed, you will retrieve all the data related to your new field and no work needs to be done at all.

Another example, if you have a v5.0 database with a custom module adding a field to the 'mrp.procurement' model. You will not have anything to do in your migrated v6.0 database regarding this field because we already migrated the 'mrp.procurement' model to the 'procurement.order' model in v6.0. The data related to this field will be present in the 'procurement_order' table. Of course, you will have to convert the module in itself which means the python code and xml files, ...

Concrete example:

To show you how it works concretely, here is an example and step by step process:

I have my database working on v6.0 of OpenERP with the following custom modules installed:

  • l10n_es_account

  • l10n_es_partner

  • l10n_es_toponyms

1) I make a dump of my DB and upload it on http://migration.openerp.com, and specify that I want to migrate to v6.1

2) a few minutes later (because my DB contains few data), I receive a confirmation e-mail saying that the migration could end successfully and get a link to download the migrated DB: http://migration.openerp.com/status/a07bf528f8804b6da90bc86bd2bb6849.html

3) I create a new v6.1 environment with my custom modules

4) I restore the migrated DB (the one with uncertified module)

5) I perform a server update (-u all)

6) if a technical problem occurs during the server update or during my functional tests:

  * I try to fix them if they originate from my custom modules

  * if the problem originates from a certified module:

    - I send an email to the Migration Service if I suspect this is a migration problem (migration@openerp.com)

    - I send an email to the Support Department if I suspect this is a server, addons or client problem (support@openerp.com)

7) in our case, no problem occurred during the server update (the 3 custom modules are now installed). The database does not need to be modified from a partner side of view. (NOTE: some functional tests should still be done before validating a migration.

Service from OpenERP:

OpenERP can do for you the job of migrating the custom modules from one version to any future version. This is an extra service, not included in the OERP Enterprise contract. The price of this migration service is based on the code lines of the custom modules (800€ per batch of 1000 lines of code). Feel free to contact your partner or your OpenERP Account Manager for more information.

Date : 19th July, 2012