Workflow Preservation Checklist & Conversion Reference

Your data migrated fine. Your workflows didn't. That sentence describes most post-migration crises.

Workflow preservation is the process of documenting, mapping, and rebuilding the operational logic — automations, triggers, macros, escalation rules, SLA policies, and routing configurations — that makes your platform actually function. It's separate from data migration. It requires its own checklist, its own timeline, and its own owner.

This guide gives you a copy-ready checklist and a conversion reference for translating workflow logic between platforms. Whether you're moving between help desks, CRMs, or project management tools, the structural problem is the same: workflows are platform-specific and do not transfer.

Preserving workflows checklist: a migration control document listing every workflow asset, business owner, dependency, risk, and validation step.

Conversion reference: a rule-by-rule mapping spec that records trigger logic, execution order, timing, actor permissions, side effects, and the exact target implementation.

These are separate workstreams because data integrity and workflow behavior fail in different ways. A clean import can still break routing, SLA reminders, approvals, customer notifications, and sync jobs the minute the new system goes live.

For a broader look at migrating help desk data, see our Help Desk Data Migration Playbook.

Why Workflows Break During Every Migration

Data records — tickets, contacts, deals, articles — are portable. They're rows and columns. Workflows are not. They're platform-native logic: conditions, actions, and execution rules encoded in each vendor's proprietary format.

A ticket is a record, so it travels. A trigger is logic that lives inside one platform's rules engine, so it doesn't.

As of 2026, no automation platform offers automated migration — workflows must be manually recreated on the target platform. There is no magic export/import. Not from Zendesk, not from Salesforce, not from Freshdesk. The closest thing is Salesforce's Migrate to Flow tool for internal workflow upgrades, and even that has significant limitations. Jira can import and export automation as JSON, but statuses, issue types, fields, and owners often need reconfiguration. (support.atlassian.com)

The root problem is execution semantics. A rule is not just a name plus a condition. It also has an engine: when it runs, in what order, as which user, with what retry behavior, and against which IDs, statuses, fields, and connected apps.

Beyond execution differences, two more failure patterns show up consistently:

State mismatch. A source status like "Pending" may not map to "Waiting for customer" or a custom pipeline stage in the target. Jira automation transitions fail if there's no valid workflow transition to the destination status or if the rule actor lacks permission. (support.atlassian.com)

Time mismatch. HubSpot can reschedule actions into the next allowed window and applies a 15-minute execution window when timing restrictions are set. Zendesk warns that exact "hours since … is X" conditions can miss because automations don't run at the same minute every hour, especially on larger accounts. (knowledge.hubspot.com)

What Counts as a "Workflow" (Audit Scope)

Before building your checklist, define the scope. "Workflow" is an overloaded term. In a migration context, it covers every piece of operational logic that makes your platform behave the way your team expects.

SaaS migration includes everything: data, user accounts, integrations, workflow configurations, permissions, custom code, and the cutover process. Your checklist needs to account for each of these categories independently.

The Workflow Preservation Checklist

This is the execution sequence. Each item should have an owner and a completion date before cutover begins.

Phase 1: Inventory and Document

• Export all automations, triggers, and macros. Zendesk doesn't provide a built-in export feature for triggers. Your options are using the API to extract trigger data as JSON, or using a third-party migration tool. Most platforms are similar — you'll need the API. Budget for rate limits early: HubSpot's limits vary by subscription tier, and Zendesk Support API limits vary by plan. (developers.hubspot.com)
• List every active workflow with its trigger event, conditions, and actions. Carefully document each workflow, noting its conditions (triggers), operators (logic), and actions (results).
• Capture the execution model for each rule. Record trigger type (event, schedule, manual, webhook, batch), evaluation order, enrollment/re-fire behavior, timing model, actor (system account vs. triggering user vs. integration user), and retry behavior. If a rule can't be described in these fields, you don't understand it well enough to migrate it.
• Flag workflows that reference custom fields, tags, or groups. Any field referenced by a macro, trigger, or automation needs to exist in the new platform before you migrate workflows.
• Identify inactive or obsolete workflows. Most teams find 60 to 80 percent of macros have not fired in the last 90 days. Don't carry dead logic into a clean system.
• Map every SLA policy. Document all SLA objectives, conditions, time thresholds, exclusion statuses, work schedules, and category associations.
• Document escalation chains. Note who gets notified, at what thresholds, and through which channels.
• Record webhook and integration endpoints. Any workflow that calls an external API needs the endpoint, auth method, payload format, and retry behavior documented.
• Screenshot or export saved views/filters. These are the daily working interface for your team and get overlooked until day one on the new platform.

