Phase 0

Decide & Plan

Resolve the scope, owner, residency and success-criteria questions before any export or build work begins.

Document the migration objective and the trigger event in one paragraph. Capture why the move is happening now (tool consolidation, Data Center end of support in 2029, M&A, Cloud-only feature need) so later scope debates resolve against the original intent.
Pick the destination Jira edition before any build work: Jira Software, Jira Service Management, Jira Work Management, or Jira Product Discovery. Editions differ on issue types, permission schemes, queue features and pricing. Mixing teams across editions changes the licensing and the import path.
Risk if skipped: Building under the wrong edition forces a re-architect once an edition-specific feature is needed mid-migration.
Pick the destination hosting model: Jira Cloud, Jira Data Center, or remain on legacy Server (end of support Feb 2024). Cloud uses JCMA (Jira Cloud Migration Assistant) for Data Center inbound and Site Import for cloud-to-cloud; Data Center is self-hosted with end-of-life scheduled for 2029.
Risk if skipped: Choosing Data Center now without a 2029 exit plan repeats the same migration in three years.
Define the in-scope object set: Projects, Issues, Issue Types, Issue Links, Sub-tasks, Comments, Attachments, Worklogs, Sprints, Boards, Filters, Dashboards, Users, Groups. List each object explicitly with an in-scope or out-of-scope flag. Treat dashboards, filters and automation rules as separate decisions from issues.
Risk if skipped: Implicit scope expands mid-project as stakeholders discover missing data, blowing the timeline.
Decide the historical-data window: how many years of source issues, comments and attachments come across. Pair each in-scope object with a date cut-off. Older issues can stay archived in the source export instead of imported.
Risk if skipped: Importing unbounded history inflates per-project issue counts and slows JQL queries permanently.
Choose the Jira Cloud plan tier (Free, Standard, Premium, Enterprise) before any build work. Audit log retention, sandbox, release tracks, advanced roadmaps, data residency and Atlassian Guard policies are gated by tier.
Risk if skipped: Building on Standard then discovering Premium-only sandbox or audit needs forces a mid-migration upgrade and re-test.
Select the hosting region for Jira Cloud: US, EU (Frankfurt), AP (Singapore, Sydney) or other available residency. Data residency is set per-product per-site and only available on Standard, Premium and Enterprise plans. Pin the region before any production data is created.
Risk if skipped: An EU customer left on the global tenant must move data residency later under regulator pressure.
Identify legal and compliance constraints that gate the cutover. Capture GDPR data-processing addenda, HIPAA BAA requirement (Atlassian Guard), SOC 2 evidence needs, ISO 27001 scope, customer contracts that name the source platform, retention policies that change on cutover.
Risk if skipped: A missing signed BAA on a HIPAA workload means PHI uploaded to Jira is non-compliant from day one.
Assign a single accountable migration owner (DRI) and a named delegate. One person signs off each phase. Cross-functional input is welcome; ownership is not shared.
Document explicit success criteria for cutover. Example: 100% of in-scope issues present, 99%+ comment fidelity, all attachments downloadable, Sprints reconstructed, dashboards rebuilt, sign-off by named users per team.
Risk if skipped: Without written criteria, every stakeholder applies their own bar and the project never formally closes.
Set the target cutover window (date + time + timezone) and the source-system freeze date. Pick a low-traffic window — weekend or quarter-end gap. Communicate the freeze date as the moment no new tickets can be created in the source.
Document out-of-scope items explicitly: legacy projects, archived dashboards, defunct integrations, dead automation rules, deprecated app data. Naming the un-migrated items pre-empts "why is this missing" questions in Phase 6.

Phase 1

Pre-Migration Prep

Cleanse the source, build the destination site shape, and stage users so the import has somewhere correct to land.

1a. Source-system audit and cleansing

