As a Microsoft D365 Consultant, I’ve encountered a more and more frequent challenge: migrating from Project Service Automation (PSA) to Microsofts new Creation – Project Operations (PO). This transition is crucial for businesses seeking enhanced project management capabilities or looking forward to migrate before PSA runs out of support. Today, I’ll share insights on the migration process, its benefit as well as an issue I faced within the migration.
Why and how to migrate to Project Operations?
PO offers significant advantages over PSA. It integrates seamlessly with Dynamics 365, providing a unified platform for project management. Users gain real-time visibility into project performance and financials. Collaboration is streamlined, and resource utilization is optimized. While the migration is more or less an App Update in the Power Platform Admin Center with some extra steps, you should keep some steps in mind.
- Prepare Your Environment: Clean up your PSA environment. Remove unnecessary components which are obsolete in Project Operations or not longer needed.
- Test in Sandbox: Deploy your solution to a sandbox. Test all functionalities thoroughly.
- Validate the data of the environments: There are multiple restrictions on data that can be migrated. You can read those below.
- Address Issues: Resolve any errors encountered. This might involve removing components that can’t be migrated.
- Finalize Migration: Once testing is successful, proceed with the production environment migration.
When embarking on a migration journey, it’s crucial to adopt a systematic approach. Starting with sandbox testing allows organizations to evaluate the new platform’s features and functionalities without impacting live operations. This iterative testing process ensures a smooth transition and minimizes the risk of disruptions.
Once the sandbox testing phase is complete and any issues are addressed, the next step is testing in a dedicated test environment. This environment mirrors the production setup, enabling thorough validation of configurations, data migration, and customizations.
Finally, the migration process culminates in transitioning to the production environment. By following this phased approach, organizations can mitigate risks, ensure data integrity, and optimize user adoption.
Validate the data of your production environment
As part of the data review of the Project Operations migration, I’ve provided you with the following action items. Verify the migration readiness of all projects and tasks in the production system:
- No task should have more than 20 resource assignments.
- No project should have more than 500+ tasks.
- Header tasks, i.e., parent tasks, should not have roles assigned.
- Header tasks, i.e., parent tasks, should not have resource assignments.
- Tasks should not exceed a duration of 1250 days.
A wild: Custom control declaration for form factor missing for control – error appears
The error I encountered involved a specific error code indicating that a certain component couldn’t be migrated.
![](https://strohmayer.dev/wp-content/uploads/2024/04/image-1-1024x364.png)
ProjectOperations_Anchor
Custom control declaration for form factor(s) 0,1,2 is missing for control with uniqueid {…}. More Details:Parent Type:SystemForm;SubType:main;Parent Id::… ;Associated entity:msdyn_project;Control Description Xml:Unexpected schema; Control Reference XML: Unexpected schema; Error Message: -2146041847; Additional Information; Fehlercode -2146041847
Upon investigation, I found only an ID provided, which I then traced back through exporting the default solution of my environment, unzipped the customizations XML from the solution and checked for the id.
![](https://strohmayer.dev/wp-content/uploads/2024/04/image-2.png)
This component pertained to a standard resource within the Schedule & Tracking-Grid of the project entity, used for project capacity planning. However, this resource was no longer necessary in Project Operations. It appeared that Microsoft hadn’t automatically removed this resource with the app update. Therefore, I manually removed it from my old environment, enabling the successful completion of the solution upgrade.
![](https://strohmayer.dev/wp-content/uploads/2024/04/image-3.png)
Conclusion
The migration from PSA to PO is a transformative process. Through my own experiences as a consultant, I’ve learned that meticulous planning and problem-solving are essential for a smooth transition. Despite encountering challenges like the custom control error, perseverance and proactive action enabled me to overcome obstacles and successfully upgrade the solution.
If you have other issues like a malfunctioning invoice correction, make sure to read into this post as well!