The discovery phase pays for itself

Most rewrites fail for the same reason: the team treats the second system as a chance to fix everything at once. The first release grows until it can never ship, and by the time it does the business has moved on.

Start with the seam, not the system

The useful question is not "what should the new system look like" but "where can we cut this one in half safely". Find a seam — a boundary where data flows one way and the contract is small — and replace only what sits behind it.

That gives you something in production in weeks rather than quarters, and it gives the business a way to stop if priorities change.

What that looks like in practice

• Write down the contract at the seam before touching either side of it.
• Run both implementations in parallel and compare outputs against real traffic.
• Cut over one tenant, one region, or one workflow at a time.

If you cannot describe the first release in a paragraph, it is not the first release.

Keep the old system boring

While the replacement is in flight, the legacy system should get bug fixes and nothing else. Every feature added to the thing you are replacing is work you will do twice.

The discipline is unpopular and it is the single largest predictor of whether the migration finishes.