Export source record counts per project, per issue type, per status as a numeric baseline. Capture counts per project, per status, per assignee. Save the export as the reconciliation reference for Phase 6 and the JCMA PTR (Pre-Migration Time Report / Post-Migration Reconciliation Report) comparison.
Risk if skipped: Without a baseline, post-cutover deltas can be explained away as normal instead of investigated.
Run dedup analysis on source issues using a stable match key. Match on source issue key or external ID where present, otherwise on (project, summary, reporter, created). Resolve duplicates in the source while you still have its dedup tooling.
Risk if skipped: Duplicates merged after import require manual cleanup against destination issue keys that did not exist at source time.
Normalize email casing and verify each user email resolves to a real mailbox. Lowercase all email addresses before export. Issues assigned to bounced mailboxes need assignee reassignment before cutover.
Standardize date and datetime values to ISO-8601 with explicit timezone. Jira stores dates in UTC and renders per-user timezone; mixed-format source dates surface as off-by-one-day errors on Due date, Start date and Sprint dates.
Risk if skipped: Date field imports silently shift days at the date-line, producing wrong deadlines on thousands of issues.
Audit and resolve issues missing values for fields that are required on the destination Field Configuration. Required fields block issue creation on import. The CSV importer aborts the issue with a validation error like "Original Estimate is required". Pre-fill or strip the requirement before load.
Risk if skipped: Import jobs surface validation errors mid-load, leaving the project in a half-populated state.
Audit source picklist / Select List / Radio Button options and rationalize them. Consolidate near-duplicate option values ("Won-Closed" vs "Closed Won") at source. Each Custom Field Context on Jira stores its own option set and accepts only exact matches.
Risk if skipped: Mismatched option values fail validation at import with messages like "custom field require options that do exist".
Re-encode any non-ASCII / non-UTF-8 source text as UTF-8 before export. Jira's CSV importer warns on non-ASCII characters and silently mis-renders mixed encodings; set UTF-8 across the export, the CSV file and Jira's encoding settings.
Risk if skipped: German, French and CJK characters arrive as garbled cells with no per-row error.
Strip or replace special characters in long text fields that exceed Jira's 255-character single-line field cap. Summary, single-line custom text fields and labels cap at 255 characters. Route over-length content to Description or a multi-line custom field.
Risk if skipped: Long titles truncate without warning, losing the back half of summaries on thousands of issues.
Clean up source apps, custom workflows and stale configurations before migration. Atlassian recommends pre-migration cleanup of unused workflows, schemes, custom fields and apps. JCMA scans the source and surfaces blockers; resolve them before running a real migration.
Risk if skipped: Carrying broken or unused configuration into Cloud pollutes the destination and inflates the time JCMA spends scanning.

1c. People prep

Communicate the source-system freeze window to every active user with date, time and consequences. Email + Slack + source-system banner. Confirm receipt from project leads.
Identify and brief end-user trainers per team for go-live. Each team needs a designated trainer who knows JQL basics, board configuration and the new workflow.
Designate first responders to triage user issues for the first 48 hours after cutover. Rotation of two admins on-call during the post-cutover window.

Phase 2

Source Export

Pull a clean, time-stamped, complete export of every in-scope object from the source — issues, comments, worklogs, attachments and configuration.

Phase 3

Transform & Map

Build the field mapping, run the transforms and resolve every PM-specific structural question before sandbox load.

3a. Mapping spreadsheet

