Migration always have a downtime. So depending on how much your downtime is, you can go with setting up either :
- Logshipping ( I have used this method and it reduces the downtime considerably)
a. Set up logshipping from the source to destination server as usual. Keep the sync time 1 min (which is minimum).
b. On the day of migration, make sure the logbackups are in sync.
c. Stop all the logshipping jobs and then take the final tail log-backup and put the primary databases in no-recovery mode (this is just in case you need to go back to primary).
d. restore the tail log backups on the secondary with recovery bringing all the secondary databases online.
- Database Mirroring : I do not recommend mirroring for migrating 200 databases as you will easily exhaust the worker threads as described in this KB article.. If there were less databases, then this would be a viable option.
If you have enough downtime then I would recommend
backup / restore method (as opposed to detach / attach) as if something goes wrong, you atleast have a good backup to restore back. this script will get you started with moving all the logins and databases. Just modify it to use backup / restore (or take full backups before running the script - as it uses detach/attach method).
Things you can do prior to migration :
Refer to this answer for migration steps. Some may apply to your scenario as well.
script out all the jobs / ssis packages, etc --OR -- As suggested by @shanky, you can restore the system databases from the old server to new server before hand - that will give you all the logins, jobs, etc on the new server.
turn on Instant File Initialization on the new server.
Have multiple tempdb data files with equal size.
Enable Trace Flag 1118 - to assist in TEMPDB scalability by avoiding SGAM and other allocation contention points.
Configure max and min memory correctly. Especially Max memory away from default.
Properly adjust the MAXDOP settings. Refer to http://dba.stackexchange.com/a/36578/8783 for more details.
Best is to install sp_Blitz from Brent Ozar. Run it and address the critical and high priority issues reported by it.
You can even use SQL Power Doc from kendalvandyke - SQL Power Doc works with all versions of SQL Server from SQL Server 2000 through 2012, and all versions of Windows Server and consumer Windows Operating Systems from Windows 2000 and Windows XP through Windows Server 2012 and Windows 8. Also useful for Planning upgrades - see what hidden features are in use on an instance.