Options for maintaining archival/historical Project Server 2007 data

I have a customer who will be installing and configuring Project Server 2010 this summer.  The upgrade plan is to configure Project Server 2010 as a fresh, new install with no data migration from Project Server 2007.  This being the case, the question came up about how to preserve the Project Server 2007 data.  I suggested the following options, assuming the production Project Server 2007 environment will be decommissioned and the servers recycled for some other use.

1. Back up production DBs and store on a shared drive.
   1. DBs can be restored to a test server to pull specific project plans, then the test server can be recycled.
   2. This is a method commonly used for restoring plans that have been completely removed from production databases including ProjectServer_Archive_DB, but still exist in old backups of the database.
2. Move plans you want to keep to the Project Server 2010 production system.
   1. Open plans from the 2007 server that will be needed on the 2010 server, save as .mpp files, import plans into the 2010 server, save and publish, allow the archive process to run at night, then delete the copy of the plan from the draft and published databases leaving a copy in the archive database. This copy can be made available at any time by using Server Settings > Administrative Restore.
   2. This option runs the risk of having someone request a plan in the future that was not saved to the new server. You would have to fall back on the first option to recover that plan.
   3. This option is the most manual labor intensive and the least attractive, in my opinion.
3. Recommended Option: Move production DBs to a standalone test server.
   1. This is a single server running the SQL Server, Project Server application server, and Project Server web front end.
   2. Production servers can be decommissioned, ensuring no one accesses the 2007 PWA URL, while maintaining an historical/archival snapshot of the production 2007 environment and projects in a test environment.
   3. The standalone server can be virtual and generally have lower specifications than production servers and even other test servers.
   4. Projects are always available at any time and can be referenced or pulled from the standalone server whenever you need them.
   5. I would turn off the any AD syncs that run, the cube build after it runs once.
   6. The initial labor involved isn’t terribly large and once it’s set up and configured, you always have access to it, the URL will only be circulated amongst those administrators who need it and they can retrieve plans for PMs who request them.