Build a master mapping spreadsheet: one row per source field with destination field, custom field ID (customfield_XXXXX), type, transform and required-on-import flag. Include nullability, default value, the Custom Field Context that scopes it, and whether the field is on the Create / Edit / View screen.
Risk if skipped: Without a single mapping artefact, transformation rules drift between engineers and the same source field maps two different ways.
Resolve every source field with no destination equivalent: drop, concatenate into Description, or create a new Custom Field. Document the decision in the mapping spreadsheet. Concatenated fields keep history without inflating the custom-field count.
Decide the upsert key per object and document it. Typical: source system issue key stored in a single-line text Custom Field on Jira. External System Import can update issues that match this key on re-runs.
Risk if skipped: Without a stable upsert key, partial re-imports duplicate every previously loaded issue.
Resolve Status value mismatches against the destination Workflow's Status set. Map source ("In Review", "Under Review", "Reviewing") to one destination Status. Create any missing Status via the admin UI before load.
Risk if skipped: An unmapped source status fails workflow validation and blocks the issue from being created.
Resolve Select List / Radio Button option mismatches per Custom Field Context. Each option must exist on the field's context. The CSV importer surfaces "custom field require options that do exist" when a value is missing.
Decide the assignee strategy: best-match by email to Account ID, or assign to a single migration service user. Jira Cloud requires Account ID for the assignee, reporter and watcher fields. Issues whose assignee emails do not resolve to a provisioned Account ID load with empty assignee.
Risk if skipped: Storing the inactive original assignee in a custom text field preserves history without inflating the licensed user count.
Decide the historical-timestamp strategy. Jira's CSV importer does not allow overriding system Modified Date on import; Created Date can be set via the Date Created column. Capture original modified-date in a custom Date field where preservation matters.
Risk if skipped: If historical SLA reports depend on modified-date, losing it misrepresents past performance permanently.
Decide the Issue Type mapping per source type. Jira's new import experience (2025+) supports mapping each source type to a specific destination Issue Type (Epic, Story, Task, Bug, Sub-task) at import time. Earlier importers defaulted everything to Task.
Risk if skipped: Defaulting every source type to Task loses the type semantically and breaks every report grouped by Issue Type.

3b. Data transformation

Convert date and datetime fields to the format selected in the import wizard's Date Time Format Options. The wizard accepts a configurable date pattern; pick one and convert all source values to it. Mismatched formats throw fields.validation.date.format errors.
Risk if skipped: A single off-format date row fails the entire issue import with a date-validation error.
Normalize multi-value fields (Fix Version, Component, Labels) into the CSV importer's repeated-column convention. To import multiple values, repeat the column name for each value. The number of repeated columns must match the maximum number of values per row.
Risk if skipped: Comma-separated values inside a single Labels cell load as one giant label, not as separate labels.
Truncate or re-route text fields that exceed Jira's 255-character single-line cap. Summary and most single-line text fields cap at 255 characters. Route over-length content to Description (multi-line) or a Long Text custom field.
Re-encode every CSV file as UTF-8 with no BOM unless the importer requires it. Atlassian recommends UTF-8 across Jira, the file and the import settings. Mixed encoding silently mis-renders non-ASCII characters.
Risk if skipped: German umlauts, French accents and CJK characters arrive as garbled cells with no row-level error.
Escape commas, newlines and double-quote characters in CSV cells per RFC 4180. Wrap any cell containing a comma, newline or quote in double quotes and double-escape internal quotes. The CSV header row should contain no punctuation other than the separating commas.
Risk if skipped: An unescaped newline in a Description cell breaks every subsequent row's column alignment.
Normalize the Date Created column to the importer's expected date format if preserving original creation timestamps. Mapping the Date Created column on import preserves source creation time. Without this column, the importer stamps create-time to the import moment.
Normalize Original Estimate, Remaining Estimate and Time Spent values to Jira's duration format (e.g. 1w 2d 3h 30m). Jira Worklog and Estimate fields parse a strict subset of duration strings. Source decimal hours (1.5h) must convert to the supported format (1h 30m).

3c. Relationship and audit-trail decisions

Implement the chosen assignee strategy across the transformed files. Either resolve every source assignee email to an Atlassian Account ID, or hard-write the migration service Account ID everywhere.
Stamp original source issue keys into a dedicated single-line text Custom Field on every issue. Field name like source_system_key makes later cross-system reporting and audit-log tracing possible.
Risk if skipped: Without a back-reference, debugging why an issue ended up where it did requires a manual hunt through the source export.
Stamp original created_at and modified_at into dedicated Date custom fields alongside the system timestamps. These power the audit-trail validation in Phase 6.
Decide the attachment strategy: re-upload binaries to Jira vs. link out to external storage (Google Drive, OneDrive, Dropbox, Box). Cloud per-file UI cap defaults to 1 GB (max 2 GB). Account storage is plan-capped (2 GB Free / 250 GB Standard / unlimited Premium).
Risk if skipped: Re-uploading every binary can exhaust the storage cap and silently fail later uploads.
Acknowledge that the Activity tab audit history is not portable across sites. Comments and worklogs migrate; the field-change Activity history does not transfer through CSV import or JCMA in full fidelity. Capture critical field-change history in a custom Long Text field if it matters.

