Pre-requisite: Having Github Account & Odoo SH Account

Once client has confirmed they want to move from a Saas DB to SH Database, and has confirmed the payment(subscription) to SH, you can create a ticket

1. Creating Odoo SH Project. TC will take the task, move it to Help & Training. When done, TC will alert you that project has been created and added you to the list of users. This ticket is usually resolved quickly. Here is the required information:

• Customer company name
• Subscription code
• FC github username
• Server location (Customer can use this page to decide)

2. Migrating Developments. If there are developments attached to the Saas DB, note that these have to be migrated to SH version as well. Any studio customization used in a module will also be migrated to the module as to have no dependancy between studio and our developments. From this ticket, you will be given an estimation of time and LOC. The LoC here would refer to the NEW LOC AFTER MIGRATION, NOT ADDITIONAL LOC.

For ticket 1, you can refer to this documentation

For ticket 2, here are the processes involved:

1. Install odev tool. Details here.
2. Create a separate directory or use the new SH repository to store these exported modules.
3. Have a look into the export function of odev odev export -h
4. The General format of the command is: odev export <URL> --path <output path> --login <one of db user's email (preferably strongest access rights like admin)> --password <trigram/password> --platform sh -m <module1,module2,module3>

Might take some time because it will also include studio_customization, and __export_module__ automatically but you can ignore these when converting.

Once the export is completed, you should check all of the files and make sure that they are correct. From my observation, here are some good and bad parts after export. You need to do extra action for the bad parts as they are not accurate enough.

GOOD:

• All exported modules have the correct models and fields already (if you introduce new models and fields)
• All the field names are converted to SH friendly names (i.e. removing the prepended 'x_' from field names)
• Initialized a migration script already for this to help you migrate them. Migration scripts include renaming models and fields.
• Views are automatically updated to using the new field names if used previously

BAD:

• Automated actions are exported incorrectly. It will generate a server action which later on will create a method on one of the models. For this part, you have to look back at the task(requirement), and see how would you do it if it were on SH database. Avoid automated/server action when in SH.
• Migration script doesn't include the migration of views outside of the module. If for example, FC or client has used the x_ field on their studio customization, you will need to write more script to migrate those

After correcting the modules (roughly), install all the modules on blank database and then run odev cloc method on the database with passing those modules path as argument. Document all changes needed from the Saas module to SH module on the ps-tools.
Quote the time and LoC afterwards, make sure you bump up your estimations as there might be uncertainties faced during migration process.

Specify in the Technical Analysis which new fields have to be introduced and put on pre-migrate if these fields have to be migrated from previous fields (through studio or saas module).