[*Disclaimer : SQL Server 2005 is out of mainstream support. - extended support ends for sp4 on 04/12/2016*][1]

Migration always have a downtime. So depending on how much your downtime  is, you can go with setting up either :

 1. **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.

 2. **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.][2]. 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**](http://dba.stackexchange.com/a/36701/8783) 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**](http://dba.stackexchange.com/a/50315/8783) 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][3] on the new server.
 - Have [multiple tempdb data files][4] with equal size.
 - [Enable Trace Flag 1118][5] -  [to assist in TEMPDB scalability by avoiding SGAM and other allocation contention points.][6]
 - 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][7] from Brent Ozar.**  Run it and address the critical and high priority issues reported by it.
 - You can even use **[SQL Power Doc][8]** 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.**


  [1]: http://blogs.msdn.com/b/sqlreleaseservices/archive/2011/01/27/end-of-mainstream-support-for-sql-server-2005-and-end-of-service-pack-support-for-sql-server-2008-sp1.aspx
  [2]: http://support.microsoft.com/kb/2001270
  [3]: http://sqlblog.com/blogs/tibor_karaszi/archive/2009/03/09/do-you-have-instant-file-initialization.aspx
  [4]: http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-1230-tempdb-should-always-have-one-data-file-per-processor-core/
  [5]: http://www.sqlskills.com/blogs/paul/misconceptions-around-tf-1118/
  [6]: http://blogs.msdn.com/b/psssql/archive/2008/12/17/sql-server-2005-and-2008-trace-flag-1118-t1118-usage.aspx
  [7]: http://www.brentozar.com/blitz/
  [8]: http://sqlpowerdoc.codeplex.com/