Any administrator preparing for a significant system migration knows this: You need to plan for things to go wrong, because they usually do. I planned to start my migration on a Friday night, as a business might, to concentrate downtime in less-critical periods. Almost immediately I ran into two roadblocks that were my fault alone.
The first: the domain I was migrating was configured in a complicated way, registered at one registrar but with the authoritative DNS at a different one. Furthermore, the domain was locked at the registrar. I ended up having to make changes at both registrars, but unlocking the domain required filling out a form and faxing it and photo ID to the registrar. Worse, because it was a Friday night there was a good chance nobody would see it till Monday morning. (This process may seem absurdly primitive and cumbersome, but it's part of an effort to protect domains from theft and abuse and I appreciate the need to impede speed, lest domain thieves do their dirty deed.) Fortunately, there were things I could do while waiting.
Once the domain was unlocked, I ran into problem number two, which was that the email address I was going to use for the administrator of my Office 365 domain was the same as one I had been using for many years as a Windows/Live/Passport ID. Microsoft's systems were so confused by this that it took a good 24 hours working with a support escalation engineer to get it fixed.
The final barrier was migrating the data itself, also explained earlier.
If I had the resources and the time I might have been able to do more of the work in advance of changing the actual domain structure, but it doesn't change the overall lesson: You need to know what to expect when you actually start throwing switches in a migration. I should have planned it out better in advance and investigated each stage of the process.