Hi Sally,
This isn't a trivial operation and I'd strongly advise engaging with a
Partner that could do this for you. There's a great deal more to it than
just moving projects around.
For one thing your new Server will presumably have a different name than the
old one so you'll have to reconfigure your OLAP services and cube
permissions, and check that the cube builds OK.
I would also higly recommend that you save each project plan as an mpp file.
(make sure all outstanding updates are processed first). You can also do
this with your resource pool but the issue here is that you may lose your
enterprise outline code settings and will have to rebuild these from
scratch. BUT please do not copy and paste - this is asking for trouble.
The only way to clean up a duff database (apart from ensuring that duff data
doesn't get in there in the first place) is really to export each project to
mpp, rebuild the resource pool, rebuild the outline codes, re-import the
projects, and reset the values. You'll then to re-publish all assignments
for each project and rebuild the OLAP cube and Analyser Views. You'll also
need to rebuild any Project Center, Project detail and any other PWA views
you had.
This is time consuming and the more projects you have the longer it will
take.
We had a client a few months ago that migrated from Project 2002 to 2003.
They changed one of their Project level outline codes and were getting
strange values in some of the fields in the database. We knew about this in
the Project 2002 database and recommended a clean migration to them. There
were about 300 projects and we suggested about 15 consulting days to do the
whole migration and checking. They couldn't wait that long (partly budget
and partly time constraints from Snr mgmt I think)and went with the quick
option of simply running the migration tool on the SQL DB, much against our
recommendation. Not surprisingly they then had a whole set of issues with
Project Server, which seemed to accumulate over time, and we ended up
re-installing from scratch and doing the whole thing over. We didn't like to
say we told them so - but we did - and it cost them a lot more than it would
have done if they had followed our recommendations.
The moral of the story is that there are no shortcuts here. You inherently
build risk into the implementation by cutting corners so don't do it.
As I said I strongly recommend that you engage with a partner and take their
recommendations on board. If they are doign their job and you ask them to
shortcut something they will identify the risks to you. If you choose a
risky route you will greatly increase the exposure of the project to
failure.
What happened to our client - we'll they finally admitted that they didn't
do it right. It took twice as long to implement and nearly twice as much,
but they now recognise the value of support from a suitably qualified
Microsoft Project Partner. We spend about a day a week with them now as
hand-holding support (and will do over the next few months) in order to
ensure they are set up properly and the system works for them. They also
have an established support contract with us so we can provide 24/7 support
to them through our helpdesk. In our view that's a very sensible approach !
I've heard similar stories from other partners over the last few months -
not all of them with as happy an ending as ours.
Still I hope that sheds some light on the situation and enables you to make
an informed decision.
Regards & best of luck !
Gary.
