The first crucial point is that you increase the version number of your addon, 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 version, if the version number has three or fewer components. In the preceding example, we also 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 addons with its own major and minor version number. Generally, using the long notation is a good thing because you can see with just a glance at the manifest file, for which version of Odoo an addon is meant.
The two migration files are just code files that don't need to be registered anywhere. When updating an addon, Odoo compares the addon's version as noted in ir_module_module with the version in the addon's manifest. If the manifest's version is higher (after possibly adding Odoo's major and minor version), this addon's migrations folder will be searched if it contains folders with the version(s) in between, up to, and including the version that is currently updated.
Then, within the folders found, it 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 addon defines, so you can assume that nothing changed in your database layout compared to the previous version.
After all pre-migrate functions run successfully, Odoo loads the models and data declared in the addon, 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, post-migrate files will be searched and executed if found. In our case, we need to look at every value and see whether we can make something usable out of it; otherwise, we keep NULL as data. Don't write scripts iterating over a whole table yourself if not absolutely necessary; in this case, we should have written a very big unreadable SQL switch that does what we want.