For the thousands of enterprises out there still relying on SharePoint 2010 and 2013 Workflows to manage complex business process, there simply wasn't enough time between Microsoft's announcement last July and the actual retirement/depreciation date in November to properly redesign and rebuild solutions.Many companies using InfoPath as part of the solution have found the project even more daunting.This change in service also affected a lot of unsuspecting customers using basic SharePoint approvals and other out-of-the-box workflow solutions, who did not even realize they were using WF2010. As a result, many companies found themselves dealing with broken workflow solutions scrambling to produce a last-minute strategy to recover.To make matters worse, a lot of these solutions were built many years ago, so the original architect, BA, designer, developer, and process SME's have since moved on and taken their tribal knowledge with them.
As a side note, I should mention that this applies only to SharePoint Online.SharePoint on-premises is a different story (for the near future).But those of you who are running WF2010 on prem, and planning to migrate sites to the cloud, will need to address this issue before migrating.
What's the Quick Fix?
I hate to break the bad news - there is no easy fix.If you are reading this, then you probably realize that WF + InfoPath solutions are essentially custom software solutions.Perhaps some of the first to be considered 'no-code' or 'low-code', but still custom software solutions, nonetheless.Many of which are managing extremely complicated processes with lots of branching, decision trees, automation, business logic, etc. baked in.And, being SharePoint solutions, these processes typically carry some sort of payload, such as documents, list items (data), electronic (XML) forms, and so on.Not to mention unique item-level permissions!As such, there are typically many facets to these solutions, in addition to the technical aspects, that can make these projects very challenging.And, no, unfortunately there is no migration tool that will automatically upgrade WF2010/2013 solutions to Power Platform, nor InfoPath to Power Apps.
For that reason, we wanted to provide some helpful tips to avoid the hidden traps you may encounter, and hopefully save you some hardship along the way.Naturally, as a lifelong IT professional and drinker of the Microsoft cool aid, I believe the 'obvious' approach is to migrate SharePoint Designer workflows to Power Automate/Flow, and InfoPath to Power Apps.Therefore, this post is based on that approach.
1. Scan your environment
It is important to begin by scanning your environment holistically, to understand the width and breadth of the technical debt.The free Microsoft tool to do this is called the SharePoint Modernization Scanner, but it only works with SharePoint Online.If you are planning to migrate your tenant from on-prem to online, the tool for scanning on-premises SharePoint farms is the SharePoint Migration Assessment Tool.
The output from the tool will give you an excellent handle on the amount of workflow and InfoPath you have in your environment, along with some granular details (such as number of actions) that you can use to estimate overall effort.See the Microsoft reference documentation for details on the output for workflow and InfoPath.
2. Understand your data options
There are many options available for the back-end of a Power App but, if you are coming from an existing SharePoint solution, your basic options will be SharePoint Document Libraries and SharePoint Lists, or you could choose to move to the Microsoft Common Data Service (CDS a.k.a. Dataverse).
If you want to maintain the SharePoint look and feel of your existing solution, have a lot of SharePoint documents involved in the process, or if you're not ready for the CDS, then custom lists or document libraries are your best bet.If your existing solution leverages an XML document library, you will want to move towards a list or document library and eliminate the XML library from your solution, as Power Apps eliminates the need for XML-based forms.This can be more complicated than it sounds since XML forms often write some of their fields to XML library columns while managing and maintaining other fields only in the XML form itself.In these scenarios, you will need to identify those XML-only fields and create new list columns for each, for the new Power App to manage those data fields.
WARNING!A lot of InfoPath solutions manage a very large number of data fields.Recently, we came across a project where one of the InfoPath forms had over 300 fields.The form wrote approximately 175 of those 300 fields to the XML library columns.However, over 150 of the fields were stored and managed only within the XML document itself.This data was critical to the workflow process.As you may have guessed, while creating new columns to manage those fields we hit the limit of list columns in SharePoint (actually, it's not a column limit but a max record size) and were forced to create a second list to manage the overflow of columns.
If you are not married to the SharePoint UI for your solution, the CDS is a very powerful cloud-based back-end.Think of it as SQL Server for business apps that allows you to create tables with columns and relationships (formerly called entities, fields, and relationships) without being a database developer.Power Apps built on CDS back-ends are called Model Driven Apps.Be aware there are some licensing considerations attached to the CDS, so make sure you understand how that will impact your project.Going in this direction will reduce, or maybe even eliminate, your dependency on SharePoint since the back-end will no longer be based on a SharePoint list or library.This, of course, will have a big impact on user experience as well.Make sure to plan accordingly.
3. Eliminate the XML library
It is very common to break a software project like this into phases.For WF and InfoPath projects in particular, it might seem logical to attack the InfoPath to Power Apps piece in phase 1, and then the Workflow to Flow workstream in phase 2.However, if you have an InfoPath solution with an XML back-end, your workflow is probably implemented against the XML library as well.If you are planning on eliminating the XML library from your solution, then you will need to rebuild your workflows at the same time.In this scenario, it is possible to refactor all your 2010 workflow for the new list or document library and leave the Flow development until phase 2.This approach might minimize effort on the workflow workstream to allow more focus on the Power Apps workstream in phase 1.However, we have found it best to implement Flow and Power Apps in one unified phase, such that you can cut over in one release.
4.Allow time for Flow approvals POCs
If you are using WF2010 approvals, we find they are replaced nicely by the Flow approval process.However, there are some differences in the details that will require allotting additional time for proof of concepts to get it right.Keep in mind, there is a user impact with the Flow-based approval process.
5. Be aware of Flow history and timeouts
There are two major caveats to be aware of between Workflow and Flow.First, Microsoft Flow is limited to 28 days of history.Second, long running Flows will timeout after 30 days.If you have the need for long term retention on WF history or long running process (greater than 30-day approvals for example) be aware of this, and make sure you plan for development time to refactor your process logic accordingly. There are several tutorials online that describe techniques to trap these timeout events and deal with it gracefully.
6. Realistically Plan for Migration/Cutover from the XML Library
One of the more challenging facets of upgrading a live workflow solution is cutting over to the new solution.Aside from dealing with in-process (running) workflow instances, if your solution is eliminating an XML library, be aware there are some additional complications.Be sure to plan for migrating your XML library data to your new list or document library.This may seem straightforward but can prove to be quite challenging.Not only will you will need to move existing XML library column data into the new list (this is the straightforward part), but if your InfoPath forms contain data elements that are not written to XML library columns (like the scenario painted above), you will need to write scripts to extract and move that data as well.
They key here is not to underestimate the amount of work required.Testing is crucial, extremely time consuming, and will impact the business users who are required for comprehensive UAT.Plan accordingly.Since much of this is a manual effort, we found that leveraging our hybrid team of onshore and offshore resources for planning and execution can offer a high-velocity solution with minimal downtime.
7. Explore the opportunity to innovate
While the intent of this blog was to focus on a straight port, keep in mind that these projects are a great opportunity to strategize with business leaders.With Office 365, Power Platform, and Azure it is amazing what you can accomplish with minimal effort and a little creativity.If you are in the process of eliminating legacy WF2010 and/or InfoPath from your technical debt, this may be the perfect time to innovate and provide true digital transformation for your business.