Changing existing database tables or columns is more complex. Whether columns are renamed or changed in type or constraint, the transitions have to be executed in several steps. Directly renaming or changing columns would lead to incompatibilities with the deployed application instances; changes require intermediate columns.

Let's examine this approach using an example. Assume the car entity has a property color, which must be set, represented in the database column color. Assuming it will be refactored to the name chassis color or chassis_color in the database column.

Similar to the previous approach, the change is executed in several deployments. The first deployment adds a nullable column chassis_color. The application code is enhanced to use the new model property. Since the older application version doesn't know about the property yet, it is not reliably written from all places during the first deployment. Therefore, the first code version still reads the color from the old, color column, but writes values to both the old and new column.

The migration script on the next deployment updates the missing column values by overwriting the chassis_color column with the color column contents. By doing this, it is ensured that the new column is populated consistently. The not null constraint is added to the new column as well. The application code version will then only read from the new, but still write to both, because of the short period when the older version is still active.

The next deployment step removes the not null constraint from the color column. The application code of this version doesn't use the old column anymore, and both reads and writes to chassis_color.

The next and final deployment then drops the color column. Now all data has been gradually transferred to the new chassis_color column. The application code doesn't include the old model property anymore.

Changing column types or foreign key constraints require similar steps. The only way to gradually migrate databases with zero-downtime is to migrate in small steps, using intermediate columns and properties. It is advisable to perform several commits that only contain these changes to both the migration scripts and application code.

Similar to the previous approach, rollback migrations have to be executed in reverse, for both the database scripts and code changes.