The first crucial point is that you increase the version number of your add-on, as migrations run only between different versions. During every update, Odoo writes the version number from the manifest at the time of the update into the ir_module_module table. The version number is prefixed with Odoo's major and minor versions if the version number has three or fewer components. In the preceding example, we explicitly named Odoo's major and minor version, which is good practice, but a value of 1.0.1 would have had the same effect, because, internally, Odoo prefixes short version numbers for add-ons with its own major and minor version number. Generally, using the long notation is a good idea because you can see at a glance which version of Odoo an add-on is meant for.
The two migration files are just code files that don't need to be registered anywhere. When updating an add-on, Odoo compares the add-on's version, as noted in ir_module_module, with the version in the add-on's manifest. If the manifest's version is higher (after adding Odoo's major and minor version), this add-on's migrations folder will be searched to see whether it contains folders with the version(s) in-between, up to, and including the version that is currently updated.
Then, within the folders found, Odoo searches for Python files whose names start with pre-, loads them, and expects them to define a function called migrate, which has two parameters. This function is called with a database cursor as the first argument and the currently-installed version as the second argument. This happens before Odoo even looks at the rest of the code the add-on defines, so you can assume that nothing changes in your database layout compared to the previous version.
After all the pre-migrate functions run successfully, Odoo loads the models and the data declared in the add-on, which can cause changes in the database layout. Given that we renamed date_release in pre-migrate.py, Odoo will just create a new column with that name, but with the correct data type.
After that, with the same search algorithm, the post-migrate files will be searched and executed if found. In our case, we need to look at every value to see whether we can make something usable out of it; otherwise, we keep the data as NULL. Don't write scripts that iterate over a whole table if not absolutely necessary; in this case, we would have written a very big, unreadable SQL switch.