Moving to ServiceNow Flow Designer: Migration Considerations

Moving workflows to Flow Designer means inventorying each legacy workflow and deciding whether to migrate it, redesign it or retire it. Simple workflows with state transitions, notifications and record updates usually move easily, while complex approvals and script activities need redesign or conversion.

Moving legacy workflows into Flow Designer starts with an inventory and a decision per workflow: migrate, redesign or retire. This page covers what to catalogue, how to judge whether a workflow can move as it stands, how to phase and plan the migration, map data and process, choose a cutover approach, handle records already in flight, and recognise the signals that the migration is not working.

What to Inventory

Before migrating, catalog your workflows: how many exist, what do they do, which are critical, which are deprecated? Query the Workflow table in ServiceNow, review each workflow’s purpose and usage. Look for abandoned workflows (inactive for 1+ year) that can be decommissioned without migration effort.

Categorize workflows: critical (failure would impact business), high-value (used frequently or handle important processes), low-value (rarely used, simple logic). Prioritize migration of critical and high-value workflows; defer low-value to backlog.

Assessment: Can This Workflow Migrate to Flow Designer?

Most workflows can migrate, but some legacy features have no Flow Designer equivalent. Assess each workflow: does it use advanced workflow features (schedule-driven activities, wait for condition, loop) that Flow Designer may not support? Does it use plugins or custom code that would need rewriting?

Simple workflows (state transitions, notifications, record updates) migrate easily. Complex workflows (multi-stage approval with complex routing, conditional branching on custom logic) may require redesign. Script activities need conversion to Flow Script.

Estimated effort per workflow: simple workflows need far less effort than medium or complex ones. Budget accordingly.

Migration Planning and Phasing

Phase 1: Pilot. Select 2-3 low-risk workflows (not critical to business, simple logic). Migrate to Flow Designer, test thoroughly, run in parallel with legacy workflow for 1-2 weeks to validate behavior matches. This builds confidence and identifies issues with safe workflows.

Phase 2: High-Value Workflows. Migrate workflows that are used frequently or handle important processes. Test each thoroughly before cutover. High-value workflows justify the effort; if you save 10 hours per month through improved automation, migration pays for itself in months.

Phase 3: Remaining Workflows. Migrate remaining workflows or decommission if they are no longer needed.

Data and Process Mapping

Document current workflow behavior: what are trigger conditions, what actions does workflow execute, in what order, what are approval conditions, what notifications are sent? This documentation ensures new Flow Designer workflow matches original behavior.

Map current workflow to Flow Designer constructs: workflow state transitions become Flow state charts, wait activities become Flow waits, approval activities become Flow approval actions. Identify constructs that do not map directly; these need redesign or alternate approach.

Cutover Strategy

Approach A: Parallel Run. Run legacy workflow and new Flow Designer workflow simultaneously. If both complete successfully, success. If either fails or produces different results, investigate. Run parallel for long enough to build confidence, then disable legacy workflow. Lower risk but higher overhead.

Approach B: Shadow Mode. New Flow Designer workflow runs but results are not used (new approvals go to queue, notifications are sent to admin, not actual user). Monitor for errors or anomalies. Run for long enough to build confidence, then switch to production. Medium risk, less overhead.

Approach C: Cutover with Rollback Plan. Disable legacy workflow, enable Flow Designer. If issues discovered, re-enable legacy workflow within hours. Have rollback plan documented and tested before cutover. High risk but fast if it works.

Risks and Mitigation

Risk: Behavior mismatch. New Flow Designer workflow differs from legacy workflow in subtle ways. Mitigation: test thoroughly, run parallel or shadow mode, validate results match.

Risk: Approver and notification delays. If new workflow is slower to trigger approvals or send notifications, users may complain. Mitigation: performance test before cutover, optimize Flow triggers and actions.

Risk: Script conversion errors. Legacy scripts are converted to Flow Script but logic errors occur. Mitigation: test converted scripts thoroughly, consider rewriting scripts from scratch for critical workflows rather than converting.

Validation Steps

Before declaring migration complete: test with realistic data (not just test records), verify approvals route correctly and notifications arrive, verify record state changes happen as expected, verify integration actions (API calls, updates to other tables) succeed, test error cases (invalid data, external system unavailable).

