K2 blackpearl Migration vs. Upgrade
What you should know before you begin.
The conversations online, along with Nintex’s increased messaging about the end-of-life of K2 blackpearl, have raised many questions. So, let’s address a few of them and bring some clarity to what is becoming a hot topic.
For some background, I have two clients who are actively involved in both the migration and upgrade processes. I say “both” because while closely related, these are two different undertakings, and it is essential to understand that distinction.
What is a K2 blackpearl migration?
When discussing K2 blackpearl migration, we are referring exclusively to workflows built and deployed with the desktop-based tooling, which reached the end of this year. Workflows built in the legacy tooling cannot be maintained by the newer K2 Designer, nor can they be imported.
Migration of a K2 blackpearl workflow is a migration in concept only. In practice, it is a full rebuild of the workflow. Any SmartObjects or SmartForms created as part of a K2 blackpearl solution do not need to be updated other than updating any rules to use the new replacement K2 workflow.
Additionally, any custom .NET applications that use the K2 client libraries will continue to work as before, since none of the APIs have changed, including SourceCode.Workflow.Client or SourceCode.Workflow.Management and are still fully supported for the new designer workflows, just as they were for the K2 blackpearl based ones.
Why rebuild?
If you are wondering why import isn’t an option, you aren’t alone. The primary difference between the two versions is the change in design tools, moving from a desktop-based experience to a web browser, and the limitations imposed by that shift.
The blackpearl lineage of tools was all XML-file-based, whereas the new tooling is RESTful & database driven using JSON for workflow design artifacts.
Along with changing the tech stack, an opportunity was seized upon to apply the lessons learned from the first two generations of design tools to craft a more modern, intuitive design experience.
Design is the keyword. The changes to K2 workflows are a design-time consideration only. The K2 workflow runtime did not change. To reiterate, any tooling or custom applications created to manage or interact with K2 at runtime are still valid, with a couple of notable exceptions.
What changed?
With the technology shift and the refinement of the design experience, there are four changes that also fuel the need to refactor your workflows and update any associated custom applications.
XML process data fields have been removed.
Activity data fields are no longer.
Custom code isn’t supported in design tools.
Activities and Events were replaced with Steps.
For my customers, the removal of XML data field support in the Nintex Automation K2 designer was the most influential in driving the push to refactor. XML data fields were introduced in the early days of K2, well before SmartObjects were introduced.
At the time, XML was the only way to store or model complex data relationships in the workflow driven by the integrations with InfoPath, one of the primary UI options for a K2 solution.
Later, understanding evolved into a pattern of externalizing data through SmartObjects, making it more accessible and maintainable. The introduction of SmartForms and the slow deprecation of InfoPath further lessened the practicality of XML as a data storage medium.
Activity data fields have also been deprecated in favor of greater use of process-level variables. It is my understanding that this was done primarily to simplify the design experience. It helps to remember that at one point, the messaging from Gartner and Forrester was the rise of the citizen developer, which necessitated a refinement of design concepts.
The removal of the Activity and XML data fields will affect custom applications, which will need to be updated accordingly. Variables are rebranded Process data fields, and no changes are required.
The ability to write custom code in the K2 design tooling was also deprecated as a part of the technology shift. The Visual Studio design experience allowed adding custom code or reference libraries that aren’t compatible with the new approach.
The focus on custom code shifted to ServiceBrokers via SmartObjects and expanded to include JavaScript. C# was the only option prior to the change.
The important takeaway is that while the technical implementation details were removed, the instigating use cases can still be addressed via other means that preserve the original intent.
Finally, the structure of how workflows are assembled changed. Activities and events gave way to Steps. This was purely a design consideration, thus making the two paradigms between old and new incompatible. Another citizen developer: quality-of-life improvement. It was a bit of an adjustment at first, but I must admit it makes more sense. For me, it was just more a matter of adjusting to the change than a functional limitation.
Why migrate?
The end-of-life deadlines are not technical limitations. Workflows are not going to stop working on at midnight on December 31 if they have not been migrated.
The motivation to migrate is access to support and security. Of my two clients, one migrated a major solution from K2 blackpearl by the October deadline due to the highly regulated nature of their industry. Being on unsupported software was a risk they were not willing to take or a conversation they wanted to have with regulators. We went live in the first half of October.
The remaining client their migration effort is ongoing. Their industry affords them a bit more flexibility in their planning. They have been using this process as a training effort for new K2 developers to skill them up on legacy solutions and K2, and I have been engaged to advise them on how to rearchitect the solutions to fit the features of the newer K2 version.
Clients who are finding themselves in this situation have obviously been K2 users for a very long time. Solutions that could be as old as 17 years old. These are obviously important processes to have been maintained and still used for that long, so migration is necessary.
There will be a level of effort associated with migration. Keep in mind that, in many instances, it is a carbon-copy rebuild. The hard work was already completed when the solution was originally built. At least, the effort will be opening the legacy workflow, starting a new workflow, and mapping the old to the new.
The effort would increase if the workflow relied heavily on custom code or XML data fields, as in my regulated client’s workflow. It required rearchitecting not only the workflow but also impacted systems and applications. If you find yourself in a similar situation, I advise you to take a moment to evaluate the solution. Understand how the workflow change will impact the solution as a whole, and take some time with the business owners to review the workflow. My client and I found out after the fact that a few steps in the workflow we were migrating could have been left out because the business needs had changed.
In the race to migrate with time as a factor, take a moment to evaluate the process. I am not suggesting a full process discovery exercise, but at least a critical look, as you may save yourself some time and effort if there is functionality that doesn’t need to be brought forward.
When to upgrade?
My clients who are migrating were already running a newer version of K2 before they began the migration. Upgrading can happen at any time, independent of migration.
The need to upgrade is driven by the end-of-life of k2 blackpearl 4.7.
Migration is a topic that was driven by the end of life of Visual Studio 2015.
The matter is slightly complicated, as the final date for both is December 31, 2025, because both the design-time and runtime components that support them are reaching the end of life.
The upgrade will only be a prerequisite for migration if your organization is not running a version of K2 5.x with the new K2 Designer. K2 blackpearl 4.7 customers must upgrade before they can begin the migration process.
Final thoughts
My recommendation is that if you are a K2 blackpearl 4.7 customer, upgrade to K2 5.7. The move is a required step on the journey to 5.9 from 4.7, so effort won’t be wasted. This will keep you on a supported version under extended support till September 2027 and enable your organization to begin migration.
With migration and upgrades uncoupled, a plan can be developed for when to upgrade to K2 5.9
Questions about your migration plans? Drop us a line at hello@caseitsolutions.com