Project Server 2010 Beta migration / upgrade overview

After having a couple of days to test the migration procedures to 2010 I wanted to share my experience in this blog entry for everyone to see.  

Overall I would say that the migration process is quite straightforward, certainly compared with what we used to have to do from 2003 – 2007! I’ll start by detailing the options and requirements for migration as at Beta2 of Project 2010:

Upgrade Options

To upgrade to Project Server 2010 from 2007 the following options are available:

1.       In-place upgrade – in which the existing 2007 servers are directly upgraded.

2.       DB-attach upgrade – whereby you upgrade a backup of the databases only.

3.       Full database migration from Project Server 2003 –

Upgrade Requirements

Different circumstances require the use of different option, or options in the case of number 3. However the specific requirements for each can be summarised as:

1.       In-place requirements:

a.       Existing Project Server 2007 must be installed in a 64-bit environment including SQL Server 64bit.

2.       DB-attach requirements:

a.       Extra hardware is required on which to run 2010 separately from the 2007 version.

3.       Project Server 2003 requirements:

a.       This is a two step upgrade – first migrate from 2003 to 2007, then 2007 to 2010 using either method 1 or 2 above.

b.      For this migration a Virtual Migration Environment (VME) is available for use, it contains a fully pre-configured 2007 instance including all required tools in a Hyper-V image format. Using this requires the use of a DB-Attach upgrade for the second step.

Other requirements:

SQL Server version required for the server which will host the 2010 databases is as follows;

  • 64-bit version of SQL Server 2008 SP1 with CU2, or
  • 64-bit SQL Server 2005 SP3 with CU3.


Once the upgrade is complete the restored databases will be configured in Backwards Compatibility Mode, which enables the following:

Backwards Compatibility Mode (BCM)

  • Enabled by default after upgrading
  • Enables connection to Project Server 2010 by Project Professional 2007 clients
  • Can be disabled from Server Settings, but then can not be re-enabled

 Note: When enabled the following client features are disabled:

  • Manually scheduled tasks are not available on the server or client.
  • Tasks cannot be set to inactive.
  • Font strikethrough is not available.
  • All departmental custom fields are enforced in Office Project Professional 2007.


Upgrade Procedure Summary

In-place upgrade

The in-place upgrade is similar to a typical MOSS service pack installation, once all software version pre-requisites have been met (Oct CU, SQL + CU, etc) then the process is roughly as follows:

1.       Stop WWW service on all front end servers and stop Project Queue service on all application servers

2.       Install SharePoint 2010 binaries on all servers in farm (do not run config wizard yet)

3.       Install Project Server 2010 binaries on all servers in the farm

4.       Run the SharePoint Configuration Wizard on the server hosting Central Administration

5.       Run the SharePoint Configuration Wizard on the remaining servers in the farm

6.       Restart all Queue and WWW services previously stopped

There you have it.

Share and Enjoy !


Project Server 2010 Migration Requirements

I’m doing some testing this week on migrating to 2010 so I have a few things I will be blogging about in the next day or so, but I noticed that my draft blog is getting very long so I thought I’d split one very important part of it into a separate entry altogether.

A few things have come out as obvious ‘gotchas’  in the migration requirements, and I’ll summarise them here quickly;

  • In-place migration requires 64bit Project Server / MOSS in order to ‘upgrade’
    This one is no surprise as 2010 is 64bit only.
  • Upgraded 2007 installations need to start by running all latest patches (as of October ’09), so that means:
    Project Server OctCU, MOSS OctCU, WSS OctCU, SQL 2005 SP3 + CU3 OR SQL 2008 SP1 + CU2. It’s worthwhile when doing any new installs from no onwards to START at that level.
  • DB-Attach upgrades (more on the upgrade methods in my main blog), which is probably the method that will be used 90% of the time due to #1 above will need Workspaces provisioned OUTSIDE of the default content database, i.e. Not at /PWA.
    Fortunately there are steps provided in the  migration guide to move your workspaces to a new site collection and content db so that this is possible.


Come back later for more comments and some lessons learnt.

Share and Enjoy !