Migrations matter because they are usually the only available avenue to make meaningful progress on technical debt.
Engineers hate technical debt. If there is an easy project they can personally do to reduce tech debt, they’ll take it on themselves. Engineering managers hate technical debt, too. If there is an easy project their team can execution in isolation, they’ll get it scheduled. In aggregate, this leads to a dynamic where there is very little low-hanging fruit to reduce technical debt, and most remaining options require many teams working together to implement them: migrations.
Each migrations aims to create technical leverage (“your indexes no longer have to fit on a single server!”) or reduce technical debt (“your acknowledged writes are guaranteed to persist a master failover”). They occupy the awkward territory of reduced immediate contribution today in exchange for more capacity tomorrow. This makes them controversial to schedule, and as your systems become larger, they become more expensive.
Lore tells us that Googlers have a phrase, “Running to stand still”, to describe a team whose entire capacity is consumed in upgrading dependencies and patterns, such that it can’t make forward progress on the product/system they own. Spending all your time on migrations is extreme, but every mid-sized company has a long queue up migrations it can’t staff: moving from VMs to containers, rolling out circuit-breaking, moving to the new build tool; the list extends effortlessly into the sunset.
Migrations are the only mechanism to effectively manage technical debt as your company and code grows. If you don’t get effective at software and system migrations, you’ll end up languishing in technical debt. (And still have to do one later anyway, it’s just that it’ll probably be a full rewrite.)
Source: Migrations: the sole scalable fix to tech debt, Will Larson, https://lethain.com/migrations/