Migrate from MeisterTask to Jira

MeisterTask Projects map 1:1 to Jira Projects. Project name, description, color, and member list migrate directly. We set the Jira project template to the Scrum or Kanban template during project creation, depending on the source project's use of sprints versus continuous flow. The project lead maps to the Jira Project Lead role.

MeisterTask Sections (Kanban columns) map to Jira status column names within the project's default issue type's workflow. If the source project uses fewer than six sections, we map each to a named status in Jira. If sections represent categories rather than workflow stages (e.g., Bug, Feature, Support), we map them to Jira Labels or to Components. Section order is preserved as the column sequence in the Jira board view.

MeisterTask Tasks map to Jira Stories by default, or to Jira Tasks if the source task represents a standalone action item without a deliverable. We map task title to Summary, description to Description (migrated as Jira's rich text renderer), due date to Due Date, and status (active/completed/archived) to the corresponding Jira status value. Task ID is preserved in a custom field mtask_id__c for traceability back to the source.

MeisterTask enforces one assignee per task. Jira supports one Assignee and multiple Watchers. If the source account used tagging or comments to simulate multi-ownership (a common workaround noted in G2 reviews), we surface those patterns during scoping and give the customer the option to convert the primary assignee to Assignee and secondary owners to Watchers in Jira. Owner resolution is by email match against the Jira User directory.

MeisterTask Tags are project-scoped labels. We migrate them as Jira Labels by default, which are project-scoped and searchable across issues. If tags represent ownership or categorization across the entire project (e.g., frontend, backend, design), we offer Component mapping instead. The customer selects the strategy during scoping based on how the tag set is used operationally.

MeisterTask Business-tier custom fields (text, number, date, dropdown, checkbox) map to Jira custom fields of the equivalent type. Jira's custom field schema is defined before migration using the Jira REST API. Dropdown fields in MeisterTask become Jira Select (single choice) or Multi-Select fields; checkbox becomes Jira Checkbox. If the source account is Free or Pro with no custom fields, we skip custom field extraction and note the absence in the migration report. Project-level custom field schemas are applied per Jira project during configuration.

MeisterTask time entries (logged hours attached to tasks) map to Jira Worklog records. We preserve the original time value, the date logged, and the author. Jira Worklog visibility follows the project's permission scheme. Time tracking must be enabled in the Jira project settings before migration; we configure this as part of the destination schema step.

MeisterTask recurring tasks have a recurrence pattern (daily, weekly, monthly, custom) stored per task. Jira has no native recurrence model. We extract the recurrence pattern, convert it to a Jira Automation scheduled rule (trigger: scheduled, frequency matching the original), and document it in the automation inventory delivered post-migration. We do not create the rules as code in the migration scope; the customer's Jira admin implements them from the documented specification.

MeisterTask task comments migrate to Jira Issue Comments with author, timestamp, and body preserved. Rich text in MeisterTask comments is converted to Jira's wiki-markup or stored as plain text. Author attribution maps via email match to the Jira User directory. If a comment author has no Jira account, the comment is attributed to the migration service account with a note in the report.

MeisterTask file attachments are downloaded with their original filename and metadata, then uploaded to the corresponding Jira issue as Jira-native attachments. URL-based attachment links in MeisterTask are preserved as hyperlinks in the Jira issue Description field since Jira does not store external URL attachments as first-class files. Attachment size limits in Jira Cloud (max 10MB per file on Standard) are enforced; files exceeding this threshold are flagged for the customer to store in Confluence or a linked file storage service.

MeisterTask blocking and waiting relationships between tasks map to Jira Issue Links (blocks / is blocked by). We extract the relationship edges from the source API, resolve the target Jira issue keys post-migration, and create the link records via the Jira Issue Links API. Cyclic dependencies are detected and flagged for the customer to resolve before link creation.

MeisterTask Notes (powered by MeisterNote) are project-scoped documents. Short notes are merged into the Jira issue Description field. Longer or structured notes are migrated as Jira issue comments with a note tag, or optionally as Confluence pages linked from the Jira issue if the destination includes Confluence. We inventory all notes during scoping and apply the strategy per note length threshold agreed with the customer.