3d. Jira PM-specific structural transforms

Map the source project hierarchy onto Jira's Site → Project → Epic → Story / Task / Bug → Sub-task structure. A common pattern: source portfolio → Site (or multiple Projects); source program → Epic; source project → Story or Task; source sub-task → Sub-task. Jira's parent-child link is Epic-Link for Story-to-Epic and the Sub-task type for Sub-task-to-parent.
Risk if skipped: Flattening five source levels onto Jira's four-level model without an explicit rule produces unpredictable parent-child links and broken roadmaps.
Translate source task dependencies into Issue Links with the right link type (blocks, is blocked by, relates to, duplicates, clones, is cloned by). Issue Links are configurable per site. Create any custom link type before load. Native CSV import accepts a Link column referencing destination keys after the issues themselves exist.
Risk if skipped: Dependency pairs imported before both linked issues exist silently drop the link.
Translate source time entries into native Jira Worklogs with Original Estimate, Remaining Estimate and Time Logged values. Each worklog needs author Account ID, started timestamp, time-spent and an optional comment. Native time tracking lives at the issue level under the Time Tracking section.
Risk if skipped: Worklogs lacking author Account IDs default to the import user and misattribute thousands of hours.
Reconstruct comments threading via the Activity tab payload with @-mentions and visibility restrictions intact. Comments support @-mentions referencing Account IDs and visibility restrictions to a Project Role or Group. Preserve both in the transform; @-mentions to unresolved users render as plain text.
Risk if skipped: Visibility-restricted comments that lose their restriction become world-readable to every project member.
Plan custom workflow Status mappings per Issue Type per Project, attached via Workflow Schemes. Workflows are bound to projects via Workflow Schemes per Issue Type. Statuses must be created via the admin UI first, then referenced by the workflow.
Risk if skipped: Skipping Status creation up front fails the workflow transition the moment the first issue of that type hits it.
Re-create source recurring-task rules as Jira Automation rules in the destination. Jira has no native recurring-issue property. Recurrence is built with Automation rules using the Scheduled trigger and Create Issue action; document each source recurrence and queue the rule for activation post-cutover.
Plan the attachment migration path: JCMA cloud-to-cloud (DC → Cloud) handles binaries natively; CSV import references attachments by URL or file path. Choose the path that fits the median file size and total volume.
Risk if skipped: Mixing paths on the same project leaves attachments scattered between native files and external links with no single source of truth.
Plan Sprint reconstruction: each Sprint name, goal, start, end and complete date is rebuilt on the destination Scrum board. Sprints are board-bound. Closed Sprints carry historical velocity; recreate them with the original dates on the destination before re-assigning issues to them via the Sprint custom field.
Risk if skipped: Reassigning issues to a freshly created Sprint with today's dates inflates current-sprint velocity and erases historical velocity charts.
Plan Board, Filter and Dashboard rebuild post-cutover. Boards, Filters and Dashboards do not transfer through CSV import. Rebuild each board's JQL filter, column config, swimlanes and quick filters; rebuild each dashboard's gadget set against the new filters.

Phase 4

Sandbox Test Migration

Run a full dry run against a non-production site, catch every problem, and only proceed when reconciliation passes.

Phase 5

Production Cutover

Execute the tightly-sequenced production load with the freeze in place, idempotent upserts and full instrumentation.

Phase 6

Validate

Prove the migration was correct. Do not let users into the destination until reconciliation, relationships, audit and UAT all pass.

6a. Reconciliation

