Migration best practices (Project Server 2010)

 

Applies to: Project Server 2010

Topic Last Modified: 2013-12-18

Review this list of best practices to observe when migrating from Microsoft Office Project Server 2003 to Microsoft Office Project Server 2007.

  • Do a pilot migration with a small department. It is sensible to experiment with the process by starting with a small migration rather than a large one.

  • Back up your Project Server 2003 database before migration. This action enables you to easily restart the migration process if an error should occur.

  • Make sure no users are editing project data during migration. The edited data would not be migrated properly.

  • Upgrade Microsoft Windows SharePoint Services data first, and then the projects. If you do not follow this sequence, after migration you will need to republish the projects to get them all linked to their SharePoint sites in Office Project Server 2007.

  • If you have projects that contain subprojects, ensure in the migration configuration file that the subprojects are migrated before the master projects.

  • Set your database recovery model to Simple in Microsoft SQL Server before starting migration. Otherwise, you may run into a situation where the database transaction logs of the Published and Draft databases reach their size limits (because so many projects are being added to the database at once).

  • Migrate and publish all relevant administrative projects first. This ensures that the non-project time is reflected in the Office Project Server 2007 resource availability.

  • Do not delete any migrated Project Server 2007 enterprise resource for the duration of the migration. To illustrate, imagine that such a resource were deleted, and you then migrate a Project Server 2003 project that uses this enterprise resource. The enterprise resource in the migrated project would become a local resource after migration. However, the enterprise resource could be recovered: If you were to add the deleted resource back again (with the same name or Windows NT account) and resave the project, then the project manager would be prompted to replace the local resource with the enterprise resource.

  • Keep the number of projects to migrate below 1000 in each configuration file. Each migration configuration file should not exceed 1000 projects to be migrated at one time.

  • During the migration of projects, publish only the projects with a Published version. Because a given project can have multiple versions but at least one which is called .published, be sure that a project with a version different than .Published is not automatically published during the migration process.