[basseq]

I'm at the tail end of two of these, of ~10 in my career. They are always tough, always a bit of chaos, and all different.

Planning is important, and avoid committing to targets or deadlines until you have your arms wrapped around what needs to be done. This can be wide-ranging, and include: product parity, contract management, internal asset development (project plans, test suites, customer training, etc.), customer change management, and team throughput.

You have few clients but large impacts. You likely want to pick the friendliest one and give them generous terms to be the "test case". Expect it will take 2x longer than your estimate.

Do as much work on parity as you can: what are the differences between v1 and v2, and how will you bridge them? If data migration is involved, you will need tooling and team training.

Inevitably you will find that customers move slower than you like and are using v1 in ways you did not expect.

[jiggawatts]

Day #1 of any N-month long migration/rewrite project I've participated in:

PM: "Fill out this spreadsheet with key dates leading up to the project completion."

Me: "First, that's your job, not mine. Second, I literally just got here, I haven't even drunk my coffee yet. Hi, my name is Jiggawatts. I've only just heard of this software we're migrating ten minutes ago."

PM: "Yes, yes, but the customer asked me for cost estimates and timelines."

Me: "I asked for a Lamborghini packed with supermodels, but I didn't get that either. Tough break, huh?"

PM: "It's not an unreasonable request!"

Me: "Without time machines and/or a magic crystal ball, it is. Do you have a time machine?"

Etc...

We all recognise this, and it's a symptom of an underlying problem.

Really, what ought to occur is incremental progress and demonstrable deliverables. If you go off into a cave for two years and come back with something the customer doesn't like, then you've caused a business catastrophe.

I've found that businesses and customers in general prefer incremental improvement. One trick in .NET land is to use something like YARP[1], which lets you totally rewrite the app... one web page at a time.

Another management trick on top of that is to not demo the last few steps. Complete the last few milestones of the project quietly, without reporting this up until the very end. I guarantee you that everyone in charge of the budget thinks they can "save money" by skipping the "last 10%", even though that results in 2x the ongoing complexity because it means the legacy components must still remain live and deployed to production.

I guarantee that the only way to prevent this is to lie to management. It is biologically impossible to insert these concepts into the brain of a non-technical manager, so don't even try.

[1] https://microsoft.github.io/reverse-proxy/