Phase 2: Build the Conversion Reference

The conversion reference is a mapping table that translates source-platform concepts to target-platform equivalents. Without it, your team is guessing during rebuild.

• Map status values. Convert key tags into structured fields for better reporting and workflows. Map statuses to align with your new system's lifecycle.
• Map priority levels. Some platforms use 4 levels (Low/Normal/High/Urgent), others use 3 or 5.
• Map group/team names. Source groups may not exist 1:1 in the target — decide on consolidation or creation.
• Map custom field types. You can only migrate fields of the same type (drop-down to drop-down, text to text, etc.) Document where field type changes are needed.
• Map IDs and references explicitly. Most workflow breakage is in the references behind the logic: status IDs, field IDs, user IDs, group IDs, queue IDs, connection references, and environment variables. Jira's import docs warn these often don't map cleanly. (support.atlassian.com)
• Map automation concepts. See the conversion reference tables below.
• Map SLA models. Different platforms model SLA timers differently — some pause on certain statuses, others don't. Even minor settings, like the 'Start SLA evaluation only when all applicable conditions are met' option, can significantly affect breach time calculations.
• Translate state, timing, and retry behavior — not just labels. Does source "Pending" mean target's "Waiting for customer" or a custom open state? Is a one-hour delay truly one hour, or the next allowed business window? Does a failure retry automatically, or die on first error?

Phase 3: Pre-Build the Target Environment

• Create all custom fields in the target before rebuilding workflows. Fields must exist before any rule can reference them.
• Create all groups, teams, and agent accounts. Routing rules will fail if their targets don't exist.
• Set up SLA policies in the target. Don't activate them yet — build them in draft/inactive state.
• Disable default automations in the target. Imported messages can trigger auto-replies, assignments, and tagging rules if left active. Turn off every default trigger before any data comes in.
• Decide the target implementation pattern for each rule. Not every workflow belongs inside the destination platform. If the target engine can't express the logic safely, move the orchestration to middleware. Use a native rule when the target can express the logic clearly. Use a scripted API rebuild when you need repeatable deployment. Use an external worker or iPaaS flow when the rule coordinates multiple systems, long-running jobs, or large-volume fan-out.

Phase 4: Rebuild and Validate

• Rebuild workflows in priority order. Start by identifying critical workflows that directly affect key business processes. These should be given top priority. Don't rebuild in alphabetical order — rank by operational blast radius.
• Add explicit nullifying conditions to every rule. A workflow must include a condition or action that prevents it from re-firing on the same record indefinitely. Zendesk requires automations to include a nullifying action or a condition that can only be true once. (support.zendesk.com)
• Test each rebuilt workflow with real data. Start small — process just three to five records at a time. For each workflow, collect: one record that should fire, one that should not, one boundary-timing case, one permission edge case, and one failure-path case if the rule talks to another system.
• Compare outputs against source system behavior. Run identical scenarios on both platforms and verify the results match.
• Validate SLA timer behavior. After migration, test what happens when you change SLA rules. Do the new definitions apply only to new issues? Open issues? Closed issues?
• Activate workflows in batches. Don't flip everything on at once. Activate routing first, then escalations, then notifications.

Phase 5: Post-Cutover Verification

