Migration Assessment Scan: Workflow Associations 2013

Learn how to fix issues with that occur with Workflow Associations 2013 during migration.

Overview

When content is migrated from the SharePoint source environment to the new target environment there are two types of workflows that could be involved, depending on their use in the current farm.

Workflows that were created using the workflow service that was available in SharePoint 2010 and are still in use on the source environment will be migrated to the new farm and will continue to work as expected.

SharePoint source farms run Workflow 2013 using a version of the Workflow Manager that is configured similarly to how an on-premises deployment would be set up. As a result, when a customer is moved from the source environment to the target environment, there is a process to migrate Workflow 2013 over to the Azure instance of the Workflow Manager.

Data Migration

Workflow Data is divided into two parts:

  • Workflow Definition:     The definition describes the overall workflow process, e.g. a three stage approval workflow with custom routing rules for each stage. This data lives in O365 and will be migrated with the rest of the O365 data and will be available in your target environment.

  • Workflow Instances:    Each running instance of a workflow definition maintains the state of the workflow, e.g. this document is in Stage Two of the approval process and is assigned to John Doe. This data lives in the Azure Workflow Manager. Unfortunately, the Azure team does not have the technology to migrate Workflow Manager data from the current source environments to Azure instances. The result of this will be the loss of all running workflow instances. For example, a document that was in Stage Two of a workflow in the source environment will be back to Stage Zero (workflow not started) post migration to the target environment.

Important: Any site that is configured as “No Access” (locked), in SharePoint will be skipped. To see a list of locked site collections see the Locked Sites scan output.

Preparing for Migration

To avoid unnecessary workflow restarts it is best to complete in-flight workflows before the migration event when your content is moved to the target environment. If the feature is in use in the source environment today you can receive a list of running instances of workflows prior to the migration event, so that you can communicate this status to your site owners.

Post Migration

Once the migration is complete, all users will need to restart any workflows that were still in flight.

Scan Result Reports

This scenario contains two report files. One report contains the 2013 workflow definitions that are deployed across the environment, and the other shows the 2013 workflow instances that were actively executing at the time the scan was performed.

2013WorkflowDefinitions_<Date>_<Time>.csv    This scan report contains source workflow definitions and where they are associated in the site. Workflow definitions come across in the migration, so this gives some visibility into the workflow footprint in the farm.

Column

Description

Scope

Either List or Site. This is the level that the workflow will run at. It should help the site owner locate the impacted workflow definitions.

WorkflowNAme

Display name given to the workflow.

WorkflowDescription

Description provided when building the workflow.

ItemURL

Relative URL to the workflow scope. This will either be to a list or a site.

SiteAdmin

Site collection owner.

IsReusable

True/False. Identifies which workflows were published as reusable workflows.

Running2013Workflows_<Date>_<Time>.csv    This scan report contains workflows that were actively running at the time the scan was performed. This is a view of the 2013 workflow instances. During a migration, these instances do not come across. Since there can be multiple instances of a single definition, you will typically see multiple entries in this report. To see the sites, filter on SiteUrl.

Column

Description

WorkflowName

Name that shows up in the SharePoint UI for the workflow.

ItemURL

URL to the specific item the workflow is running on.

  • If the scope is List, this will point to the specific list item the workflow is running on.

  • If the scope is Site, this will point to the specific site.

Scope

Either List or Site. This is the level that the workflow will run at. Should help the site owner locate the impacted workflow definitions.

WorkflowInitiator

User that started the workflow.

SiteAdmin

SiteAdmin Site collection administrator for the impacted lists and sites.

Share Facebook Facebook Twitter Twitter Email Email

Was this information helpful?

Great! Any other feedback?

How can we improve it?

Thank you for your feedback!

×