Export (0) Print
Expand All

Microsoft Project Server 2002 Data Migration

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
Published: May 1, 2002

Applies to:
Microsoft Project Server 2002
Microsoft Project Central 2000
Microsoft Project 2000

Summary This white paper helps you develop plans and strategies for upgrading and migrating data from Microsoft Project 2000 and Microsoft Project Central to Microsoft Project Server 2002.

On This Page

Introduction
Upgrading Data to Microsoft Project Standard
Migrating Data to Microsoft Project Professional 2002
Conclusion

Introduction

This white paper helps you develop plans and strategies for upgrading and migrating data from Microsoft Project 2000 and Microsoft Project Central to Microsoft Project Server 2002. The Microsoft Project Server Installation Guide Help file, Pjsvr10.chm, covers the details of the server installation process, but we recommend that you read this document first. By carefully planning your migration, you can make better decisions about issues that affect operation and performance of Microsoft Project Server and minimize downtime during your transition.

The scope of migrating an existing database can range from upgrading the schema of a workgroup database to rolling out Microsoft Project Server for enterprise use. Microsoft Project 2000 supported two database schemas, although they could be part of the same database: one for Microsoft Project data and one for Microsoft Project Central data. The upgrade path you choose depends on several factors:

  • If you are upgrading to Microsoft Project Standard 2002, upgrading the database is appropriate.

  • If you are upgrading to Microsoft Project Professional 2002, it may be more appropriate to import data into a new database rather than upgrading the existing database. Importing data into a new database is more appropriate if:

  • You anticipate storing substantially large amounts of data in Microsoft Project Server and will install to a new server, perhaps even running separate Microsoft SQL™ Server and Microsoft Internet Information Services (IIS) servers.

  • You are setting up standards in the enterprise global template to be applied to enterprise projects and resources. Upgrading the existing database does not apply standards such as ensuring all resources have values for required codes.

The Microsoft Project Central database does not store resource pools, projects, and templates, so if you start from either an updated or a new database, these must be added or imported into Microsoft Project Server.

You can upgrade Microsoft Project 2000 and Microsoft Project Central data to work with one of the following two usage scenarios for Microsoft Project 2002:

  • Microsoft Project Server with Microsoft Project Standard

  • Microsoft Project Server with Microsoft Project Professional

The following two sections describe the processes for these two scenarios.

Upgrading Data to Microsoft Project Standard

When upgrading from Microsoft Project Central to Microsoft Project Server, you need to know what data is automatically upgraded from Microsoft Project 2000 and Microsoft Project Central to Microsoft Project Server and what data is not. The following data is automatically upgraded:

  • Resources

  • Project and assignment view definitions

  • Security settings (upgraded to a default configuration based on Microsoft Project Central roles)

However, the following data is not automatically upgraded:

  • Projects (because they are not stored in the Microsoft Project Central database)

  • Status reports

Potential Issues

In cases where the Microsoft Project database tables coexist in the same database as the Microsoft Project Central database tables, the project data must be moved before upgrading Microsoft Project Central to Microsoft Project Server.

Preparing to Upgrade the Microsoft Project Central Database

Before you upgrade a Microsoft Project Central database, do the following:

  1. Process all active update messages in Microsoft Project Central. In Microsoft Project Server, transactions replace project update messages, and update messages cannot be upgraded.

  2. Copy and save any status reports that should be kept. Existing status reports cannot be upgraded.

  3. Prevent further updates to the Microsoft Project Central database by shutting down IIS on the computer where Microsoft Project Central is installed. The database cannot be accessed during the conversion process.

  4. Disallow access to the database to prevent further updates.

  5. Back up the Microsoft Project Central database.

Migrating the Database from Oracle to SQL Server 2000

Microsoft Project Server requires Microsoft SQL Server 2000 or later to take advantage of performance and functionality features unique to SQL Server. Optimizing Microsoft Project Server for SQL Server takes advantage of unique performance and programmability features available only in SQL Server.

