The migration you are planning is probably a rewrite in disguise

There is a specific proposal that recurs at companies of a certain age. The existing application is old. The framework is unfashionable. Someone proposes a migration, and because it is framed as a migration rather than a rewrite, it sounds bounded.

It is almost never bounded.

Why the estimate is always wrong

The estimate is built from the code that is visible: models, controllers, views. What is invisible is the accumulated behaviour — the special case for the customer who signed in 2019, the retry that exists because a payment provider occasionally returns malformed responses, the ordering that some downstream report depends on without documenting it.

None of that is in the design document. All of it is in production. You discover it by breaking it.

What successful migrations have in common

The ones that work tend to share a shape. They run both systems simultaneously for a long time. They move one bounded piece at a time, with the ability to route back. They ship value at each step, so that if the effort is cancelled after 30%, that 30% was still worth doing.

The ones that fail are the ones where nothing is deliverable until everything is done, because that is the shape where a change in priorities leaves you with two half-maintained systems and nobody who remembers why.

The question to ask first

Before approving one, ask what specific problem this solves and what it would cost to solve that problem directly in the existing system.

Sometimes the answer is genuinely a migration — the old framework is unsupported, the security patches have stopped, the hiring pool has evaporated. Those are real. But often the underlying complaint is "this codebase is unpleasant to work in," and a new framework will feel wonderful for roughly eight months, after which it will accumulate the same special cases, because the special cases came from the business, not the framework.

Shopify's answer to a large aging Rails monolith was not to leave Rails. It was to impose internal structure on the monolith it already had. That option is available more often than it is taken, mostly because it is less fun.