Comment 18 for bug 701644

My findings so far:

1) We managed to migrate an other database with no magentoerpocnnect that is likely to have been updated at the same server revisions. So this and the fact that nobody else can reproduce the bug tend to make it likely it's somewhat related to magentoerpconnect and dependent modules.

2) Some findings: the content of the ir_model_data records looks OK for my database that won't upgrade. I compared it with a fresh database which will migrate and it's the same for the ir_model_data of the "base" module.

3) I managed to print the content of self.loads where module == 'base'. Here is it with my database that won't update:

**** ('base', 'menu_base_config')
**** ('base', 'menu_procurement_management_supplier')
**** ('base', 'menu_main_pm')
**** ('base', 'menu_procurement_management_supplier_name')
**** ('base', 'menu_reporting')
**** ('base', 'menu_mrp_root')
**** ('base', 'menu_product')
**** ('base', 'menu_base_partner')
**** ('base', 'menu_administration')
**** ('base', 'menu_action_currency_form')
**** ('base', 'menu_sales')
**** ('base', 'menu_purchase_root')
**** ('base', 'menu_project_report')
**** ('base', 'menu_sale_config_sales')

And of course, all the menu component then are not found in self.loads, the list of ir_model_data records from base not found in self.loads then starts as:

not in loads: :(module,name) (u'base', u'maintenance_contract_add_wizard')
not in loads: :(module,name) (u'base', u'action_maintenance_contract_add_wizard')
not in loads: :(module,name) (u'base', u'menu_maintenance_contract_add')
not in loads: :(module,name) (u'base', u'odony_twitter_widget')
not in loads: :(module,name) (u'base', u'matrixise_twitter_widget')
not in loads: :(module,name) (u'base', u'rvalyi_twitter_widget')
not in loads: :(module,name) (u'base', u'maintenance')
not in loads: :(module,name) (u'base', u'menu_maintenance_contract')
not in loads: :(module,name) (u'base', u'albertnan_twitter_widget')
not in loads: :(module,name) (u'base', u'nhomar_twitter_widget')
not in loads: :(module,name) (u'base', u'access_maintenance_group_user')
not in loads: :(module,name) (u'base', u'access_maintenance_contract_module')
not in loads: :(module,name) (u'base', u'maintenance_contract_tree_view')
not in loads: :(module,name) (u'base', u'maintenance_contract_form_view')
not in loads: :(module,name) (u'base', u'maintenance_contract_search_view')
...

So Jay, I believe you were right, it must be some kind of exception happening when updating the base module that fail silently and prevent from putting those records in self.loads as it should be.

It's pretty late here now, but the next step is definitely to hunt for those exception by looging more inside those try blocks. This all is a long process cause my database that won't migrate has 2 years of Magento data imported + BR localization, so it takes between 5 and 10 minutes to migrate every time (which isn't that bad).

The fight continues...