The long-awaited Phase 2 upgrade from Dynamics 365 Project Service Automation to Dynamics 365 Project Operations is around the corner, with general availability in November 2022. While the Phase 1 upgrade was for scenarios where projects have no dependencies on their work breakdown structure (WBS), the Phase 2 upgrade is specifically for scenarios where a WBS is within the currently supported limits of Project for the web in Project Operations.
The fun doesn’t end at Phase 2, though. The Phase 3 upgrade, to be released further down the line, is for scenarios where a WBS is outside the currently supported limits of Project for the web in Project Operations.
Learn’s documentation has a good article explaining the different upgrade phases, prerequisites, licensing, testing and refactoring customizations, and end-to-end testing in development environments. Be sure to read through it!
This blog post is about my experiences upgrading from PSA to ProjOps as part of the upgrade preview. I want to emphasize the word preview. Some things could change before GA so take this post with a grain of salt.
The upgrade process
The Phase 2 upgrade is initiated the same way as the Phase 1 upgrade. The Microsoft Dynamics 365 Project Operations solution is installed in a selected environment from the Power Platform Admin Center. Make sure you read Learn’s documentation on prerequisites first.
If the upgrade is successful, you’ll see Project Operations installed in the environment. For me, upgrading a small-sized PSA environment without any significant customizations took approximately three hours.
Reasons for a failed upgrade
Before my upgrade was successful, I did run into errors that needed fixing. The error details in PPAC aren’t very descriptive, but there is a way to access the validation checks made during the upgrade process and the reasons for possible errors. Image 2 below displays the PPAC error. The good thing about this is that, at least in my case, the upgrade failed within a few minutes after I started the process. It seems the pre-validation checks are pretty quick.
The Upgrade logs hold the information for both successful and failed upgrades. The logs can be accessed under Settings in the PSA/ProjOps model-driven application. Looking at the logs seen in image 3 below, data validation occurs first, followed by an upgrade of scheduling and the ProjectService solution.
If data validation fails, we need to look at the log more closely. Let’s look at what’s behind the log for the failed upgrade on 28/10/2022 at 08:57. Opening the row, we can see that the table name for the logs is actually Upgrade Run (msdyn_upgraderun). Nice to know. The upgrade log (I’m calling it an upgrade log instead of an upgrade run) itself doesn’t reveal too many details, except the timestamps and the status (success/failure).
Selecting the row with the failure status in the Single-Version upgrades during this run subgrid leads to a row in the Upgrade Version (msdyn_upgradeversion) table. You might want to customize the subgrid to show more than four rows. It’s this table and row that displays the steps performed during data validation. As we can see, there’s one failed step in my upgrade: ProjectServiceValidateSummaryTaskNoResourceAssignment.
Why do some of the summary tasks have resource assignments? No idea, and in this case, I didn’t investigate the root cause further. Why? That’s a good question!
Opening the row with the failure status from the subgrid leads to a row in the Upgrade Step (msdyn_upgradestep) table. This row displays detailed information about the errors that caused the data validation and the upgrade to fail.
In this example, the upgrade succeeded when all resource assignments listed in the upgrade step were deleted. One helpful tip is to use the legacy advanced find to find data related to the errors. The new one may, unfortunately, feel a bit useless in these kinds of scenarios. The following direct URL gives you access to the good old legacy advanced find: https://yourOrgHere.crmX.dynamics.com/main.aspx?pagetype=advancedfind.
Another method is to open the rows that need to be deleted with a direct link such as this one for resource assignments: https://yourOrgHere.crmX.dynamics.com/main.aspx?appid=yourAppIdHere&forceUCI=1&newWindow=true&pagetype=entityrecord&etn=msdyn_resourceassignment&id=rowIdHere.
Converting individual projects from PSA to Project for the web
When the ProjOps upgrade completes, individual project rows need to be converted. The ProjOps solution upgrade doesn’t convert individual projects to use Project for the web. Instead, they remain as PSA projects with an uneditable WBS. The message we get states that This project is externally scheduled. Navigate to the tracking tab to view tasks. The solution upgrade resulted in some of the tabs being named “Tab” incorrectly. This eventually got resolved when the temporary solution mentioned later in this post was deleted. All tasks in this example are visible behind the Tab to the right of the Estimates tab (one of the tabs that got properly named Tracking when the temporary solution was deleted).
Before a project is converted to a Project for the web project, it’s a good idea to write down some basic information about the project in case the conversion throws a project’s dates off. I recommend writing down or taking screen captures of:
- Start Date of each task
- End Date of each task
- Duration of each task
- Effort of each task
- Start Date of project
- End Date of project
As this is net new and at the time of writing this, I’ve only done a single solution upgrade in preview, it’s hard to say what other information is worth documenting. As you try the upgrade and make observations, please leave a comment of your findings.
The actual conversion of a project row from PSA to Project for the web took a few minutes for projects of different sizes. The most complex project I converted had tasks in the low tens, and the simplest one only had a couple of tasks. It’s impossible to say how long the conversion takes when converting a project that is close to the limits and boundaries of Project for the web.
To initiate the conversion of a project, click on Convert on the command bar when on a project row.
ProjOps then presents you with a confirmation dialog.
When the project is being converted, changes to its data aren’t allowed.
Errors when converting projects to Project for the web
Sometimes the Project Scheduling Service throws an error when it can’t successfully accept and persist the conversion of a project. In such cases, an error message points us to look for the root cause in PSS error logs (found under settings just like the upgrade logs).
When looking at a PSS error log, the error in this specific case isn’t enough for me to discern the actual problem as I haven’t seen this error before. In such cases, a support request to Microsoft would be required to diagnose errors further.
Deleting the Project Operations Deprecated Components solution
Learn’s documentation states that the Project Operations Deprecated Components solution is a temporary solution that holds the existing data model and components that are present during the upgrade. When I attempted to delete the solution from Dataverse, the deletion failed due to dependencies.
When I looked at solution layers, the unmanaged layer had active customizations. Because all the dependent components were deprecated components, I removed the unmanaged layer from them. I was then able to delete the solution.
Summary
My first experience with the Phase 2 upgrade was positive. The upgrade logs provided detailed descriptions of errors, which made it easy to take corrective action. The overall time invested in my first upgrade was approximately 10 hours, including testing the conversion of roughly five projects. There were little to no customizations, and the upgrade was done on a relatively small-sized PSA.
It remains to be seen what the conversion experience for project rows will be down the line as I convert more projects and upgrade additional PSAs to ProjOps. The PSS error logs are something I do worry about slightly. Even though I have a fair amount of experience using the Project schedule APIs, I know that PSS errors can be tricky to diagnose without Microsoft support if the error details aren’t descriptive enough.