MSDyn365FO: Projects data migration, WBS publication

In this blog post I would like to point out a few challenges that you might bump into while doing Data migration activities of Project related data.

Typically, when you migrate data, the first what you need to decide is which objects you migrate. Once you have a clear understanding of the objects, you can start to consider data entities available within Microsoft Dynamics 365 for Finance and Operations.

Entity list for the project-related data migration would be the first challenge that you may come across. As a part of this process, you should define which of them would work best for you since many of them are similar, but not identical. The following screenshot shows the entity sequence that is set for the Projects data package that has been successfully used upon migration.

The following screenshot shows the entity sequence that is set for the Employee and Project resources data package that has been successfully used upon migration.

I would like to clarify why Employee data entity has been chosen instead of Worker data entity. The issue with using Worker is that Employment details are not being affected by this entity. Unlike Workers, Employee data entity generates employment automatically.

Global address book and People entity are optional here since it can be automatically generated while importing employee records via Employee data entity. Employee entity would generate Global address book record ([DirPartyTable].PartyNumber) and People record ([DirPerson].PartyNumber) automatically for you.

It’s essential that you test all the migration steps before you can safely move your data.

When you migrate project information and WBS (Work breakdown structure) particularly, your WBS data must be in Draft state, otherwise you will get an error while importing the WBS file. Since all WBS records will be in Draft, after import you might look for an ability for mass publication.

Currently there is no way to publish WBS (Work breakdown structure) for all migrated projects automatically. You have to publish all work breakdown structures manually, project by project. I am not an exeption and also faced with this issue and as the result the following class has been built to publish WBS:

class PublishWBSMain
{
/// <summary>
/// Runs the class with the specified arguments.
/// </summary>
/// <param name = “_args”>The specified arguments.</param>
public static void main(Args _args)
{
ProjPlanVersionDetail projPlanVersionDetail;
ProjPlanVersion task;
boolean valid;
int published;
while select projPlanVersionDetail
where projPlanVersionDetail.VersionType == ProjPlanVersionType::Draft
{
valid = true;

while select task where
task.HierarchyId == projPlanVersionDetail.HierarchyId
{
if (!task.validateWrite())
{
valid = false;
}
}

PSAActivityEstimates estimate;
while select estimate where
estimate.ProjPlanHierarchyId == projPlanVersionDetail.HierarchyId
{
if (!estimate.validateWrite())
{
valid = false;
}
}

if (valid)
{
ProjPlanVersionsManager::publishVersion(projPlanVersionDetail.ProjId, projPlanVersionDetail.VersionId);
published++;
}
}

info(strfmt(“%1 versions were published”, published));

}

I hope that your migration will lead to ultimate success of your project!