[*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**](https://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**](https://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 https://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.**
----------
Edit:
You can use **powershell** to migrate your all databases from one server to another as described at [Use PowerShell to Migrate Entire SQL Server Instance (db, logins, jobs, etc)](http://gallery.technet.microsoft.com/scriptcenter/Use-PowerShell-to-Migrate-86c841df)
>Migrates databases with simple or complex file structures via backup & restore or detach & attach. Also migrates users with passwords, SIDs, server & db permission sets, server & db roles, server configuration settings, SQL Agent objects, user objects in systems databases.
[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/