Workflow Automation CoE > Workflow Migration
Goal
This article will guide customers and partners in their migration efforts by identifying, analyzing, and migrating their Legacy Workflow codebase.
Introduction
In the rapidly evolving landscape of Workflow Automation, migrating from legacy workflow editor to the modern workflow toolkit is essential for organizations aiming to enhance efficiency and maintain competitiveness. This article serves as a comprehensive guide for customers and partners embarking on this migration journey, detailing the steps needed to analyze and migrate their legacy workflow codebase. Readers will learn about the critical reasons for migration, the phases of the process—from enablement to execution—key strategies for planning and analysis, and best practices for transitioning to the new Workflow Automation toolkit. By the end of this article, you will be equipped with the knowledge and resources needed to successfully uplift your workflows and leverage the full potential of the modern automation tools.
Why migrate?
The modern Workflow Automation toolkit in ServiceNow enables the creation of playbooks, flows, subflows, flow actions, and decision tables, facilitating easier development through Workflow Studio or ServiceNow Studio. Although the legacy workflow engine remains operational, migrating to the modern toolkit is encouraged due to enhanced development, performance, reusability, and security. The legacy Workflow Editor has not been updated since 2018 and is in maintenance mode. Benefits of the modern toolkit include improved usability and debugging, low-code accessibility, and integration with new tools and Generative AI innovations. The performance of the flow engine has been optimized for asynchronous processing, reducing user session holds. ServiceNow plans to phase out legacy workflows, ensuring that newly provisioned instances will not ship with them by the end of 2025, while allowing existing workflows to continue running.
Learn more in this Migration FAQ article in the Workflow Automation Center of Excellence:
https://sn.works/CoE/Migration
How to migrate?
Phase 0: Enablement and Evangelism
The initial step before heading into a project like this is to have your developers complete the available training for the modern workflow products on Now Learning and make sure they are familiar with the available resources on specific use cases and design patterns, like the Workflow Automation Center of Excellence and the Workflow Academy.
Nominate one or two (or more) flow and playbook evangelists in your org that are interested in learning new technologies and researching and defining best practices for your development team(s). Customers, partners, and our own engineering teams have seen huge success in providing recurring office hours where people can present use cases, ask questions, and receive guidance with their current development tasks.
Enablement and peer support, as well as executive backing is crucial for this to work. If your developers are expected to become competent working with a (possibly completely) new technology stack, they need sufficient time to complete the available training, get familiar with the differences in design patterns, and adopt new good practices and approaches to workflow development.
Phase 1: Planning
In this phase you will define the scope and time frame of your migration efforts. There are different approaches that should be considered and evaluated on what works best for your organization, resources, and project goals.
Regardless of your approach, you should set up governance rules for workflow development:
- All new requirements will be developed with the modern toolkit.
- All change requests to existing workflows are an opportunity to migrate this workflow or at least parts of it. Flows, subflows, and flow actions can be run from a workflow script step with via a code snippet using the FlowAPI. Similarly, workflows can be run from a flow with the Call a Workflow flow logic.
Approach 1: Iterative Migration
With this approach migration will take place over time. In addition to migrating whenever a change request for a given workflow is being worked on, your developers can also set aside specific time (for example “Migration Mondays” every Monday afternoon) or set up migration goals for a given time period (for example “migrate 3 workflows per month”), etc.
Approach 2: Big Rock Migration Project
In this approach, the timeline for the migration is more condensed. Depending on the scope of your legacy workflow codebase, you might dedicate several development cycles or internal releases and most of your development resource capacity to this project.
Phase 2: Definition
Identify legacy objects
For either approach, but even more for the Migration Project approach, it is important to clearly define the scope of the migration. In this phase, you will perform a full inventory of the code base that needs to be analyzed. This can be done either manually, by reporting on the wf_workflow_version table for active legacy workflows, or with the help of an Instance Scan Definition to create findings for each legacy workflow found with a specific set of conditions.
In a future migration and harmonization effort you might also want to consider looking at: Scheduled Jobs, Inbound Email Actions, useful Script Includes, After or Async Business Rules and consider migrating some of them to flows, subflows, or flow actions.
Inbound Email Actions can be replaced with Inbound Email Flows, Scheduled Jobs with Scheduled Flows, and Business Rules usually equate to record-triggered flows. Script Include functions can be made available for flows and subflows by calling the Script Include function from an action script step and grouping them in a Utils Spoke per Script Include.
Stakeholders
In this phase, you will also identify stakeholders for this migration effort, and their roles in the different phases of this project. Possible stakeholders can be:
- Platform Owner
- Platform Architect(s)
- Business Process Owner(s)
- Platform Developer(s)
- Platform Administrator(s)
Define a tracking process
Determine how to best track progress on the migration projects. This can be achieved with ServiceNow Products like SPM Project Management, a custom tracking table built with App Engine or any other system you are currently using for project management.
Phase 3: Analysis
Migration Strategy and Priority
Once you have identified all legacy workflows on your instance, we recommend analyzing them for their impact and effort needed.
Impact can be measured by the number of executions. How much effort is needed to migrate an object depends on whether an OOB solution exists, and if not, how complex it is. How many activities or lines of code does it contain, is there any complex branching or looping?
- Any objects that are of low complexity but execute frequently should be the priority for migration.
- Benefit: These are a great path for quick successes and getting your development teams familiar with the new technology
- New object types used: most likely
- Next, we rank any high-execution workflows that are based off an OOB workflow for which a migrated version is provided by ServiceNow. Here, you need to analyze which changes have been done for the OOB legacy workflow, how this is implemented in the new flow or playbook for this ServiceNow Product and which changes are needed to adapt baseline.
- Benefit: Understanding baseline flows and playbooks and modifying them to suit your organization’s needs is a great way to deepen your developers’ knowledge of flows and playbooks
- New object types used: baseline flows and subflows, playbooks
- High-execution, complex workflows have a medium priority and will require the most planning and reviewing. Here it is important to invest time up front to do a thorough investigation of what the process looks like in reality today and whether the requirements still hold up.
- Benefit: This is a great chance to look for optimization opportunities, streamlining and simplifying this workflow with decision tables, automating manual steps, and possibly creating your first playbook
- New object types: most likely playbooks, possibly flows and subflows, flow actions, decision tables
- Low-execution workflows are of the lowest priority. These should be evaluated with a critical eye on their usage over the past months or years and possibly deprecated without replacement if the execution numbers are very low and their value for the business is negligible. Those that are still needed can be migrated gradually until there are no more legacy workflows left.
- Benefit: Possible reduction of the codebase
- New object type: any
Group by Stakeholders
If you have a large codebase of legacy workflows, consider creating child projects for each major stakeholder group. This could be by ServiceNow product line (ITx, CSM, HRSD…) or along your own organizational groupings. Migration strategies and priorities might be slightly different for each stakeholder group, but it will still be important to keep communication channels open between the teams to exchange new knowledge, establish your own migration guidance, and build mutually beneficial relationships.
Phase 4: Execution
This is where your development teams will adopt baseline or create new flows, playbooks, or other workflow objects to replace the legacy technology. This phase should follow your usual development lifecycle with two additions: deactivating the old artifacts and informing the stakeholders about the replacements or deprecations.
Stage 1: Discovery
The first step is a thorough analysis of the old legacy workflow, the original and current requirements as well as defining any deliverables that need to be part of the migration outcome. If baseline is being adopted, this is also the time to install and test the new flows and playbooks provided by the ServiceNow Product teams to understand the current industry standards for these processes. Mapping out the desired outcomes beforehand is important to develop flows and playbooks that suit your organization’s needs and will be adopted quickly.
Stage 2: Development
Guidelines for adopting baseline flows and playbooks
When it comes to adopting baseline flows and playbooks, you will either duplicate or modify them. Which you choose depends on the flow or playbook you are looking at and how much customization you expect to do.
If it is a playbook that we ship with our Demo Store app, those are just meant as examples and not production-ready playbooks. Create a copy to modify if they look useful to you or just use the activities provided in the demo scope for your own playbooks.
For playbooks that are shipped with one of our main products, like CSM, if you modify them instead of copying, you will receive updates to these objects when the product teams release updates and improvements via skipped records when you update the relevant store apps or instance release version. This is recommended if you can adopt as is for the most part and do not plan big changes.
If you are planning to make major changes to suit your needs, I would consider creating a copy before modifying it, or creating your own playbook with the playbook activities included with the OOB store apps. If you are only planning minor changes and you want to receive updates to the playbooks when they are shipped, you might benefit from modifying the OOB playbook definitions.
Some baseline flows are also set to read-only, these always require to be copied before adopting them.
Guidelines for developing flows, playbooks, and decisions
Design approach
Flows (and playbooks) and the available flow logic work a bit differently than you are used to from legacy workflows. When you start migrating, look at the existing workflows with a critical eye, and use this project as an opportunity to evaluate whether the logic, stages, and steps that were defined a while ago (potentially years at this point) are still a good representation of how the process is actually being worked.
Give yourself time to learn the new design patterns, guidance, and best practices for building flows, when to create a subflow or custom action, how to name input and output variables, how to handle errors, how amazing decision tables are, and other neat tricks. Once you start getting familiar with how workflows are built on the modern tool stack, your time to value will speed up noticeably, you will need to use scripting much less frequently, leading to fewer spelling mistakes and missing semicolons!
Flows vs. Playbooks
Flows or subflows should be used for self-contained automations that require little to no user interactions, as well as for specific use cases that are supported in dedicated flow triggers, like Service Catalog fulfillment, SLAs, Inbound email processing, etc. Subflows can be launched from other flows and subflows, from playbooks, or with the FlowAPI and have specified inputs and outputs. Triggered flows can run on record creation or update, on a schedule, triggered via an integration (like an inbound REST API call or Apache Kafka events).
Playbooks should be created for complex, multi-stage, cross-departmental processes with frequent user interaction. Each playbook activity executes a (sub)flow or flow action but can enhance it with a UI layer to guide the process worker through the required steps. Playbooks can be embedded in and worked on in any configurable workspace, Next Experience page, the Service Portal, or even the ServiceNow mobile app.
Learn how to get started with Playbooks:
https://sn.works/CoE/StartPlaybooks
https://sn.works/workflowacademy/2411
Reduce complexity with Decision Tables
Decision tables are great to eliminate complex if-then-else branching in your workflows, they can be reused across flows and playbooks and even called from any script via the DecisionTableAPI to replace case-switch statements.
Learn how to get started with Decision tables:
https://sn.works/CoE/StartDecision
https://sn.works/workflowacademy/2406
Build with reusability in mind
For frequently used automation patterns, consider creating subflows that can be called from multiple flows or playbooks. Common examples are approvals that are needed for a range of catalog items or choosing the right communication channel for different business units or geographies in your organization. Some might prefer to be contacted via email, others via teams or mobile push notifications. Decision tables can be combined with dynamic subflows to achieve very flexible outcomes for these use cases.
https://sn.works/CoE/FD/DynamicFlowDecision
Flow actions can be created for repeatable, atomic automation that cannot be achieved with any of the baseline actions or those included in Integration Hub spokes. We recommend to group flow actions in an application scope to categorize them, this can either be something of a Utils Spoke, like a Utils Script Includes collection of functions, or - in the case of integration actions - they make up a custom integration spoke.
Build custom spokes: https://sn.works/CoE/IH/buildspokes
Migrate scripted integrations: https://sn.works/CoE/IH/migration
Documentation
As with any development project, make sure to document the newly built workflow objects, their requirements and definition of done, and add information about the legacy workflow that is being replaced. Document any information about the old artifact, the new artifact, and potential reasoning for changes to the process that were decided on during the discovery stage.
It is a good idea to create a KB article with an overview table of all the legacy objects and their migrated counterparts that links to the Epics, Enhancements, Change Requests, or KBs which contain documentation for the individual pieces.
For our own migration project, the product teams at ServiceNow have created a custom tracking table to store the old artifact, the new artifact, its migration status plus extra information. If you are looking to minimize the use of custom tables, add the replacing artifacts’ name and sys_id to the legacy workflow to the Workflow Properties > Description.
Stage 3: Testing and Approval
Once you have created the new flows or playbooks to replace legacy workflows, they should undergo your usual testing processes like UATs or automated testing with ATF. If you have been following good practice recommendations for your automated test and built them to test for outcome, existing ATF suites should be applicable to your new developments as well. Learn more about ATF testing here: https://sn.works/CoE/StartATF.
After acceptance testing has completed successfully and the stakeholders have granted their approval, we can move on to deployment and depreciation.
Stage 4: Deploy and Deprecate
In this stage, the new playbooks, flows, subflows, actions, or decision tables can be promoted to production with your usual methods. Legacy workflows can be deactivated, and their description updated to point to the new artifacts that will take over the automation work from here on out (see also Stage 2 > Guidelines > Documentation).
Stage 5: Completion and Communication
Lastly, update your tracking tasks to reflect the successful migration of a legacy workflow. This will allow for project progress reporting and post-project analytics.
Make sure to bring awareness about the documentation created during this project to all affected stakeholders and process workers after the changes have been being deployed to production and the old artifacts have been deactivated.
Phase 5: Project Conclusion
Congratulations! Once all migration tasks have been completed, all legacy workflows have been deprecated or replaced with automation built in the modern workflow toolkit. Be sure to send out communication to all agents and end users if their experience of working the process has changed.
Conclusion
In summary, the migration from legacy workflows to the modern Workflow Automation toolkit is crucial for organizations seeking to streamline processes and enhance operational efficiency. Throughout this article, we have highlighted the importance of understanding the migration phases—from enablement and planning to execution and project completion.
Key takeaways include the need to prioritize workflows based on execution frequency and complexity, involve stakeholders in the process, and leverage best practices for development and documentation. By embracing the new toolkit, organizations will not only improve performance and security but also position themselves for future growth and innovation in an increasingly automated environment. The transition ultimately empowers teams to harness the full capabilities of advanced workflows and drive greater outcomes for the business.
Survey
We want to hear your thoughts! Please take a few minutes to fill out the survey on this article and Legacy Workflow migration.
https://sn.works/workflow/survey/migc
Resources
- Workflow Automation Center of Excellence: https://sn.works/CoE
- Migration CoE article: https://sn.works/CoE/Migration
- Workflow Automation on Now Learning: https://sn.works/CoE/Training
- Workflow Academy: https://sn.works/workflowacademy
- Workflow Academy Playlist: https://sn.works/workflowacademy/playlist
- Platform Academy sessions on Workflow Automation: https://sn.works/platformacademy/workflow
- Build custom spokes: https://sn.works/CoE/IH/buildspokes
- Migrate scripted integrations: https://sn.works/CoE/IH/migration
- Getting Started with Automated Test Framework: https://sn.works/CoE/StartATF
- Impact Technical Accelerator: Jumpstart Your Legacy Workflow Migration
