Migrating your Project Plan as easy as 1,2,3
It is easy, isn’t it? You’ve been managing your project in one planning tool and you need to migrate it to another. It’s just a matter of finding a mutually compatible format and simply exporting and importing, hardly worth losing sleep over. Then reality dawns and it quickly becomes clear that nothing about this task does exactly what it says on the can.
It’s not for want of trying on the part of the software authors, but it’s a half-hearted effort for the most part because however keen Oracle, Microsoft, Asta, etc are to help you move into their world, they are naturally going to be rather less helpful when you want to leave them.
This is typified by Microsoft’s approach to conversion from its native (.mpp) files. If you want to convert that MS Project file you’ve just been given to another format then you need to have a licensed copy of MS Project installed, which will of course lead you to wonder whether it’s easier to just stick with MS Project. That’s just the start of the obstacles, because Project has been through a number of versions each of which will require a different conversion routine to be provided by the supplier of the target software and the right version of MS Project too. Thus you will not be able to import an MS Project 2010 file if your copy of MS Project is 2003 without some pre-conversion conversion.
In theory these difficulties vanish if you opt to carry out the migration via the ubiquitous XML format, but that has its own issues. Firstly it’s not a single common standard and there’s a significant difference between say MS Project XML and Primavera XML, but even when that’s overcome there’s the matter of bloatware; yes, XML files are bloated, in fact a typical MS Project file with a reasonable number of Custom Fields will morph into an XML file orders of magnitude larger and I’ve seen examples of projects 30 mb in size producing XML files on the gigabyte scale.
None of these formats are stable either and many otherwise seasoned planners have been broken by the mystery errors generated when someone left a blank line in their plan, or that long running xml import finally failed altogether because of some tiny conversion issue. Such problems come in various guises, rarely well trapped and described by the import utility and are prevalent regardless of the source and target software.
Let’s suppose that you’ve cracked the technical issues, so now all you have to worry about is the data itself? Is it like for like? For example MS Project allows you to embed projects within projects within projects to link tasks between them and link summary tasks too, there’s only one milestone, there’s Custom Fields, just one milestone type, project specific resources, project specific calendars, volatile activity ids, inconsistent scheduling, etc and your target environment may baulk at these “features”. To make matters even worse your MS Project “Programme” may well be corrupt anyway (just google “corrupt ms project”!).
Are you beginning to get the message, this apparently simple process is actually a real nightmare and, if you don’t recognise this, there’s a high likelihood that your migration is going to hit a wall.
Fortunately we do understand and Project Pilots has a lengthy track record for conducting such migrations, we know where the skeletons are buried and we have the hard earned expertise and the tools to overcome them.
If you’d like to know more about how we can help defuse this minefield for you, then email enquiries@projectpilots.net for further information.
