This most often comes up in rewrites (which are usually a mistake) and the problem is that time doesn't stop once you start you rewrite (or, more generally, your long term plan). Features get added to the original. Bug fixes are made. Software entropy happens. These need to somehow be folded into your new thing. Or worse, you halt new development on the old while you write the new.
I've seen pointless rewrites with a 6 month estimate take 3.5 years to deliver, all the while the once-leading old version languished.
More generally a lot of this comes down to risk management. Your long term plan needs:
1. Shorter term milestones. Due to changing circumstances you may end up terminating your long term plan early. You should aim to have something to show for it if that happens. Ironically, having something to show for it makes this outcome less likely;
2. Reversibility: your migration (data, software, etc) needs to be reversible; and
3. Incrementality: you need to be able to gradually roll out your long term plan. It can't be all or nothing.
This is a common pattern in data migrations:
1. Double-write to the old and new systems. Start doing this with a small percentage of users (<=1%). Identify problems, fix them, rinse and repeat. Do nothing with the new data;
2. Increase the rollout to 100% gradually;
3. Have the system be able to read from the old or new system and work fine;
4. Roll out a small number of users to read from the new system. If this goes badly, you just read from the old;
5. Identify and eliminate all the old call sites reading from the old;
6. Once old data traffic gets to zero you can switch it off.
I've seen too many systems where the project plan is basically to shut down development for 18 months while you write the new (often leaving non-critical bugs in place), do a 3 day data migration where the system is down and hope everything works.
This most often comes up in rewrites (which are usually a mistake) and the problem is that time doesn't stop once you start you rewrite (or, more generally, your long term plan). Features get added to the original. Bug fixes are made. Software entropy happens. These need to somehow be folded into your new thing. Or worse, you halt new development on the old while you write the new.
I've seen pointless rewrites with a 6 month estimate take 3.5 years to deliver, all the while the once-leading old version languished.
More generally a lot of this comes down to risk management. Your long term plan needs:
1. Shorter term milestones. Due to changing circumstances you may end up terminating your long term plan early. You should aim to have something to show for it if that happens. Ironically, having something to show for it makes this outcome less likely;
2. Reversibility: your migration (data, software, etc) needs to be reversible; and
3. Incrementality: you need to be able to gradually roll out your long term plan. It can't be all or nothing.
This is a common pattern in data migrations:
1. Double-write to the old and new systems. Start doing this with a small percentage of users (<=1%). Identify problems, fix them, rinse and repeat. Do nothing with the new data;
2. Increase the rollout to 100% gradually;
3. Have the system be able to read from the old or new system and work fine;
4. Roll out a small number of users to read from the new system. If this goes badly, you just read from the old;
5. Identify and eliminate all the old call sites reading from the old;
6. Once old data traffic gets to zero you can switch it off.
I've seen too many systems where the project plan is basically to shut down development for 18 months while you write the new (often leaving non-critical bugs in place), do a 3 day data migration where the system is down and hope everything works.