3 Migration from Data Center

This guide is for Jira Cloud administrators. It explains how to upload a migration ZIP exported from WorkflowWise - Parallel Approval and Workflow Extension (Jira Data Center), run validation, map objects, review the migration plan, start the background import, and check the result in WorkflowWise - Parallel Approval and Workflow Extension (Jira Cloud) / Workflow Parallel Approval (Jira Cloud).

Cloud import supports two DC migration package types: approval rule configuration packages and approval history packages. These packages are uploaded, validated, and imported separately. There is no strict import order; handle each package according to your migration plan.

Supported Package Types

Configuration package import writes or replaces Cloud approval rules. History package import only writes historical display data and does not trigger approvals, Jira workflow transitions, validators, or notifications.

Before You Import

Entry Point: DC Migration Page

Open

In Jira administration, go to Manage apps, then select DC Migration from the WorkflowWise menu on the left.

The DC migration control center shows five stages:

Notes:

• The page only uploads the ZIP and collects administrator confirmations. Package parsing, validation, and import writes are handled by the system in the background.

• Delete package files deletes only the uploaded migration package files and saved task information on the page. It does not delete data already written to Cloud or audit history.

• If Resume a migration or Migration history is shown, use it to review recent tasks and historical import records.

Path A: Import Approval Rule Configuration

A configuration package imports migratable DC approval rule configuration into Cloud. Configuration import requires object mapping first, then Review and confirmation before anything is written.

A1. Select The Configuration ZIP

Open

In Upload package, click the upload area or drag the configuration ZIP exported from DC into the page.

Configuration package names usually look like:

workflowwise-configuration-global-*.zip

After selecting the file, the page shows the file name, size, and Upload and preview button. Confirm the file is correct, then click Upload and preview.

A2. Wait For Validation

Open

After upload, the page moves to Validate. The system checks the package in the background and confirms whether it can move to Review.

Validation does not write, delete, or modify Cloud approval rules, notification templates, or history records.

A3. Review The Migration Plan Summary

Open

After validation, the page moves to Review. The summary cards show:

If All identities must be mapped appears, some objects are not yet mapped to Cloud targets. The left-side workflow shows the areas to complete: Map projects, Map workflow context, Map people and fields, Review rules, and Review files.

A4. Map Projects

Open

Start with Map projects. The system tries to match DC project keys to Cloud projects automatically. If matching succeeds, the status appears as resolved or Mapped.

When mapping projects, confirm:

• Each DC project maps to the correct Cloud project.

• Different DC projects are not mapped to the same Cloud project.

• If the target project does not exist in Cloud, create or adjust it in Jira Cloud first, then return to the migration page to re-preview or map again.

Project mapping is the basis for workflow context mapping. Issue types, statuses, and transitions are resolved inside the mapped project context.

A5. Map Workflow Context

Open

In Map workflow context, the system groups issue types, statuses, and transitions by project context.

If automatic matching does not find a target, use the dropdown in the Mapping column to search for and select a Cloud target. After selection, the row may show Pending confirmation. This means the local choice is recorded and must be confirmed by clicking Next.

Notes:

• Workflow mapping must be completed in the correct project and issue type context. Do not blindly confirm objects just because their names match.

• If the dropdown says project or workflow context must be mapped first, go back and complete the prerequisite step.

• After clicking Next, the system refreshes the Review result. The import blocker is cleared only after the system confirms the mapping.

A6. Confirm Mapping Status

Open

After selecting mappings in the current step, the footer may show Pending confirmation. Click Next to confirm the mappings for that step.

If confirmation fails or the system is temporarily busy, the page keeps your local choices and shows a retry action. Do not repeatedly reselect the same mappings. Wait a moment, then retry confirmation.

A7. Map People And Fields

Open

In Map people and fields, handle users, groups, and custom fields.

Configuration import cannot start while required users, groups, or fields remain unmapped. History packages do not require these mappings because history users are displayed from DC snapshots.

A8. Review Rule Import Actions

Open

After all required mappings are complete, go to Review rules. This page shows the default action and final action for each DC rule.

Configuration conflicts default to replace-with-dc. You can change actions one by one, or use bulk buttons:

• Replace conflicts: set conflicting rules to replace-with-dc.

• Keep Cloud conflicts: keep the Cloud version for conflicting rules.

