Toronto - CN Tower View

OpenERP migration to the current stable version (part 1)

22. March 2013

After TaPo-IT is using OpenERP for a long time for ourselves and therefore is mapping the business processes on top of OpenERP, we regulary have to decide how we will upgrade and migrate the recorded data and the used modules to the next major version of OpenERP. As we had some time recently and we were very exited about the new major release and impatient to work with, we finally deployed successfully a migration to our production database!

OpenERP Customer Kanban

There a several approaches and methods, respectively possibilities how you can do your migration which I will discuss in small series here. Maybe this will help our readers to see the bigger picture behind and make their decisions based on that.

In general, you have to ask yourself in which situation you are and how you are using OpenERP for you business.

  • with an OpenERP Enterprise Contract
    • Migration w/ the help of your OpenERP business partner (OpenERP Partner, IT Company)
    • Migration directly and self-managed through the fülly automated OpenERP migration platform (Internal IT Department)
  • without OpenERP Enterprise Contract
    • Migration w/ the help of your OpenERP business partner (OpenERP Partner, IT Company)
    • Migration w/o help of other companies based on the competencies maintained by your own company

The offer from OpenERP based on the enterprise contract for migration, bugfixing and support, is securely the most direct and easiest way if you need to migrate the official and certified modules and having a responsible and contracted company for the core modules and the software itself.

Now it is common sense that Open Source is available w/o paying license fees and it is potentially possible for all, who possess expertise, want to work on it or even buy it where ever they want, to use and reuse it (for sure under the agreement of the license offered).

"Free software is a matter of liberty, not price. To understand the concept, you should think of free as in free speech, not as in free beer."  (Cite from GNU - What is free software?)  is pointing out the essential idea behind and you should consider this all the time when you are working with Open Source. But what is freedom at all? :-)

I will try to explain to you based on our own experience. To switch back to our topic, there have been developed a few approaches and initiatives within the Community of OpenERP, concerning the self-managed, respectively attended migration, which I will introduce in the future and discuss the advantages and disadvantages of the different methods.

In general, there are the following methods, in order to find a solution to handle the requirement, independently from the easiest way together with your OpenERP Partner (who we eventually are as well) and respectively directly with OpenERP for the core modules and the software itself.

  • Migration of data trough an ETL module in the target database of OpenERP (newly created database in the target version)
  • Migration based on database analysis respectively comparision and adaptations in its purest form through execution of elaborated pre- and post migration scripts around the auto upgrade process of OpenERP which makes it possible to update minor changes in the modules and models.

Both methods lead, based on their requirement, to aimed success, although it is a requirement to have a high comprehension of the software which should be migrated, in order to face the troubles on the way to the newest version and finally solve them successfully.

In my next blog post I will try to focus on the requirements of a migration for OpenERP and the the process which accompanies a migration in general or eventually should accompany it.

I hope you enjoyed my first blog post and I would be happy to see you again next time.