Complex OpenUpgrade Migration

Day 1 of very very many

Graeme Gellatly

I have an upgrade project to do.  It is fairly complicated and while OpenUpgrade documentation is good, its mainly written for the simple case.  I've used it lately for a number of v10 - v11 migrations and easy peasy, done in minutes.

So what we are doing is migrating from v7 to v11.  The database is large, like 50gb large and there are roughly 150 modules installed.  The last time I tried OpenUpgrade on a database this large, it took 3 weeks just to migrate the account move lines, which led to me abandoning the project for a few years and doing my own thing with a direct sql implementation which did the whole thing in 30 minutes. 

However, the complexity here and multiple version jumps means I want to try it again.  Besides, even if the time becomes unsuitable, OpenUpgrade has a library of tools which could prove useful if I need to take the SQL route.  The idea is to do a quick recce to see if it is feasible, and iterate from there.

Step 1. Read the docs

Step 2. Again

Step 3. Ask some people who know their stuff. Turns out I am not alone here.

Step 4. Take stock of the current situation.

  • SELECT name, author from ir_module_module WHERE state = 'installed' ORDER BY author, name;

  • Compare that list with OpenUpgrade migration docs for what has been done. Cut and paste and VLOOKUP for all 4 versions. OK 49 are ready all the way to 11.

  • Do a quick pass to spot anything odd, like I'm sure they don't use that and check it out or I know they aren't going to use that again. Great that is another 24 modules I can mostly forget about for now - plugin_thunderbird anyone, or the account_report_company fiasco of the new v7 partner model - although some dictate some serious migration work, like porting reports from webkit to qweb.

  • Check the OCA modules are migrated to v11 already, and whether there has been any changes of note.

    • Mostly OK, web_context_tunnel I've noted needs replacing with base_view_inheritance_extension and needs migrating.

    • Few view renames.

    • A couple with open PR's which I note to review.

  • Make various notes about expected issues in the code migration where obvious, but plenty now to see if feasible.  The 50 modules cover roughly 80 pct of the data, so enough to start timing.  I can continue the notes once I got an upgrade going.

Unfortunately now the phone goes and my daughter has arrived at swimming without togs.  So TBC tomorrow.