Run the JCMA Post-Migration Reconciliation (PTR) report if migrating from Jira Data Center to Jira Cloud via JCMA. JCMA 1.12.45+ generates an Excel PTR comparing source and destination entity counts (projects, issues, comments, attachments, boards, filters, configurations). Investigate every delta.
Risk if skipped: Without PTR, count deltas surface as user complaints weeks later instead of as a structured report on day one.
Compare total issue count per project: source vs. destination. Investigate any delta. Use JQL on the destination: project = X AND created < cutover_timestamp. Compare to the Phase 1 baseline.
Compare open issue count per project (status != Done) source vs. destination. The PM-category aggregate analogous to pipeline value: how many active issues survived the migration intact.
Compare comment count per issue on a 25-issue random sample. Comment-thread reassembly is one of the most common migration losses.
Risk if skipped: Lost comments are invisible until a user looks for a specific decision and cannot find it.
Compare worklog total hours per project source vs. destination. Worklog hours drive billing and capacity reports. A 1% delta on hours becomes a 1% delta on revenue or capacity calculations.
Risk if skipped: Worklog drift goes undetected until the finance team reconciles month-end and finds the hours don't match.
Cross-check 25–50 randomly selected issues field-by-field between source and destination. Walk every visible field: Summary, Description, Status, Assignee, Reporter, Priority, every Custom Field, Labels, Components, Fix Versions, Affects Versions, Due Date, Start Date.
Verify every Custom Field's value arrived intact on a 25-issue sample. Spot-check Select List options, Date values, User-picker resolution and Number formats.

6b. Relationship validation

Verify Epic-Link relationships on a sample of Stories: open the Epic, confirm the Story appears under it. Roadmap and backlog views depend on Epic-Link.
Risk if skipped: Lost Epic-Links break every Roadmap and Advanced Roadmap view that filters by Epic.
Verify Sub-task parent links on a sample of Sub-tasks. Sub-tasks open inside their parent issue. A broken parent reference orphans the sub-task.
Verify Issue Links (blocks / is blocked by / relates to / duplicates) on a sample. Walk both directions: from blocker to blocked and from blocked to blocker.
Verify Sprint reconstruction: closed Sprints show with their original start/end/complete dates and their original issue membership. Render the historical velocity chart and confirm it matches the source's velocity chart.
Risk if skipped: Sprints reconstructed with today's dates render a flat historical velocity, erasing the team's actual history.
Verify attachments are accessible and linked to the right issues. Open 25 random issues with attachments; download each file; confirm the binary matches the source binary by hash or visual inspection.
Verify Comments preserve order, @-mentions resolve to the right users, and visibility restrictions hold. Visibility-restricted comments must still be restricted to the original Project Role or Group.
Risk if skipped: A visibility-restricted comment that lost its restriction becomes world-readable to every project member.

6c. Audit and compliance

Verify the audit-trail strategy worked: original Created Date renders correctly on a sample. If Created Date was preserved via the Date Created column on import, confirm it on 25 random issues.
Verify original assignee and reporter history is preserved (in custom fields or in the live fields) per the Phase 3 decision. Reassigning to a single migration service user is fine; losing the original assignee history without preservation in a custom field is not.
Confirm Jira Cloud data residency: in-scope app data is hosted in the chosen region (US, EU, AP). Verify in the Atlassian Administration → Data residency settings. Data residency applies to Jira, Jira Service Management, Jira Product Discovery and Confluence on Premium / Enterprise plans.
Risk if skipped: An EU-resident customer whose Jira data is on the global tenant is non-compliant with GDPR data-residency commitments.
Confirm the audit log on the destination captures configuration events at the expected granularity for the tier. Free plans do not include the audit log. Standard/Premium/Enterprise capture configuration changes; Enterprise plus Atlassian Guard extend organization-level activity capture.
Confirm SOC 2, ISO 27001, HIPAA evidence collection is in place if regulated. Atlassian's compliance reports cover the platform; the customer is responsible for the in-tenant configuration evidence. Capture screenshots of SSO, MFA, audit settings and BAA.

6d. User-acceptance check