Document migration: what was the workflow, what is it now (Flow Designer details), when was it migrated, who tested it, any known limitations or differences from legacy behavior.

Post-Migration Support and Maintenance

After migration, allocate time for support: users may have questions, issues may emerge that testing did not catch. Monitor Flow execution logs for errors. Track if users are trying to access old workflow (indicates they do not know it moved); update documentation and send communication.

Timeline and Effort

Plan the migration from your own inventory of workflows: assessment, pilot, high-value migration, and remaining workflows each take as long as their size and complexity require. Staff the assessment and migration phases according to the amount of work, and keep some support in place afterward.

Deciding which legacy workflows to retire rather than rebuild

A migration is an opportunity to remove work that should have been removed years ago. Before a legacy workflow is rebuilt, ask whether anyone still depends on its outcome. A workflow that sends a weekly report nobody opens, or that routes approvals to a group dissolved two reorganizations ago, should be switched off with a dated record rather than carried across. Rebuilding dead logic in a new tool just gives it a longer life.

The useful split is between workflows that are retired, workflows that are rebuilt as flows, and workflows that stay where they are for now because the business case is weak but the risk of change is high. The third group is often the largest, and it should be reviewed on a fixed date instead of being left in limbo. Record the owner, the reason for the choice, and the date on which the choice will be reconsidered.

Parity matrix: what has to match before cutover

Parity is not the same as identical output. A rebuilt flow can produce a better result and still break a downstream process that depended on the old timing or the old field values. The matrix below is a way to check parity by behavior rather than by screenshot, and the flow testing and acceptance checklist can supply the test cases for each row.

The access row is one teams often forget. A workflow that ran under an administrative context may behave differently once the flow executes with the permissions of its run-as identity, and that difference only appears on records a standard user cannot see.

Handling records that are already in flight

The hardest part of a cutover is often the set of records that started under the legacy workflow and have not finished. Approvals pending on the day of the switch, tasks half complete and scheduled notifications queued in advance all need an explicit rule. Options include letting in-flight records finish under the legacy workflow, restarting them under the new flow with their current state copied across, or cancelling and re-raising them with a note. Pick one per workflow and write it down, then reconcile the counts using the data migration validation and cutover article as the reference. Leaving the choice to whoever happens to notice the stuck record can be how approvals get lost.

A cutover-day procedure

1. Freeze changes to the legacy workflow definition and to the flow for the cutover window.
2. Count the in-flight records by state and confirm the in-flight rule for each state.
3. Disable the legacy trigger and confirm in the execution history that no further legacy runs start.
4. Enable the flow trigger and run one controlled test record through the full path.
5. Check the first live executions against the parity matrix before the approvers are told the switch is complete.
6. Keep the legacy definition in place but inactive until the rollback window has closed.

Keeping the legacy definition inactive, rather than deleting it, is what makes a rollback possible. The rollback itself is usually simpler than teams expect, provided the in-flight rule was written down.

Signals that the migration is not working

Watch for approvers asking where a request went, notifications arriving twice, or a support queue filling with the same question about a changed screen. Many of these trace back to parity work that was incomplete rather than to user resistance. A quieter signal is a flow whose executions look healthy while the downstream report has fallen. Compare business outcomes with the legacy baseline for the first full cycle, not only the execution success rate, and write the pass criteria against the release acceptance criteria article.

Can we run the legacy and new workflows side by side for a while?

Yes, but only if one of them is made silent for each record. Two live workflows that both send notifications can double every message. Decide which version owns the outward communication and suppress the other’s sends during the parallel period.

What happens if a legacy workflow calls a script include?

Map the script’s behavior into the flow, or into a shared script that both versions call, before retiring it. Deleting the script early breaks every other process that still references it, which is often not visible in the workflow being migrated.

Who decides that a legacy workflow can be retired?

The business owner should sign that the outcome is no longer needed, and the platform lead should confirm that no other process reads its output. Both sign-offs belong in the migration record.

How long should support stay in place after a migrated workflow goes live?

Plan for a support window that covers at least one full business cycle for that process, such as a month-end or a quarterly review. Problems that only appear on the cycle’s unusual dates tend to surface late.

Scoping a migration with a specialist

Bring the workflow list with owners and the date each one last changed, so the first session can focus on the decisions rather than the mechanics.