To upgrade a Microsoft Project Central database on an Oracle server, do the following:

  1. Create the Microsoft Project Central tables in the target SQL Server database using the Microsoft Project Central Table Create script on the installation CD.

  2. Using Microsoft Data Transformation Services (DTS), copy the data only from the Microsoft Project Central database in Oracle to the new Microsoft Project Central database in SQL Server.

  3. Modify the Microsoft Project Central database registry key to point to the new database, and test the installation to be sure that the data was properly transferred.

Preparing the Upgrade Scripts

After the data and the database have been prepared, you can begin the upgrade process. You may have site database implementation standards to enhance performance or enable consistent maintenance. The following steps are optional:

Note: It is important that columns, data types, nulls, defaults, constraints, and indexes not be altered.

  1. Modify the database upgrade script to specify files and file groups for performance.

  2. Specify database object owner who is not a DBO if required (not recommended).

Upgrading the Database

Performing the Upgrade

To upgrade the database, do the following:

  1. Execute the database upgrade script in Microsoft Query Analyzer or another Microsoft SQL Server query processor.

  2. Check the execution output for errors. If errors occur, identify and fix the cause of the errors, restore the database, and rerun the script.

Verifying the Upgrade

After the Microsoft Project Central application has been upgraded, verify the database upgrade by starting Microsoft Project Server.

Migrating Data to Microsoft Project Professional 2002

This section describes data migration process for Microsoft Project Professional, but the process depends on the specific needs of your organization. Fully migrating existing data to Microsoft Project Professional 2002 can be complex and should be part of a broader implementation review process.

Deliverables from an enterprise implementation review process might include:

  • A business process model

  • View and report layouts

  • Likely sorts, filters, and groupings

  • Custom fields and outline codes needed

Tip If you plan to roll out Microsoft Project Server for enterprise use, read this document in conjunction with the EIF (Enterprise Implementation Framework), which suggests an approach for building an implementation strategy for your business. Assessing the requirements of your business and users includes the selecting and purchasing hardware, deciding on Microsoft Project Server options, designing enterprise custom fields, migrating or importing existing data, and switching production systems.

Preparing for Data Migration

Migrating from Microsoft Project Central to Microsoft Project Server is not a turnkey conversion. Like a classic data migration process, you first install the database tools that you are upgrading to and then migrate the data. For Microsoft Project Central data, break the data migration process into two sequential phases: migrate resource information, and then migrate project plans.

Before you upgrade a Microsoft Project Central database, do the following:

  1. Process all active update messages in Microsoft Project Central. In Microsoft Project Server, transactions replace project update messages, and update messages cannot be upgraded.

  2. Prevent further updates to the Microsoft Project Central database by shutting down IIS on the machine where Microsoft Project Central is installed. The database cannot be accessed during the conversion process.

  3. Copy and save any status reports that should be kept. Existing status reports cannot be upgraded.

  4. Disallow access to the database to prevent further updates.

  5. Back up the Microsoft Project Central database.

Migrating Resource Information to Microsoft Project Server

You should migrate resource information before migrating project plans to Microsoft Project Server. Moving resource information first helps ensure that you account for duplicate resource names that represent the same resources.

Resources and users are maintained separately in Microsoft Project Server—resources as team members or materials assigned to projects and users as logon IDs with permissions on system commands and data. When an enterprise resource is added to Microsoft Project Server, a corresponding user is also created with default permissions. If a user with the same name already exists, the enterprise resource is merged with the existing user account. Microsoft Windows® account information in the user account is synchronized with the newly added enterprise resource.

During the resource migration process, you choose which resources to promote to enterprise resources and which to map as duplicates of enterprise resources. For example, the resource John Smith could be duplicated in separate project plans or (less likely but still possible) in a resource pool as JSmith, JohnS, and John Smith. During the resource data migration to Microsoft Project Server you might choose to promote John Smith as the enterprise resource, and map JSmith and JohnS as duplicates.