Have 3–5 power users per team validate that their day-to-day workflows work in the destination with migrated data. Engineer creates a Story, triages a Bug, logs a worklog, transitions through the workflow. Support agent opens a Service Request, replies, escalates, resolves.
Document every data issue surfaced by UAT and triage it to closure before opening the site to general users. UAT defects are usually transform bugs, not data bugs. Fix in the transform and re-run for affected issues only.

6e. Sign-off

Get written sign-off from the migration sponsor before proceeding to Phase 7. Sign-off lists: reconciliation pass, relationship pass, audit pass, UAT pass. Sponsor name + date.
Risk if skipped: Skipping written sign-off leaves the project open-ended and lets every post-cutover edge case re-open the migration.

Phase 7

Post-Migration Cleanup

Wrap up so the team can move on — go-live comms, training, source decommission, archive, retrospective.

Watch list

Risks to track throughout

These risks live across multiple phases — keep an eye on them from kickoff through cutover.

Status, Workflow and Custom Field Context drift

Statuses must be created via the admin UI before any Workflow Scheme references them. Custom Field Contexts further scope option values to specific projects and issue types. A single missing Status or option in the wrong context blocks the workflow transition for every issue that needs it and surfaces as a cascading import failure. Lock Statuses, Workflows and Field Contexts in Phase 1 and audit them as part of every sandbox and production load.
Audit-trail and original-timestamp loss on import

Jira's CSV importer accepts Date Created but does not allow overriding Modified Date on import; the field-change Activity history does not transfer across sites. Worklog and Comment authors must resolve to a provisioned Atlassian Account ID or default to the import user, misattributing thousands of hours and hundreds of comments. Capture original modified-date, original assignee and original author into dedicated custom fields in Phase 3 so historical reporting and SLA calculations remain defensible after cutover.
Attachment cap and per-file limit mismatch

Jira Cloud's UI attachment cap defaults to 1 GB per file (max 2 GB). Account storage is plan-capped — 2 GB on Free, 250 GB per product on Standard, unlimited on Premium. A high-volume binary-heavy migration that fits within the per-file cap on paper can still exhaust the account storage cap. Decide the attachment strategy (re-upload via JCMA or UI vs. external storage links) in Phase 0 and Phase 3 before any binary lands.
Bulk-load notification bursts and automation runaway

Loading 50,000 issues into a project with five active Automation rules triggers up to 250,000 rule executions, each potentially sending an email, transitioning a status, or writing a field. Disable every Automation rule, integration and notification scheme on the destination before the first row lands and re-enable in deliberate waves after Phase 6 validation begins.

Asana→Jira monday Work Management→Jira Trello→Jira Microsoft Project→Jira

See Jira migration overview All Project Management migrations Estimate your migration

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

Migration Checklist: Moving to Jira

Decide & Plan

Pre-Migration Prep

1a. Source-system audit and cleansing

1b. Destination site and schema setup

1c. People prep

Source Export

Transform & Map

3a. Mapping spreadsheet

3b. Data transformation

3c. Relationship and audit-trail decisions

3d. Jira PM-specific structural transforms

Sandbox Test Migration

Production Cutover

Validate

6a. Reconciliation

6b. Relationship validation

6c. Audit and compliance

6d. User-acceptance check

6e. Sign-off

Post-Migration Cleanup

Risks to track throughout

The complete Jira migration guide

Migration Checklist: Moving to Jira

Decide & Plan

Pre-Migration Prep

1a. Source-system audit and cleansing

1b. Destination site and schema setup

1c. People prep

Source Export

Transform & Map

3a. Mapping spreadsheet

3b. Data transformation

3c. Relationship and audit-trail decisions

3d. Jira PM-specific structural transforms

Sandbox Test Migration

Production Cutover

Validate

6a. Reconciliation

6b. Relationship validation

6c. Audit and compliance

6d. User-acceptance check

6e. Sign-off

Post-Migration Cleanup

Risks to track throughout

Common migrations to Jira

The complete Jira migration guide