As software grows, patterns and practices naturally evolve. Inevitably, someone comes to the conclusion that a change should happen and code should be migrated to the new thing.
While many agree full rewrites are a bad idea, migrations tend to slip under the radar.
Migrations are mini rewrites and the same caution should be applied.
When you think of migrations as rewrites, you think about the problem differently. Rewrites are an exercise in chunking. The total cost of ownership is not just adding it the first time, but updating all other places for consitency, fixing bugs introduced along the way, and maintaining the new thing forever. Unfortunately, many large scale codebases end up with tech debt because of half completed migrations (probably several because a migration are needed to fix the other partial migration!).
You’ll often hear justifications like, “We can do this gradually” and, “We’ll add this to new code first.” All lies we tell ourselves to do the thing we want.
What can you do about it?
Approach the migration as if it needs to happen all at once in one effort or not at all. This pierces the illusion that future us will have the time and focus to complete the work present us doesn’t do (experience would suggest this is never true unless you absolutely have to).
Don’t accept installment plans, pay the whole thing up front or move on because worse is better.
See also:
- Dependencies are a sneaky way migrations are needed and the default strategy should be to not add more
- Closing the gap between previous technical decisions and the current quality bar is engineering leadership