I would slipstream Service Pack 2 (and perhaps Cumulative Update 2 as well) into the R2 installer prior to running the upgrade, especially if you have enabled the extended partition support. This guide walks you through slipstreaming (it talks about a different service pack and CU, but the process is the same). Slipstreaming will save you a bunch of time and service restarts, since you should be installing the latest service pack at least and not be leaving your new instance at RTM (it is no longer a maintained branch).
You shouldn't have to change SSIS packages.
If you can afford a side-by-side upgrade (e.g. you have another machine or adequate resources for another instance on the current machine, and can re-point your apps later), it will be slightly safer and require less downtime than an in-place upgrade (though it will be more work). You can install another instance, get your logins and jobs set up, then mirror or log ship your user databases to the new instances. When you've ready, you can fail over, take the old databases offline, then the new instance is the primary and you just need to re-point your apps.
Personally, I haven't had any problems with in-place upgrades, but I would probably opt against them if possible in a mission critical environment. The main point is if you do side-by-side and something goes wrong, you can take the new instance down and rebuild from scratch, and it doesn't affect your production system. If something goes wrong in the middle of an in-place upgrade, then you'll be in scramble mode... do we have current backups? Where do we restore them?
In either case, you'll want to make sure you take proper backups before the upgrade.
You will want to update statistics once the upgrade is complete, and if you're on Enterprise Edition and using data compression on tables with nvarchar columns, you may want to rebuild those indexes, since one of 2008 R2's primary advantages over 2008 in the OLTP world is Unicode compression. I wrote a few blog posts about this:
Generally speaking, if you just reapply of the stored procedures and no errors show up, you should be good to go (based on my experience from migrating 2 databases (2000->2005) (2005->2008). On a side note, this is why we started writing unit tests for our database code to handle problems like these.
Best Answer
There are no tools, so to speak. At least not that I am aware. The best thing to do is to test your code, verify your configurations and ensure that SQL Server is functioning optimally. I am hoping that you did this upgrade in a dev or test environment first and that you followed a process with steps that you can repeat again in production. If that's the case, do a full test of your code that interacts with SQL Server. Ensure everything functions as it did before and make sure that all of your maintenance works and that everyone can connect to it at as before.
I would also look in your SQL Server Error Logs and see if there are any issues. Same thing with your windows event logs (particularly your system and application event log)
I recently gave an answer here that talks a whole lot more about SQL Server Upgrades. Lastly, have you considered what you'll do about DB Compatibility Level? If you haven't, you might want to think about changing that for your databases to SQL 2008 and seeing if all works after a regression test. But please make sure you are in a dev or test. I do not advise just changing this in production, nor do I advise starting with an upgrade in production.