SharePoint 2010 Workflows retirement – What should be your next steps

There have been many things to deal with this year, and Microsoft added more chaos to our already tumultuous days. They announced in July that they would be unceremoniously stopping support for SharePoint 2010 workflows in SharePoint Online. This announcement was met with various reactions, ranging from “What??” to “Are people still using SharePoint 2010 workflows? That stuff’s ten years old!”

Wherever you fall on the spectrum, these workflows are really getting retired, and if there’s SharePoint Online in your present or future, you’ll need to know how this impacts you. In this blog post, I’ll cover what the retirement means, how you can see if your environment is affected, and what to do if it is.

A Brief History of the SharePoint 2010 Workflows

How did we get here? SharePoint’s relationship with workflows has been complicated. SharePoint 2007 introduced us to the concept of Workflows. It came with some simple out-of-the-box workflows, like Document Approval. Workflows could also be created with SharePoint Designer, the recently renamed FrontPage. The adventurous folks could also create workflows with code. All those workflows were being executed in the background by a workflow engine that came with SharePoint.

SharePoint 2010 Workflows

SharePoint 2010 continued this approach to workflows. The workflow engine was written by the SharePoint team and was hosted on the SharePoint servers as part of SharePoint. This worked well, but it was somewhat limited by what it could interact with. Microsoft also recognized that workflows would be a big part of their burgeoning cloud platform, and they had a team working on making it as secure, resilient, and full-featured as possible.

SharePoint 2013 Workflows

When SharePoint 2013 hit the streets, it continued to run the SharePoint 2010 workflows with SharePoint’s built-in workflow engine, but it had a trick up its sleeve. It could also connect to another Microsoft product, Workflow Manager, and run workflows with it. These workflows had more features, and since the workflow engine ran separately, you had more control over scaling and process isolation. When a user created a new workflow in SharePoint Designer, they choose which platform to build it on, and the workflow could then use whatever functionality the chosen platform provides.

SharePoint 2016 & 2019 Workflows

SharePoint kept this dueling workflow platforms approach for the next two versions of on-prem SharePoint, 2016 and 2019. Much like SharePoint 2016 and 2019, to facilitate easy migration from earlier versions, SharePoint Online supports workflows built on both SharePoint 2010 and SharePoint 2013 platforms. This made it easy for companies to move their content to the cloud without losing the workflows that make that content work.

What’s the Problem?

In July, Microsoft announced that SharePoint Online would stop running workflows built on the SharePoint 2010 platform. Before we explain what that means, let’s quickly cover what will continue to work. The following thing will keep working after November 1st, 2020:

• All workflows on all versions of on-premises servers
• Workflows built on the SharePoint 2013 Workflow platform in SharePoint Online
• The SharePoint Designer 2010 and 2013 application itself
• All Flows created with Power Automate in Microsoft 365

If that is all you have, you’re in good shape. You can skip the rest of this blog post and go watch some funny hamster videos on the Internet. If you have any of the following, you’d better stick around, because they won’t work after November 1st:

• Workflows built on the SharePoint 2010 Workflow platform in SharePoint Online.

Source: https://threewill.com/updating-task-approval-form-box-sharepoint-approval-workflow/

If any of the workflows doing the hard work in your environment are either of those two types, you’re in a spot of trouble after Halloween.

How Do we Find Them?

But what if you’re not sure? How can you find out whether you are relying on any workflows that are impacted by this retirement? I’m glad you asked. You have a couple of options, depending on where you want to check.

If you want to scan your on-premises farm for SharePoint 2010 Workflows, you don’t have to look any farther than Syskit’s SPDockit. It does an exhaustive inventory of your farm, and workflows are only one of the many things it documents on your farm. It will report the workflows, and you’ll be able to find the ones built on the SharePoint 2010 engine. Give it a try with a 30-day free trial!

Microsoft’s free SharePoint Migration Assessment Tool will also find these for you. It’s a bit rough around the edges, but it works. You might be wondering why you would want to know where the SharePoint 2010 workflows are in your on-prem environment if they will continue to work. While they will continue to work on-prem, they won’t work when you eventually migrate to SharePoint Online. You don’t need to know today whether you have any or not, but when you plan your cloud migration, it’s something new you’ll need to add to your checklist.

If you’re already in SharePoint Online, you’ll need to use a different tool to ferret out those pesky SharePoint 2010 Workflows. Many can help you out, but I make the most use of the free SharePoint Modernization scanner. This isn’t a Microsoft tool, per se, but it’s part of the Patterns and Practices project that Microsoft supports and guides. The Modernization scanner is built to find all of the objects in your SharePoint Online deployment that can be modernized and SharePoint 2010 Workflows fall under that.

When you run the scanner, it’s going to try to give you a list of all kinds of things in your SharePoint Online environment that can be modernized. You should check those all out at some point and modernize them, but for now, we only care about the Classic Workflows. Specifically, we want “Classic Workflow usage (detailed)” in the scanner mode dropdown.

When you run the scanner, it’ll create a couple of Excel spreadsheets with details about the Classic Workflows it finds. ModernizationWorkflowScanResults.csv is a standard CSV file with a row for each Classic Workflow it finds. One of those columns, Column E, reports whether the workflow is SharePoint 2010 or SharePoint 2013 workflow.

You can use Excel’s Filter functionality just to show the 2010 workflows if you have a lot in your environment. Column A is the URL to the site with the workflow and Column J is the list name. If you need something a little more Boss Friendly, open up the “Office 365 Classic workflow inventory.xlsx” file and refresh it. It displays the same data in a Pivot Table, so it’s easier to slice and dice.

You can read this blog post for more information on how to scan your environment for workflows.

What Do We Do Once We Find Them?

Once you’ve discovered the 2010 Workflows in your environment, the work has just begun. If you have many workflows, you’ll need to triage them and decide which ones to rewrite and which ones you can ignore.

Columns T will tell you when the workflow was last edited, which will give you some idea of how current it is. Each site also has a hidden Workflow History list at /lists/Workflow%20history/AllItems.aspx, which, as the name suggests, lists the history of when workflows have run. You use that to see how often the Workflow is fired. If a Workflow isn’t being used, it might be a good time to bid it a fitting farewell and not rewrite it.

If you want to dig deeper into the Workflow History List, read through this post.

How Do We Fix Them?

I keep mentioning “rewriting” workflows, not “upgrading” them or “migrating” them. That’s because there is no way to upgrade or migrate SharePoint 2010 Workflows. They can’t even be converted to SharePoint 2013 Workflows. The only option is to start from scratch and rewrite them as Power Automate Flows.

Columns Y through AC of the ModernizationWorkflowScanResults.csv worksheet give you an idea how many actions the workflow has, how easy it will be to rewrite as a Flow, and which actions are incompatible.

There are some common problems you’ll encounter as you make the switch to Power Automate. Here’s a shortlist of things to look out for:

• Flows have a 30-day lifespan 
• HTTP Connections in Flow require a Premium license
• Flows can’t impersonate another user 
• Flows don’t automatically log their usage in a Workflow History table

Microsoft has some good documentation to help you get over these hurdles and start recreating those workflows as Flows.

The retirement of SharePoint 2010 Workflows seems abrupt and painful. But if you use the tools we’ve outlined above, you’ll do a lot to minimize the pain to you and your tenant users. You’ll be able to find all of the workflows currently in use so that your users don’t see any interruptions. You’ll be able to determine which ones need to be rewritten and which ones can be ignored. And you’ll have a good start figuring out how to rewrite your workflow’s functionality as a Power Automate Flow.