I've helped a lot of people upgrade their SQL 2000 applications to SQL 2005.  While many of these upgrades go well, occasionally some applications have issues and the overall workload may perform more poorly after the upgrade. 

One area where I've seen issues is with ad-hoc on-line transaction processing (OLTP) systems.  This class of application performs a relatively large number of simple compilations.  Often, many of the resultant plans are almost identical and would never change - i.e. there's not many possible execution plans for these queries.   While we make efforts to make sure that the upgrade experience is positive, major releases that take 5 years have a lot of variables that can change.  This can change the "sweet spot" for getting optimal performance out of an application.

Reasons things can perform differently after upgrading include:
 
1. SQL Server 2005 performs more optimizations, and the fixed cost of doing those will go up a bit each release.  Generally this cost won't be very visible, but compilation-intensive scenarios may see some impact.
 
2. The code size of SQL 2005 is larger than SQL 2000 (it has more features).  The working set of these features is also larger in the new release.  This can cause additional L2 cache line misses on both code and data.  Some of the older x86 server machines (say, the 5-year-old machines you may have bought right when SQL 2000 came out) have relatively small L2 caches, and they may see lower cycles-per-instruction after upgrade.  This causes an application to run more slowly.  The newer x86 CPUs have larger L2 caches (2 MB) and tend to do a lot better.
 
3. Some internal components and features were rewritten in SQL 2005, and they may change the exact performance characteristics of an application that is upgraded.
 
For ad-hoc OLTP applications, it's a combination of all of these. 
 
The good news is that there's a way to make many of these applications perform a lot better than even the SQL 2000 level - use parameterized queries.  These can reduce the overall number of compilations significantly, reducing the CPU and memory load on the system.  Generally speaking, if your application is an OLTP application and is not sensitive to plan choice for each query, forced parameterization can be a good way to manage any compilation slowdown.  However, please be sure (via testing) that your application is insensitive to query plan changes, as you can lose all (and more) of your compilation time gains via slower execution of sub-optimal plans.
 
Going forward, we recommend customers take opportunities to examine their stored procedures and other logic to make sure that you're using parameterized queries when necessary to reduce compilation time.  We expect that this will improve the overall system throughput for our customers (even compared to forced parameterization if done to completion).  I've written a fairly detailed blog entry on how to better understand the impact of parameters on plan quality here(http://blogs.msdn.com/queryoptteam/archive/2006/03/31/565991.aspx), so I hope it can help you in tuning this application as well.
 
I hope that this helps you when you are planning SQL 2000 to SQL 2005 upgrades.
 
Conor Cunningham