Tip Microsoft Project Server does not allow duplicate or merged enterprise resource names, and you cannot delete a resource—you can only make it inactive. For these reasons, it is well worth the effort to create accurate enterprise resource information from the beginning.

If your organization currently uses a centralized resource pool, use the Import Resources to Enterprise Wizard to migrate this resource information to Microsoft Project Server. This wizard can map local field to enterprise custom fields, map enterprise base calendars, and check for common problems such as duplicate names or invalid Windows user account name formats.

If your resource information is not in a centralized resource pool, you can still use the import process to migrate the resource information to Microsoft Project Server, or you can create a central resource pool and share it with all project plans that include resources. Creating a central resource pool may help you identify duplicate resource information between different project plans.

If your resource information resides in another data source such as Active Directory or a human resources database, you can approach resource data migration with one of two goals in mind:

  • Migrate resource data with no further synchronization with an external source.

  • Synchronize resource information between Microsoft Project Server and other resource databases after data migration.

As you begin the import process, keep the following in mind:

  • Not all of the resources in your existing Microsoft Project 2000 projects automatically become enterprise resources, so they don't get enterprise code values associated with them.

  • Resources with assignments don't automatically become team members of those projects.

  • Creating a new enterprise resource that is a non-generic work resource also creates a corresponding user with the following characteristics:

    • Belongs to the Team Member group,

    • Has a blank password,

    • Can log on, and

    • Counts towards Microsoft Project Web Access CAL licenses.

Migrating Specific Project Plans to Microsoft Project Server

After you have successfully migrated resource information to Microsoft Project Server, you are ready to migrate data from specific project plans. The specific data migration path you choose depends on several factors. These factors are explained in detail in the topic "Microsoft Project Server installation roadmap" in the Microsoft Project Server Installation Guide Help file, Pjsvr10.chm. This Help file is included with Microsoft Project Server 2002.

Microsoft Project Central maintains pointers to projects that are stored outside the database. Importing these projects into a Microsoft Project Server database does not map the destination enterprise project with the workgroup project. The only significant data loss is the loss of security settings for the projects. There are tasks to be done after importing a project, such as regenerating actuals and deleting the non-enterprise project to avoid duplicate assignments.

There are two methods of migrating projects to Microsoft Project Server; both methods provide the same data validation, so no projects or tasks are migrated with invalid values or missing required fields. The two methods of project migration are the Import Project Wizard and using Save As on the File menu in Microsoft Project 2002.

With the Import Project Wizard, you can:

  • Map local to enterprise custom fields.

  • Map project resources to enterprise resources, leave project resources as local, or promote project resources to enterprise resources.

  • Import more projects in the same wizard session with the same field mapping.

Using the Save As command does not allow you to perform these actions.

Before you begin the project plan data migration, you may need to address some complicating factors, including the following:

  • If you have master and subprojects, you may see rolled up costs duplicated when the project plans have been migrated to Microsoft Project Server. To correct this duplication, represent master and subproject relationships with enterprise codes. In general, in Microsoft Project Server, think in terms of programs and projects rather than master projects and subprojects. You can still use traditional master projects locally if you want; just don't save them to Microsoft Project Server.

  • If you have dependencies between tasks in different MPP files, open all linked files in Microsoft Project. Save each file to Microsoft Project Server, while keeping all of the linked files open. Microsoft Project resolves the links while the files are still in memory.

Conclusion

Migrating data from Microsoft Project 2000 and Microsoft Project Central to either Microsoft Project Standard or Microsoft Professional with Microsoft Project Server can be a complex process. Migration requires considerable advance planning. Besides this white paper, useful resources for this planning process include the following:

  • The Microsoft Project Server Installation Guide Help file, Pjsvr10.chm (included with Microsoft Project Server 2002).

  • The EIF (Enterprise Implementation Framework) and other content in the Microsoft Project 2002 Resource Kit (available soon on the Microsoft TechNet Web site).

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft