Migrating To Primavera Cloud In Less Than 5 Days

The Emerald team just completed a client migration to the Oracle Primavera SaaS Cloud. The client had over 1000 small (50-60 activities) projects in their on-premise Primavera P6 PPM v8.3.2. They needed to be able to share the projects for the next 2 years amongst a large collaborative program team with multiple contractors and engineering firms. This program is very high profile and reporting is paramount.

P6-Loader v4 Cloud – Got Us There

Now not only did we migrate from P6-PPM to P6-EPPM, we also upgraded from P6 v8.3.2 to P6 v15.1. We were able to turn the project around in less than 5 business days. This includes both the staging and production environments.

The process we used was to copy the P6-PPM database and restore it onto our servers. We verified the global and project data elements in the P6-PPM database and developed the migration plan of what we needed to move and what didn’t along with what the best approach was going to be. Before we started the migration process, we had a brainstorming session with the Emerald integration and implementation team to come up with alternatives and the best techniques for the migration. We decided on two likely approaches to migrating the P6 data to the Oracle Cloud ; either entirely with the P6-Loader, or a mixed approach, in case we ran into any unexpected errors or roadblocks.

We used our P6-Loader to extract and upload all the global data to get the foundation set. That went well with no issues. By day one, all P6 global data and user information was migrated to the cloud. This included – all the calendars and their exception and detailed working hours, all the project, resource and activity codes, resources and UDFs, all the role teams, resource rates, all the global and project profiles, the EPS and OBS structure, the users and their OBS assignments.

Once the global data was in and verified, we then proceeded to move the project and baseline data. This is where things got interesting. We ran into some unforeseen problems related to performance and to data integrity and cleanliness.

In running the new P6-Loader v4 Cloud version we use the P6 WebServices to move the data from Excel to P6 while maintaining security and P6 business functionality. We have been using the WebServices for several months now and knew we needed to deal with the potential for lag and latency going over the internet. We have refined the way the P6-Loader works as a result to improve the manner of processing and the speed we get out of it. Unfortunately we were not expecting such slow load time into the staging area. Imports were roughly 3-5 times slower than we expected.

Now, when you extract from P6 and upload back to P6, we don’t expect any data issues, but we ran into unexpected data loading errors that the WebServices was picking up in the upload. The biggest problem areas were around durations, dates, logic types.

Since we had a tight deadline, we decided to switch from 100% P6-Loader to a mixed approach.

To move the project data, we used an Emerald modified XML export/ import, and this is where having a team of dedicated professionals pays off. Since this was a PPM installation, with no web access, that had some persistent data issues preventing those projects from being exported with P6 client, we needed to get creative fast. And with over 1200 projects to import, using the P6 Web to import XML files was not going to be practical when you need to select the import actions, EPS destination node and each baseline for each project. That would be over 3000 clicks!

Where the P6 client and P6 web failed, the API was able to shine. We created a small API script, written specifically for this, to keep track of the original baselines of each project and to restore them as actual projects. After those baselines were exported, we wrote another API script to export 1200 projects to 24 XML files, which means each XML file had 50 projects in it. At the end of this process, which took a few hours, we had 24 VERY big XML files and we needed to load them into the database.

Since P6 client is much more user friendly for importing - for example it lets you use a default EPS node to import into - we used the P6 client to get the projects and baselines imported into the Oracle Primavera Cloud staging database. We queued up all 24 files to be processed overnight and, in the morning, all the files were there with the exception of a few outliers that we fixed ourselves.

We then had some 1200 projects in the root EPS node. Now, moving these into their appropriate EPS nodes manually would scare anyone off, but not so much when you have the P6-Loader. We extracted all the project and baseline details into Excel, mapped them to their correct EPS nodes and very easily and quickly (less than 10 minutes) we remapped 700 projects and 500 baselines in the Oracle Cloud database. We then submitted one final Excel file to relink the baselines for each project. Again this was less than a 5 minute process. This saved another 2000 user clicks by not having to click Manage, Copy, Select for each baseline assignment. The process was simple, fast and very reliable with the P6-Loader.

We then did some validations using the P6-Loader, Excel and project layouts with summarized data. Again we found a few odd discrepancies related to resources and costs that we hunted down. There seemed to be some uncalculated tasks in the original P6-PPM database, and we found, verified and ensured all was matching.

Then – we did it all again in Production.