A new white paper released by Discover Technologies addresses the downstream effect a SharePoint environment upgrade can have on workflows.
Essentially, the upshot is really the difference between K2 blackpearl and other, SharePoint-based workflow solutions like Nintex Workflow: K2 blackpearl has its own workflow engine, and does not require SharePoint to operate. Other, SharePoint-dependent offerings (including Nintex) were faced with a major dilemma when Microsoft introduced Workflow Manager 1.0 (WM), because WM moves the workflow engine OUT of SharePoint, and there is no upgrade path to WM-based workflows. Microsoft did leave the legacy 2010 workflow engine in SharePoint 2013, allowing dependent workflows to run with upgraded content — albeit sans 2013 features. The only way Nintex and other workflow users will be able to take advantage of WM and its feature set (which is incomplete, by the way) is to rewrite their workflows. And if Microsoft doesn’t leave the 2010 engine in SharePoint 2016, those processes will have to be refactored sooner rather than later.
Executive Summary
Since many workflows are started by, or perform changes in SharePoint® content – perhaps a new list item fires a workflow process, or a process modifies a library – upgrading to SharePoint 2013 can break your workflow processes.
The introduction of Microsoft’s new Workflow Manager, and the separation of the workflow engine from SharePoint 2013, have downstream impacts on users of business process management software (BPMS), like Nintex Workflow and K2 blackpearl®.
For users of SharePoint 2010 looking to upgrade their Nintex Workflow solutions to use the new platform and its features, staying current with SharePoint can mean refactoring workflow processes or even shifting Nintex solutions altogether. Although it is possible for SharePoint 2010-based Nintex solutions to run “as-is” in SharePoint 2013, this capability may not extend beyond the 2013 edition.
Nintex customers will have more decisions to make.
Since rebuilding 2010-based workflows is effectively a given (it’s just a question of when), perhaps building them in a mature BPMS independent of SharePoint, and its new and presently incomplete workflow engine, is worthy of consideration.