This is solid advice. Particularly: Have a staging system where you can practice your migrations - ideally you should have a full migration into staging at some point and the users (whoever they are) look at the results and sign it off (or, more likely, they find 50 important fields they forgot to mention earlier - its only once people see tangible results of the migration that they really think about which bits are important).
Lastly, avoid committing to a schedule if at all possible. Well thats just good advice for any situation, if only it were that simple
> Lastly, avoid committing to a schedule if at all possible. Well thats just good advice for any situation, if only it were that simple
I wrote this over a decade ago. I agree it is almost impossible to not have a schedule.
If I were to update it based on what I know today, I'd say: "break the migration up into pieces if at all possible, and build a schedule based on that. Always make it clear that a schedule is an estimate. Don't do a migration for a fixed price--there's too much uncertainty."
I remember once migrating from a system with periodic service contracts, where the old system set dates for all future contracted services at time of signing and the new one just calculated them as in start on X date then every 2 weeks. Ball ache. Having everything scripted so we could just keep running and tweaking and running and tweaking till it was right, then press go on the day was a good way to go. Of course the whole project was cancelled just before go live, but the migration worked like a charm.
Lastly, avoid committing to a schedule if at all possible. Well thats just good advice for any situation, if only it were that simple