关于 zero downtime migration 的疑问

https://www.honeybadger.io/blog/2013/08/06/zero-downtime-migrations-of-large-databases-using-rails-postgres-and-redis

1. Make sure you update both representations when new records are saved
2. Use the new data when possible, but fall back to the old data
3. Remove this ASAP. It's ugly as sin.

我的思路和这篇文章提到的基本一致，为保证服务一直可用，不停机升级数据库。方案如下：
1. 后台程序完成大部分（老）数据的升级；
2. 上线新代码，CRUD操作时升级相关数据，然后走新流程；
3. 升级完成后移除兼容性代码。

但按同事的说法，只需要第一个就可以了，升级期间生成的数据加个标记，后续再用脚本处理，加上第二个会影响用户体验。
我的想法是，第二步是个保护措施（在第一步和第二步上新代码期间一定是有个时间差，期间的数据要标记再处理感觉会更麻烦），能保证数据的正确性，为了这个即使牺牲很小一部分的的体验也可以接受。如果按同事的方法，这个处理何时是个头（有种耗时是1, 1/10, 1/100的等差数列的感觉）。

大家对这个问题怎么看？我隐约觉得为了正确性加上第二步是有必要的，但想得不是很清楚，没办法说服同事。求说服/帮忙说服同事。