Migrate from Planio to Jira

Planio Projects map directly to Jira Projects. Each Planio Project becomes a Jira Project with the same name and description. We pre-create Jira Projects using the Jira REST API before any Issues are migrated, so that the Project key (e.g., PROJ) is available as a parent reference for all child Issues. Project-level settings including default assignee, notification scheme, and issue security level are configured in Jira before migration begins.

Planio Issues map to Jira Issues with the type determined by a configurable rule during scoping. Planio Tracker (Bug, Feature, Support, etc.) maps to Jira Issue Type (Bug, Story, Task). Planio Priority and Status values map to Jira Priority and Status respectively, with the Jira Status mapping driven by the target project's Statuses configuration. Custom fields on Issues are mapped to pre-created Jira custom fields by name and type. We preserve Planio's Issue description, reporter, assignee, created date, and updated date.

Planio sub-issues map to Jira sub-tasks with the parent Issue ID preserved in Jira's Parent link field. Cross-issue relations (blocks, duplicated by, relates to, blocks, duplicated by) map to Jira Issue Links of equivalent type. We export the full relation graph from Planio, reconstruct parent-child links using the exported Issue IDs, and bulk-create Jira sub-tasks and issue links after all parent Issues are established in Jira. This addresses the Planio CSV import limitation that does not natively preserve sub-issue hierarchy.

Planio custom field definitions (name, type, possible values, required flag) are pre-exported and mapped to Jira custom field types before any Issue migration begins. Text, integer, float, date, and boolean map directly. List fields map to Jira Select List (single choice) or Multi-Select List. User-type fields map to Jira User Picker (single or multiple). Version fields map to Jira Version Picker. We create each Jira custom field via the Jira REST API and associate it with the relevant issue types and projects before import.

Planio Time Entries map to Jira Worklogs attached to the migrated Issue. Each worklog preserves hours, activity type (as worklog comment), and date. Note that Jira native worklog entry requires the Log Work button and is available natively on Premium and Enterprise tiers; Standard tier uses Jira Tempo (a separate Marketplace app) for time tracking. We flag this distinction during scoping so the customer provisions the appropriate tier or Tempo subscription before migration. Time entries with no associated Issue are logged against a default catch-all project issue flagged for review.

Planio Wiki pages are exported as structured HTML with internal Planio links (issues, files, repositories) preserved as absolute URLs or placeholder strings. The destination is Confluence Cloud or Data Center, which is a separate product and separate license from Jira. We deliver a written migration map for each wiki page (source URL, target Confluence space and page URL, any broken internal links) so the customer's admin can manually re-import or use a third-party HTML-to-Confluence importer. Jira itself does not have a native wiki feature.

Planio Documents (uploaded files under Projects or Issues) migrate as Jira Attachments linked to the migrated Issue or Project. We export file metadata and binary content, preserving the original filename and folder hierarchy. Jira Cloud has a 32 MB per-file attachment limit; files exceeding this are flagged for the customer to store externally (Google Drive, SharePoint, or an S3 bucket) with a link provided in the Jira Issue description.

Planio Git and SVN repository hosting and the commit-to-issue linking metadata are exported as a structured record set. The repositories themselves cannot migrate as hosted git data to Jira, which does not provide native repository hosting. We deliver a repository migration map specifying the source Planio repository URL, the target external hosting service (Bitbucket Cloud, GitHub, GitLab), and the commit hash history so that the customer's DevOps team can clone and push to the new hosting location. Jira issue keys in commit messages are re-linked at the destination.

Planio Help Desk Customers are a distinct role separate from Users, able to submit tickets via email without a full user seat. Jira Service Management (JSM) provides a customer portal with a similar model, but JSM requires separate licensing and configuration. We export Help Desk Customers as a contact record set (name, email, ticket history) and deliver a written handoff document for manual import into JSM or for linking to a customer identity management system. Standard Jira does not support a customer portal.

Planio Project News posts and Forum threads are exported as structured text records with author, timestamp, and content. These are low-priority migration objects with no direct Jira equivalent. News and Forum threads are delivered as a structured export (JSON or CSV) and a written recommendation to recreate them as Jira project Activity log entries or Confluence pages depending on the team's documentation preference.

Planio Users (active members with login, email, name, admin flag, and preferences) map to Jira Users by email address match. We export all active Planio users and match by email against the Jira destination. Any Planio user without a matching Jira account is placed in a reconciliation queue for the customer's admin to provision before record migration proceeds. Suspended or locked Planio users are exported as inactive Jira users to preserve historical attribution.

Planio custom roles and per-project permission assignments are exported as structured role definitions and membership lists. These map to Jira Permission Schemes (granting permissions to roles) and Project Roles (grouping users by function). We deliver a written permission matrix showing each Planio role, its permissions, and the equivalent Jira Permission Scheme and Project Role so the customer's Jira admin can configure the destination during or after migration. Jira's permission model is more granular than Redmine's and may require simplification during the rebuild.