Migrate from Mission Control to Jira

Mission Control Projects map directly to Jira Projects. We extract project name, description, status (active/archived), start and due dates, owner, and member list. Sub-project hierarchies in Mission Control are flattened on export; we reconstruct top-level parent-child relationships using Jira Project features (Project categories or linked projects) and document the hierarchy structure for manual reconfiguration if the customer requires it.

Mission Control Tasks map to Jira Issues with the type determined by a convention agreed during scoping: Tasks with status values indicating development work become Jira Stories or Tasks; tasks flagged as bugs or issues become Jira Bugs. The Mission Control priority field maps to Jira Priority (Highest, High, Medium, Low, Lowest). Assignee, due date, and description migrate directly. Custom fields on Tasks map to Jira custom fields by name match.

Mission Control Subtasks nested within Tasks map to Jira Sub-Tasks up to two levels of nesting (Jira supports Issue > Sub-Task). Subtasks nested beyond two levels under the same parent are exported as Jira Sub-Tasks with a parent_reference field linking them to the correct parent Issue. The Mission Control export flattens any hierarchy deeper than three levels; we reconstruct up to two Jira Sub-Task levels and flag any remaining depth loss on the field-mapping worksheet.

Mission Control Users map to Jira Users by email address. We export all user records including name, email, role, and avatar URL. Unresolvable users (no matching Jira account) go to a reconciliation queue for the customer's admin to provision. Jira does not support user avatar upload via API, so avatar references are noted as manual post-migration configuration.

Mission Control Teams map to Jira Groups. Team memberships transfer as Jira Group membership records. Jira Groups are used in Permission Schemes, Notification Schemes, and Project Roles. We map team name to group name and preserve the member list. If the customer uses Jira Software Premium or Enterprise, Groups also drive automatic team-based sprint assignment.

Mission Control Comments migrate to Jira Issue Comments with author (resolved via User mapping), timestamp, and comment body preserved. Comment thread sequence is maintained by ordering inserts by the original Mission Control created_at timestamp. Rich-text formatting in Mission Control comments is converted to Jira Wiki Markup or plain text depending on complexity. Comments on Projects attach to the Jira Project description or a linked Issue at the customer's preference.

Mission Control file attachments are stored with name, size, mime type, and URL. We preserve the URL reference and download metadata; actual file content transfer depends on whether the source storage is publicly accessible. Jira Attachments are uploaded via the REST API using multipart/form-data. Files exceeding Jira's attachment size limits (250 MB per file on Cloud) are flagged on the worksheet with a recommendation to use Jira Cloud storage add-ons or external file hosting for large assets.

Mission Control Tags migrate to Jira Labels. Tags are simple string labels applied to Tasks and Projects. We export the full tag vocabulary and apply tag values to matching Jira Issues. Tags without a Jira-compatible character set are sanitized (spaces replaced with hyphens, special characters removed) and noted on the field-mapping worksheet.

Mission Control per-account custom field definitions on Tasks are extracted before migration. We match custom fields to Jira custom fields by name and map the field type: Mission Control text fields map to Jira Text Field (single-line), Mission Control long-text fields map to Jira Text Field (multi-line), picklist values map to Jira Select (single-option) or Radio Button, and multi-select values map to Jira Multi-Select. Any custom fields without a Jira match are staged in a temporary custom field until the Jira admin creates the equivalent field.

Mission Control custom fields on Projects (if present) map to Jira Project Properties or to a custom field on a designated Project-level Issue. Jira does not support native custom fields on Project records directly; we use a Project-level summary Issue or Jira Project Properties API to preserve the data. The customer chooses the approach during scoping.

Mission Control workflow automation rules (triggers, conditions, and actions) do not migrate as executable definitions. Jira's workflow engine uses statuses, transitions, post-functions, conditions, and validators in a project-scoped workflow scheme that differs fundamentally from Mission Control's event-driven automation builder. We export the full Mission Control rule set as structured JSON documentation including trigger events, condition logic, and action sequences. The customer's Jira admin rebuilds the equivalent logic using Jira Automation or ScriptRunner post-migration.

Mission Control role-based permissions export as a role matrix documenting what each role can access. Actual permission enforcement is destination-system-specific. We map Mission Control roles to Jira Permission Schemes and Project Roles (Developers, Administrators, Users) based on the exported permission matrix. Jira granular permissions (Browse Projects, Create Issues, Edit Issues, Assign Issues, Transition Issues) are assigned per project and must be reviewed by the customer's Jira admin post-migration to account for the additional control Jira provides.