I'd put a caveat on step 5 as it depends on your backup routines. If your doing daily full's then doing a diff wont help if you have waited more than a day to upgrade as the diff is only what's changed since the last full so that method will not work. But should you do the upgrade in the period before the next full backup then yes this step will still be valid.

How ever if your doing regular transaction log backups, these are not dependent on the full or diff so these can be replayed providing you have a full log chain from the full backup you restored initially back into the new clusters databases. Again set to read only and perform a final transaction log backup to ensure you have captured all of the transactions up to the point you take the database to read only mode.

Alternatively you could setup log shipping to the new cluster then you only have the last few logs to restore.

Also a point to not is that its a massive piece of work to downgrade back to 2005, so as always backup, backup, backup your 2005 last version and store them somewhere just on the off chance you need to downgrade, then you can restore your 2005 version and do a data differential using a Data Compare tool like Red-Gates, or by creating linked servers and manually querying the two sides to see whats needed to reimport back into the 2005 version. Or you go down the route of you re-create the schema and reimport the data straight from 2008.