• Import new rules: set importable new rules to import-new.

• Skip unresolved: set unresolved rules to skip.

If the configuration package includes migratable notification templates and you want to import them, select Import notification templates without credentials. The migration package does not restore mail, Slack, or other credentials. Recheck those settings in Cloud after import.

A9. Confirm And Start Import

Open

After clicking Start import, the system shows a confirmation dialog. Before confirming, check again:

• All required objects have been mapped.

• The counts for replace-with-dc, keep-cloud, import-new, and skip are expected.

• Cloud rules that will be replaced have been reviewed.

• Notification template import is intentional, and credentials are planned for reconfiguration in Cloud.

Click Start import in the dialog to create the background import task. Before importing, the system rechecks the target Cloud rule state. If another administrator changed related Cloud rules after Review, import stops and requires another Review, so newer Cloud configuration is not overwritten.

A10. Monitor Import Progress

Open

In Import, the page shows the current task, phase, progress bar, and metric cards.

The import runs in the system background. If the page is closed or refreshed, use the current task or recent tasks to resume viewing progress. A running task can be cancelled; cancellation does not roll back records that were already written successfully.

A11. Check The Import Result

Open

After import completes, the page moves to Result. Check:

If failures are listed, start with the user-facing explanation and next action shown on the page. A common case is that a target Cloud rule changed after Review; in that case, run Review again and then import.

A12. Confirm Rules In Approval Rules

Open

After configuration import, open Approval Rules from the left menu and check that imported rules appear under the expected project, issue type, and status.

For configuration packages, at minimum check:

• Rule counts match the Imported / Replaced counts in the import result.

• Project, issue type, and approval status are as expected.

• Open rule details and check approvers, groups, custom fields, approve/reject transitions, decision behavior, and enabled state.

• If notification templates were imported, open Notifications and recheck credentials and enabled state.

Path B: Import Approval History

An approval history package imports completed DC approval nodes and votes into Cloud as read-only history and audit data. It does not create active approvals, does not turn historical approvals into current approval tasks, does not trigger Jira workflow transitions, and does not send notifications.

The key difference from configuration import is that history import only requires the target project key to resolve in Cloud. Users, statuses, issue types, and transitions are displayed from DC export snapshots and do not need to be mapped one by one.

B1. Select The History ZIP

Open

In Upload package, select the approval history ZIP exported from DC.

History package names usually look like:

workflowwise-history-WWTB-20260608-103127.zip

Confirm the file is correct, then click Upload and preview.

B2. Wait For History Package Validation

Open

History package validation checks whether the package is valid, files are complete, the target project exists, and the amount of history data is within the system's handling range. History packages have additional size and volume reminders. If the package is above the recommended range but below the hard limit, the page shows Preview warnings and import can still continue. If it exceeds the hard limit, return to DC, reduce the history range, and export again.

B3. Review History Import Impact

Open

After validation, the page moves to Review. The history package page shows:

If there are many preview warnings, open Review files to review file or limit warnings. After confirming the impact is acceptable, click Start import.

B4. Confirm History Import

Open

The system shows the same confirmation dialog as configuration import. Even though history import does not modify rule configuration, confirm:

• The target project key is correct.

• Nodes and Votes match the expected DC export scope.

• Preview warnings have been reviewed and accepted.

• The Unresolved issues count is acceptable. History for those issues will be skipped.

Click Start import to start the background import.

B5. Monitor History Import Progress And Result

Open

History import may contain many nodes and votes. The background task writes them in batches and records progress. The page shows Processed, Votes, Succeeded, Skipped, and Failed.

After import completes, the Result page shows the import summary, skipped or failed details, and audit id. Reimporting the same history package does not create duplicate history records; the system recognizes records from the same source and avoids duplicate display.

What Import Writes

Configuration Packages Write

• Approval rule configuration supported by Cloud.

• New Cloud rule records for import-new.

• Overwritten results for replace-with-dc, while keeping the existing Cloud rule record.

• Before-import snapshots for replaced rules, used for audit and troubleshooting.

• Related data needed for the Cloud rule list and search.

• Optional Email/Slack notification template content, without credentials.

History Packages Write

• Read-only history records for completed approval nodes.

• Completed vote records, including revocation relationships when available.

