The Deep Dive (Analysis)

Before we do anything we establish what state your current database is in, so we can ultimately answer the questions:

1. How close to standard is this database?
   
   
2. 1. How many Studio modifications does it have? How significant are they?
      
      
   2. How much custom code does it have? Does this custom code touch any areas of Odoo we know have had significant changes? Are there enough tests for us to know if we've broken something?
      
      
   3. Are there apps that were purchased from the App Store which need newer versions purchasing? If they're not available, what would the plan be for migration?
      
      
   4. Are there complex configurations that may not be catered for by the new version?
      
      
3. Do we understand all your workflows? Has the customer made changes that we are not aware of?
   
   
4. What customisations, if any, can or should be migrated to now standard functionality?

We provide a ballpark time estimate based on what we've found and where we think the most time will be spent before we do anything else. 

It's then your choice if you wish to continue.

The Work (Upgrade Cycle)

During the upgrade cycle we do not touch your production database whatsoever. You continue to work.

1. We work with your team to identify any areas of Odoo which will need significant retraining, or if we need to discuss with you the impact of changes Odoo SA have made. For most installations this is generally a very short step.
   
   
2. In the background, we start off by upgrading the source code of your custom modules to be compatible with the new version of Odoo where we know that there won't be other changes. This may mean planning a deprecation and migration to now standard features. It may mean completely rewriting a feature to accomodate the changes. 
   
   We ideally like to add more automated testing at this stage, if we find it lacking. This also helps speed up future upgrades.
   
   An example of this is between Odoo 12 and 13 the accounting module was quite fundamentally altered to significantly speed it up. A customer with significant and non-cosmetic changes to the accounting system required quite a lot of time to be spend in the port and validation of those features. Whilst they have benefited the most from migrating to 12, due to the amount of invoicing they do, it was a long winded process. Internally to Odoo these are often called 'apocalypse' changes. Fortunately they do not happen often.
   
   
3. We then take a backup of your production database, and submit it to the Odoo SA Enterprise Upgrade Service.
   
   The Upgrade Service takes your database backup, runs through the official migrations to convert your database to the newer version. It can only do this for standard apps and modules.
   
   Depending on the size of your database this may take several hours. The largest database we upgraded from 12 to 15 took 9 hours alone on this step, each time.
   
   This may fail. If so we investigate the logs, sometimes submit tickets to Odoo SA, or we handle the issue ourselves, and then repeat.
   
   When it succeeds the Upgrade Service provides a new backup which we can use with the newer version of Odoo.
   
   
4. We then restore the test database, and figure out what's broken by running automatic and manual tests. 
   
   We may need to write some custom fix scripts to deal with things that the Odoo SA Upgrade Service has failed to handle correctly. The more versions you jump between the more likely this needs to be done.
   
   
5. We then provide you with a copy of Odoo with your data in for sign off, testing, feedback and training.
   
   We also use this to practise the migration process, and time it, as-if it were a real migration. We will advise you of this time so you understand how much down time to expect during go live.
   
   
6. We will need to repeat steps 1-4 multiple times until everyone is happy, and we get sign off.

Planning go live with you

• We plan when we will stop your production install and perform the upgrade. We can accomodate out of hours. 
  
  
• Work with you to help you understand what the roll back plan is should something unexpected happen.
  
  
• And ensure everyone is clear when the point of no return is (when a rollback is no longer practically feasible - i.e. you've processed a large amount of stock movements, or new sales orders).
  
  
• It's important that you do not have business critical events immediately before, after or during your go live where possible. This may include events such as:
• • Critical month end
  • VAT/Tax cycles
  • Big promotional sales
  • Significant staff holiday
    
    
• Plan for 1-3 days of mild disruption, out of an abundance of caution. In a utopian world everyone should know how to perform their daily tasks in the new version. Realistically this doesn't always happen, or things fall through the cracks. Or shadow IT has setup some kind of process that key stakeholders were unaware of. It's better to be plan for something that doesnt happen, than be surprised.
  

The Big Day

We take your production Odoo copy down, take a backup, and we perform the real upgrade. Then that's it.

Ideally at this point there should be no surprises, everyone should have run through the process multiple times and everyone clear on what is happening when, and how we will communicate progress. 

Sometimes things happen, and we do need to rollback. For example, in the past we've suddenly had the Odoo SA upgrade service die, or a critical stakeholder take unplanned leave. The important thing is this isn't necessarily a big thing and its catered for.

The morning after

Ideally it should be quiet, and business as normal.

But sometimes no matter how hard you plan, sometimes things fall through the cracks. But don't worry, we'll be there to help. We always ensure that the critical team members at glo are available after an upgrade, just incase.