Migrate from Meegle to Jira

Meegle Workflows map to Jira Projects. Each Workflow template or live instance becomes a Jira project with an Issue Type Scheme that defines which issue types (Epic, Story, Task, Bug, Subtask) are available. We set the Jira project key during scoping based on the source Workflow name and configure the default issue type for new items. Workflow instance status values map to Jira status categories (To Do, In Progress, Done) and are whitelisted per the project's Status Scheme.

Meegle nodes of type task, milestone, or group map to Jira Issues of the corresponding type. Node type, position, title, description, assignee, due date, and standard properties transfer as typed Jira fields. We use the Jira REST API to create issues in dependency order so that blocking issue links can be established as each node is created. Node custom fields require pre-creation of Jira custom fields of matching type before import.

Meegle Tasks (a node type) map directly to Jira Task issues. The task title, description, assignee, due date, status, and attachment references transfer to the equivalent Jira fields. If the Meegle task has a story-like description (acceptance criteria in the body), the customer may elect to map it as a Jira Story instead during scoping.

Meegle subtasks exist as nested node relationships within a parent task node. We flatten the hierarchy into Jira Subtask issues linked to their parent Issue via the Jira subtasking feature. Subtasks require the parent issue to exist before they can be inserted, so we process subtasks after the parent issue creation phase.

Meegle custom fields per workflow map to Jira custom fields. We map text fields to Jira Text Field (multi-line), number fields to Number Field, date fields to Date Picker, and multi-select fields to Jira Multi-Select (options). Formula fields and calculated fields in Meegle have no direct Jira equivalent; we flag these and map the last-evaluated value as a read-only Jira Number or Text field. Custom field schemas vary by workspace in Meegle, so we audit each source workflow independently and create Jira fields in the destination project before data migration begins.

Meegle view configurations (field visibility, sort order, grouping rules) are display settings, not data. We export view configurations as metadata and deliver them as a written reference for the customer's admin to configure in Jira Board settings post-migration. Jira Board filter queries replace Meegle's view filtering logic, and the admin rebuilds column configurations and swimlanes manually.

Meegle's advanced dependency feature links nodes with finish-to-start, start-to-start, and custom dependency types. Jira does not natively support start-to-start or custom dependency types. We translate finish-to-start links to Jira blocking issue links (blocks / is blocked by). For start-to-start links, we flag these and recommend converting to Jira's dependency blocking pattern or using labels for the source dependency type. The full dependency graph is exported as a reference document.

Meegle roles govern cross-space authorization and map to Jira permission schemes scoped per project. We map each Meegle role to a Jira Project Role (Administrators, Members, Viewers) and configure the corresponding Permission Scheme to grant the equivalent access. Cross-space authorization (a role that grants access to nodes across multiple Meegle spaces) does not have a direct Jira equivalent; we flag this as a multi-project or shared configuration issue for the customer's admin to resolve.

Meegle attachments stored in Meegle's file system are extracted by reference during export. We re-link them as Jira attachments after importing the parent issue. File size limits and accepted file types in Jira Cloud (50MB per file, configurable in site settings) apply; any file exceeding Jira limits is flagged with a reference URL pointing to the source file.

Meegle automations with triggers (task status changes, field updates) and actions migrate as configuration, not executable code. We deliver a written inventory of every active Meegle automation rule with its trigger, conditions, and actions, mapped to a recommended Jira Automation rule structure. The customer's admin rebuilds the automation in Jira Automation for Jira Cloud. Automations tied to Meegle-specific integrations (e.g., GitHub, GitLab) require a separate re-integration step in Jira with the Atlassian Marketplace app for those tools.