• DC-exported status, user, and approver snapshots for history display.

• Import source information for duplicate detection and audit records.

Import Does Not Write Or Do Automatically

• It does not create Jira projects, issues, users, groups, statuses, transitions, or custom fields.

• It does not import unsupported rules or fields that were not included in the DC ZIP.

• It does not restore Slack tokens, mail service settings, WeCom settings, or other credential-like settings.

• It does not automatically modify Jira workflow validators or conditions.

• It does not trigger approval runtime behavior, workflow transitions, validators, or notifications.

• History packages do not import in-progress approvals or unfinished votes.

• Deleting uploaded package files does not delete imported Cloud data or audit history.

FAQ

Can Configuration And History Packages Be Uploaded Together?

No. Each import flow handles one ZIP. Configuration and history packages must be uploaded, validated, reviewed, imported, and checked separately.

Must The Configuration Package Be Imported First?

No. Configuration and history packages have no strict order. Validate and import them separately according to your migration plan. History packages are imported as read-only records and do not depend on configuration package import being completed first.

Why Is The Start Import Button Disabled?

Usually because a configuration package still has required objects that are not mapped, or the current step has Pending confirmation. Complete the left-side steps and click Next to let the system confirm. For history packages, import is usually blocked only when the target project key cannot be resolved.

Why Does Pending Confirmation Still Show After I Select A Mapping?

Mapping choices are saved locally first. Click Next to submit confirmation. The import gate is cleared only after the system refreshes Review and confirms that the objects are resolved.

Does replace-with-dc Delete A Cloud Rule?

No. It does not delete the rule and then create a new one. The system overwrites Cloud-supported fields on the conflicting Cloud rule and saves a before-replacement snapshot in the result or audit record for troubleshooting.

What If Someone Changes A Cloud Rule After Review?

Before import starts, the system confirms that the target Cloud rule still matches what was reviewed. If the target rule changed, import stops and asks for Review again, preventing newer Cloud configuration from being overwritten.

Why Does A History Package Not Require User Mapping?

History packages are read-only display and audit data. DC users are shown from exported snapshots such as name, username, and email. If Cloud can uniquely match a current user by email, the page may show the current Cloud user information.

What Should I Do After Import Succeeds?

After configuration import, check the Approval Rules list and rule details, then manually review Jira workflow validators and conditions. If notification templates were imported, recheck mail, Slack, and credential settings in Notifications. After history import, spot-check approval history on several imported issues.

Troubleshooting

What If Validation Fails After Upload?

First confirm the upload is the original migration ZIP exported from DC. Do not unzip it, rename internal files, or modify content manually. Then check the failure reason shown on the page. If the package type is wrong, confirm whether you uploaded a configuration package or history package. If the file is damaged or incomplete, export it again from DC and upload the new ZIP.

What If I Cannot Find A Cloud Mapping Target?

In Jira Cloud, confirm that the target project, issue type, status, transition, user, group, or custom field exists and that the current administrator can view it. After preparing the target object, return to the migration page and search again or run preview again.

What If Mapping Confirmation Fails?

The page keeps your selected mappings. Wait a moment and use the retry action shown on the page. You do not need to upload the package again. If it fails repeatedly, record the current step, failure message, and package file name for support.

Can I Leave The Page During Import?

Yes. Import runs in the background. After refreshing the page, use the current task, recent tasks, or migration history to continue viewing progress. If import fails, follow the page guidance and retry the failed part when available.

Does Delete Package Files Delete Imported Data?

No. Delete package files deletes only the migration package files uploaded to Cloud and saved task information. Imported approval rules, approval history, and audit records remain.

Recommended Checklist

Before upload:

• Confirm the ZIP was exported from DC.

• Confirm you are a Jira administrator.

• Confirm Cloud target projects, issue types, statuses, transitions, users, groups, and fields are ready.

• Confirm whether this import is a configuration package or a history package.

Before configuration package Review:

• Project mappings are correct, and multiple DC projects are not mapped to the same Cloud project.

• Issue types, statuses, and transitions are confirmed in the correct project context.

• Users, groups, and custom fields are not missing or ambiguous.

• Pending confirmation has been confirmed with Next.

Before starting configuration import:

• Check counts for replace-with-dc, import-new, keep-cloud, and skip.