Migration best practices for Project Server 2007
This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.
Topic Last Modified: 2016-11-14
This article describes best practices to observe when migrating to Microsoft Office Project Server 2007 from a previous version of Project Server.
In this article:
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 Office Project Server 2007 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 are migrating project workspaces from Project Server 2003, then make sure that the appropriate Windows SharePoint Services language packs are installed on the Microsoft Windows SharePoint Services 3.0 farm. For example, if you are migrating Japanese Windows SharePoint Services 2.0 workspaces, then ensure that Windows SharePoint Services 3.0 is a Japanese server or that an appropriate language pack is installed.
If you have projects that contain subprojects, ensure that the subprojects are migrated before the master projects in the migration configuration file. If you are not sure whether your projects have subprojects, run the following query on the Draft database to get a list of projects in your system — subprojects are listed towards the top. If you use the same order in the migration configuration file, you can be sure that subprojects are migrated before master projects.
DECLARE @hierarchy TABLE ( CHILD_PROJ_UID uniqueidentifier, PARENT_PROJ_UID uniqueidentifier, LEVEL INT NOT null ) DECLARE @nrows INT SET @nrows = 0 DECLARE @level INT SET @level = 0 INSERT INTO @hierarchy (CHILD_PROJ_UID, PARENT_PROJ_UID, LEVEL) SELECT PROJ_UID, NULL, 0 FROM dbo.MSP_PROJECTS WHERE PROJ_TYPE = 6 -- master projects SET @nrows = @@rowcount WHILE @nrows > 0 BEGIN INSERT @hierarchy SELECT a.CHILD_PROJ_UID, a.PARENT_PROJ_UID, @level + 1 FROM dbo.MSP_PROJ_HIERARCHIES AS a INNER JOIN @hierarchy AS b ON (b.CHILD_PROJ_UID = a.PARENT_PROJ_UID) WHERE b.LEVEL = @level SET @nrows = @@rowcount SET @level = @level + 1 END SELECT b.PROJ_NAME AS 'Sub Project', c.PROJ_NAME AS 'Master Project' FROM @hierarchy a LEFT JOIN dbo.MSP_PROJECTS b ON (a.CHILD_PROJ_UID = b.PROJ_UID) LEFT JOIN dbo.MSP_PROJECTS c ON (a.PARENT_PROJ_UID = c.PROJ_UID) WHERE a.PARENT_PROJ_UID IS NOT NULL ORDER BY a.LEVEL DESC
If your Project Server 2003 database size is greater than one gigabyte while backed up, then 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). This is not a migration-related issue, but it may affect migration.
If you are setting up a new server in the farm, certain directories must be consistently located for all servers in the farm. Windows SharePoint Services 3.0 manages servers on the farm, and the following directories must be in the same location on all servers in the farm:
Program files directory
ULS trace log file directory
Make sure to apply the latest update to the migration tool. This can be done by applying the latest cumulative update to the Office Project Professional 2007 client from which you are using the migration tool. Visit the Project 2007 Solutions Center on the Microsoft Help and Support site for more information about Office Project Professional 2007 updates.
Migrate and publish all relevant administrative projects first. This ensures that the non-project time reflects in the Office Project Server 2007 resource availability.
During gradual migration, do not delete any migrated custom field definition before the entire migration is complete. The migration utility stores the mapping between the Project 2003 enterprise custom field ID and the migrated Project 2007 enterprise custom field GUID (the mapping is stored in the Office Project Server 2007 Draft database). To illustrate, imagine that you delete the Office Project Server 2007 custom field definition and then try to migrate a project with values for this enterprise custom field. Because the equivalent Office Project Server 2007 enterprise custom field is not available, the project enterprise custom field values will be converted into local custom field values.
During gradual migration, do not delete any migrated lookup table entry before the entire migration is complete. The migration utility stores a mapping between the Project 2003 enterprise lookup table entry and the migrated Office Project Server 2007 enterprise lookup table entry (the mapping is stored in the Office Project Server 2007 Draft database). To illustrate, imagine that there is an enterprise project text lookup table definition called "Country/Region" with the following entries: US, China, UK, India. It gets migrated successfully. Then someone deletes the "India" entry in Office Project Server 2007. After that, you try to migrate a project from Project Server 2003 with the "Country/Region" enterprise project custom field having a value of "India." This value will be lost, because the "India" entry was deleted in Office Project Server 2007.
Do not delete any migrated Project Server 2007 enterprise resource for the duration of the migration. To illustrate, image that such a resource were deleted, and you 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.
Indicate clearly which projects in Project 2003 have been migrated. Because the migration tool does not write to the Project Server 2003 data during the migration process, there is no way to "mark" which projects have been migrated from Project Server 2003 to Office Project Server 2007. However, there are many ways you can do this.
Remove login access for users in Project 2003
Make all the migrated projects read-only in Project Server 2003.
Append a "migrated" prefix to the names of the migrated projects.
If you are doing gradual migration, lock down or archive the migrated projects in Project Server 2003 so that the projects are not edited in two places. One way to archive the projects is described in the Knowledge Base article named How to archive project plans in Project Server 2003 and in Project Server 2002 (http://go.microsoft.com/fwlink/?LinkId=78243\&clcid=0x40).
Rename or disable the built-in Project Server–authenticated administrator account migrated from Project Server 2003. This account will be migrated to Office Project Server 2007 like any other user/resource in Project Server 2003. Office Project Server 2007 does not have a built-in administrator account for better security.
Download this book
This topic is included in the following downloadable book for easier reading and printing:
See the full list of available books at Downloadable content for Project Server 2007.