• Monitor workflow execution logs for 48–72 hours. Watch for rules that fire unexpectedly or fail silently. Look for rate limit warnings, high volumes of "condition not met" logs (which may indicate a mapped field isn't populating correctly), and webhook delivery failures from authentication mismatches.
• Spot-check SLA breach calculations. Compare expected vs. actual breach times.
• Collect agent feedback on macro behavior. Agents will find the gaps you missed.
• Have a rollback plan ready. If a routing rule goes rogue, you need the ability to disable that specific rule and fail back to a manual triage queue without taking the entire system offline.
• Decommission source workflows only after verification. Migration is complete only when the workflow is consistent, not just when the platform is live.

For a deeper dive into migrating automations during a help desk move, see our guide on migrating automations, macros, and workflows.

Workflow Conversion Reference Tables

Pin these to a wall during rebuild. They map the most common workflow concepts across major platforms.

Automation Rule Types

Status Mapping

SLA Timer Behavior Differences

SLA policies don't just differ in structure — they differ in how they measure time:

• Zendesk pauses the SLA clock on "Pending" and "On-hold" statuses. Custom statuses can optionally pause the clock too (Enterprise only).
• Freshdesk pauses on "Waiting on Customer" and "Waiting on Third Party" by default. You can configure exclusion statuses per SLA policy.
• Intercom does not have traditional SLA timers — time tracking is conversation-based.
• HubSpot Service Hub supports SLAs only on Professional and Enterprise tiers. Timer behavior is tied to pipeline stages, not ticket statuses.

Do not rebuild 1:1. If an SLA no longer supports a real process, leave it behind. Migration is a good moment to simplify old rules, remove unused calendars, and clean up notification logic.

The Conversion Reference Template

A good conversion reference is short enough to maintain and detailed enough to rebuild from. Here's the minimum structure:

workflow_name: Pending reminder after 24h
business_process: customer follow-up
owner: support-ops
criticality: time-sensitive
 
source:
  platform: Zendesk
  asset_type: automation
  trigger_model: hourly scan
  execution_order: n/a
  actor: system
  conditions:
    all:
      - status = pending
      - hours_since_pending > 24
      - tags excludes reminder_sent
  actions:
    - email assignee
    - add tag reminder_sent
  dependencies:
    - ticket status ids
    - agent group ids
    - notification target
  retry_behavior: none
  idempotency_marker: reminder_sent
 
target:
  platform: Jira Service Management
  asset_type: scheduled automation
  trigger_model: hourly schedule
  actor: Automation for Jira
  query: >
    project = SUPPORT
    AND status = "Waiting for customer"
    AND updated <= -1d
    AND labels != reminder_sent
  actions:
    - send email
    - add label reminder_sent
  dependencies:
    - workflow transition map
    - project permissions
    - custom field ids
 
gaps:
  - pending maps to waiting_for_customer
  - labels replace tags
  - permission review required for actor
 
validation:
  should_fire_case: SUP-1042
  should_not_fire_case: SUP-1188
  edge_case: SUP-1210
  rollback: disable target rule and re-enable source

For a tabular version, use columns for: Source Workflow Name, Type, Trigger Event, Conditions, Actions, Target Equivalent, Target Config Notes, Owner, and Status.

Include transformation rules: date format changes, picklist value rewrites, unit conversions, text length truncation, and default values for missing data. Store this mapping in version control.

Translating Webhooks and Payloads

When workflows interact with external systems, the shape of the data matters. A webhook firing from Zendesk looks completely different from one firing from Salesforce, even if they represent the same business event.

Here's how a simple "Ticket Closed" payload changes between platforms:

Source: Zendesk Webhook Payload

{
  "ticket_id": "12345",
  "status": "solved",
  "assignee_email": "agent@company.com",
  "custom_fields": {
    "3600123456": "Enterprise"
  }
}

Target: Salesforce Outbound Message / Flow JSON

{
  "CaseId": "5003h00000abcdeAAA",
  "Status": "Closed",
  "OwnerEmail": "agent@company.com",
  "Customer_Tier__c": "Enterprise"
}

The keys, status values, and custom field structures are entirely different. If you point your new system at old middleware without updating the parsing logic, every external automation will fail. Your conversion reference must include payload mapping for every webhook-driven workflow.

Platform-Specific Constraints That Break Translations

The core of workflow translation is understanding how the target platform's architecture differs from the source. These are the mismatches that break migrations most often.

Zendesk Triggers → Salesforce Flows

Zendesk processes triggers in strict top-down order. If Trigger 1 updates a ticket, Zendesk re-evaluates the entire trigger list from the top. Salesforce Record-Triggered Flows don't guarantee execution order unless configured via Flow Trigger Explorer. Salesforce also enforces SOQL query limits (100 per transaction) — translating 50 Zendesk triggers into 50 individual Flows can crash a single record update.

Translation strategy: Consolidate. Group related Zendesk triggers (e.g., all routing rules) into a single Salesforce Flow with multiple decision branches.

HubSpot Workflows → Jira Automation

HubSpot workflows are enrollment-based. A contact meets criteria, enters the workflow, and progresses through delays and actions. Re-enrollment must be explicitly enabled. Jira Automations are event-based (e.g., "Issue Transitioned") and come with hard execution limits based on pricing tier. A poorly translated rule that updates an issue on every minor edit can burn through your monthly Jira automation allowance in days.

Translation strategy: Shift from state-based logic to event-based logic. Instead of asking "Is the record in this state?" ask "Did the record just change to this state?"

Zendesk Automations → Jira Scheduled Rules

Zendesk automations run on an hourly scan. The safe pattern uses a nullifying action (like adding a tag) to prevent re-fire. Jira's equivalent is a scheduled rule with JQL. Atlassian documents a 999-work-item cap for scheduled JQL queries and warns that broad fan-out rules can hit processing limits. (support.atlassian.com)

Translation strategy: Keep queries narrow. Use labels or custom properties as idempotency markers. Confirm the workflow allows the transition and the rule actor has permission.

Failure Modes to Watch For

Even with a thorough conversion reference, edge cases will test your architecture.

Imported records triggering live automations

The most destructive failure. You import 50,000 historical tickets. Every "on ticket created" trigger fires. Agents get 50,000 notifications. Customers get 50,000 auto-replies. Fix: Disable all triggers and automations before importing any data. Re-enable only after import is complete and verified.

Infinite loops

Automation A updates a record, triggering Automation B, which updates the record in a way that re-triggers Automation A. In legacy systems, hidden platform-specific safeguards often prevent these. When you move to a new system, those safeguards disappear. Fix: Build explicit exit criteria (e.g., an idempotency tag like reminder_sent or a counter check like update_count < 2) into every converted rule.

Race conditions

If two workflows fire simultaneously on the same event and both update the same record, the outcome depends on which finishes last. If your source executed rules sequentially but your target runs them asynchronously, you'll get race conditions. Fix: Combine conflicting rules into a single workflow with a defined order of operations.

Ghost SLAs

SLAs are time-driven workflows. Migrating historical tickets into a new system often triggers immediate SLA breaches because the creation date is in the past. Fix: SLA timers should only apply to records created after cutover, or pause SLA evaluation during import. Use API-based imports that preserve original timestamps — CSV imports almost never handle this correctly.

Multi-select fields losing values

Loss of field granularity (for example, a multi-select field lands as a single-select field and keeps only one value) happens when target platforms don't support the same field types. Fix: Audit every field type mismatch before migration. Where the target doesn't support multi-select, create multiple single-select fields or concatenate values into a text field.

Workflows depending on retired features

Salesforce has officially announced the End of Support for Workflow Rules and Process Builder, effective at the end of 2025. Administrators must transition their automation processes to Salesforce Flow. If your source platform has deprecated features your workflows depend on, rebuild for the new paradigm — not just the new platform.

When to Rebuild vs. Preserve 1:1

Not every workflow should be replicated exactly. Migration is an opportunity to clean house.

Rebuild 1:1 when:

• The workflow directly impacts SLA compliance or revenue
• Agents depend on it daily and the logic is sound
• The target platform supports equivalent functionality

Redesign when:

• Modernization should focus on improved architecture, not one-to-one feature replication.
• The original workflow was a workaround for a source platform limitation
• The target platform has native features that do the same thing better
• The workflow references deprecated features (e.g., Salesforce Workflow Rules, Process Builder)

Retire when:

• Most teams discover a graveyard of rules nobody remembers creating.
• The workflow hasn't fired in 90+ days
• Nobody can explain what it does or why

Assign each workflow an estimated rebuild time. Simple trigger-action workflows take 15–30 minutes. Complex multi-step workflows with conditional logic take 1–3 hours. Workflows requiring custom code or API configurations may take a full day.

Estimating Workflow Migration Effort

Use this rough sizing model to plan the work:

A structured migration process typically takes 2–6 weeks depending on workflow count and complexity. For a 200-agent help desk with 80 active triggers, 40 macros, and 5 SLA policies, budget 40–80 hours of workflow rebuild work — on top of the data migration itself.

Engineering the Transition

The workflow preservation checklist isn't a nice-to-have — it's the line between a migration that looks done and one that actually is done. Most teams underestimate the tribal knowledge and 'temporary' exceptions holding their current workflows together. If you don't document them before cutover, you'll spend weeks rediscovering them through support escalations and angry Slack messages.

Build the inventory. Build the conversion reference. Test with real data. Don't declare victory until your team has run production on the new platform for at least a week without reverting to the old system.

For broader migration planning, check out our data migration checklist template and data migration mapping cheat sheet.