Migrate from MindGenius to Jira

Each MindGenius Project container maps to a Jira Project. We export project-level metadata (name, description, created date, owner) and create the Jira project with the appropriate project type (Team-managed or Company-managed) during migration scoping. The Jira project key is derived from the MindGenius project name acronym.

A MindGenius Mind Map with its hierarchical branches maps to a Jira Epic as the parent container, with each top-level branch becoming a Jira Story or Task beneath it. We use the map name as the Epic summary, the map's creation date as the Epic created date, and the map owner's display name as the Epic reporter. The Epic description captures the root node label and any map-level notes.

MindGenius Level-1 and Level-2 branches map to Jira Stories. Each branch label becomes the Story summary, rich notes become the description, and branch priority markers (High, Medium, Low) map to Jira Priority values. We split branches at the same hierarchy level into separate Story issues and use Jira Issue Links (parent/child) to maintain the original tree structure.

MindGenius branches at depth 3 and below map to Jira Tasks. Very deep branch trees (5+ levels) are distributed across the Jira Epic > Story > Task > Sub-task hierarchy proportionally: Level-3 branches become Tasks linked to their parent Story; Level-4 and below become Sub-tasks linked to their parent Task. This prevents hierarchy overflow while preserving the relationship chain.

MindGenius Taskboard converts branches into Kanban cards with Status (To Do, In Progress, Done), Assignee, and Due Date. We extract the card status and apply it as the initial Jira issue status by mapping to the first matching column in the target Jira project's board. Assignee is resolved by email match against Jira Users. Due date migrates directly to the Jira Due Date field.

MindGenius Timeline view items with start and due dates migrate as Jira issues with Start Date and Due Date populated from the exported MS Project XML date fields. Milestones (zero-duration markers in MindGenius) map to Jira Milestone type or a custom Milestone label on an Issue. The Timeline bar's percent-complete value migrates to the Jira resolution percentage if the issue is closed.

MindGenius priority flags (Critical, High, Medium, Low) on branches map directly to Jira Priority values (Highest, High, Medium, Low, Lowest). The mapping is defined during scoping and applied as a transform step before Jira Bulk API import.

MindGenius branch colours (a visual hierarchy cue not native to Jira) are preserved as a Jira custom field of type Select (Branch Colour). We create the custom field during schema setup, populate it from the MindGenius branch colour property, and the customer's admin can optionally use it in Jira dashboards or filter by colour for visual planning.

MindGenius branch icons (flags, checkmarks, exclamation marks) are preserved as a Jira custom field of type Text (Branch Flags) containing a comma-separated list of the original icon codes. If Jira Automation is available (included in Jira Cloud), the customer can configure status-change rules based on flag presence as a post-migration rebuild.

MindGenius branch attachments (PDF, image, Office files) are not included in standard MindGenius file exports. We generate a manifest of all attachment references (file name, original path, size, branch context) and prompt the customer to manually upload or provide a shared drive path for re-attachment in Jira. We do not scrape binary attachment data from the MindGenius web UI without an authenticated session.

MindGenius Assignee references on Taskboard cards and Timeline items are resolved by email match against the Jira destination project's user directory. Any MindGenius Assignee without a matching Jira User goes to a reconciliation queue for the customer's admin to provision before the migration resumes. Unassigned branches default to the Jira project lead or stay unassigned per the customer's preference.

MindGenius custom fields on branches (key-value properties created by the customer) migrate to Jira custom fields of the closest matching type: text properties become Jira Text Field, date properties become Jira Date Field, number properties become Jira Number Field, and multi-select properties become Jira Multi-Select. We pre-create all custom fields in the Jira destination project during schema setup before any data import.