Random tips in no particular order...
Tip 1:
Whenever possible, prior to performing a migration, reporting should be done against the source. Many 3rd party paid-for tools provide reporting capabilities (I am unsure of whether or not the free tools offer reporting). It is especially the case that you are likely to encounter errors during the migration if your source environment is an on-premise file server. The older the OS of the file server, the more shitty the errors will become (in my experience).
Tip 2:
Future permissions management should be considered prior to performing the migration. If the end-users are managing their own permissions then you may opt for a group-connected Team Site even if you don't need the O365 Group sitting behind the site, the reason being, its easy for end-users to manage permissions when its a group-connected site.
If IT Admins are managing permissions then you may decide to use the non-group-connected Team Site template, because having an O365 Group supporting every site can become tedious and IMO creates a ton of unnecessary infrastructure.
Tip 3:
Always perform migrations after hours to minimize throttling. If you have a big migration project that is planned for the future you can submit a ticket to Microsoft and request for your throttling limits to be removed temporarily. I've been successful with providing them a window by which throttling should be turned off and we were able to move a lot more data a lot more faster. Sometimes it can be a bit cumbersome to get it setup and working - maybe that is because Microsoft is reluctant to do this, idk.
Tip 4:
Free tools are great if you're on a budget, otherwise, using 3rd party tools provide added capability that is nice to have and in most cases it ends up saving a lot of labor expense (employee time).
Tip 5:
Communication plans/strategy is just as important as the migration itself. Improper or too short of notice communications **can single-ha
(Réponse tronquée)
