[sjf]

I support everything in this comment.

After more than a decade at large sw companies, I can count on one hand the number of migrations where the legacy system was ever able to be turned down. I’ve seen migrations drag on for years, to the point where most of the team has turned over. I’ve seen them become a three-way migration because the second version was deemed insufficient so a third solution was introduced.

Absolutely put your most senior devs on this; maintain as much support from management as possible; budget for much, much more time than you think; you need full commitment or you are going to be maintaining both systems indefinitely.

[stevage]

Do senior Devs actually want to work on such a thankless project?

[philip1209]

It favors people who just want a clear thing to work on for a year or two.

[toast0]

> After more than a decade at large sw companies, I can count on one hand the number of migrations where the legacy system was ever able to be turned down.

If part of the plan wasn't to run a v1 shim on top of v2 to handle legacy users that won't migrate, v2 almost certainly doesn't meet the needs of v1 customers and it's not a question of 'migration' it's a question of ending a product and releasing a similar product.

Sometimes that's what's wanted and needed, but often it's not, and then it's a surprise that the v1 users want their needs met and it's hard to say no to paying customers, but nobody signed up to run two products forever.

[sjf]

I’ve seen this happen in situations where the migration is totally invisible to users. My last team is five years into an opaque database migration that seems to only expand in scope. It’s just a symptom of the migration being more difficult than originally expected usually combined with losing momentum or leadership support. Obviously no one originally intends to keep maintaining both system indefinitely.