Migrate from Taskworld to Jira

Taskworld Workspaces map to a Jira Site containing one or more Jira Projects. We extract workspace-level member lists, organization metadata, and workspace settings during scoping. If multiple Taskworld Workspaces exist, we design a Jira project-per-workspace or consolidate into fewer Jira projects depending on the customer's team structure. Workspace-level billing and administration settings do not migrate and are superseded by Jira site administration.

Taskworld Projects map directly to Jira Projects. We preserve project metadata including name, description, start date, and the display view preference (Kanban, Timeline, Calendar). Each Jira Project requires an Issue Type Scheme and a Workflow Scheme configured before migration; we deploy these via the Jira REST API or by submitting them through the customer's Jira admin during schema preparation.

Taskworld Tasks map to Jira Issues with the Issue Type determined by task attributes. Tasks with a checklist-driven compliance structure and photo evidence may map to Jira Stories or custom Issue Types depending on the customer's issue type scheme. We preserve summary, description (migrated as Jira Comment for rich text or as the Description field), assignee, reporter, due date, priority, and status. Task subtasks map to Jira Subtask issues linked to the parent Issue.

Taskworld custom fields are scoped per-project, meaning the same attribute must be re-created in each destination project. We extract all project-level custom field definitions from Taskworld and create them as globally scoped Jira custom fields via the Jira REST API or by providing field creation instructions for the customer's Jira admin. Field type mapping: Taskworld text fields map to Jira Text Field or Free Text Field; dropdown fields map to Jira Select List; date fields map to Jira Date Picker; number fields map to Jira Number Field. If Jira already has a global custom field of the same name and type, we use the existing field rather than creating a duplicate.

Taskworld task dependency links (blocks/blocked by) map to Jira Issue Links. We extract the directional dependency relationship and create the equivalent Jira Issue Link type (Blocks or Is blocked by) during migration. If the destination Jira project does not have Blocks link type enabled, we add it to the project's Issue Links configuration. Dependency chains spanning multiple tasks are preserved as a sequence of individual Issue Links.

Taskworld checklist items are sub-objects of tasks. We migrate each checklist item as a Jira Subtask under the parent issue, or alternatively as a Jira-native checklist-style custom field if the customer prefers a flat task structure. The completion status of each checklist item is preserved as the Subtask status. Nested checklist hierarchies are flattened to a single level unless the destination Jira project has Subtask nesting enabled.

Taskworld file attachments migrate to Jira as issue attachments. Files are downloaded from Taskworld and re-uploaded to Jira via the Jira REST API. Jira Cloud limits attachments to 250MB per file and 2GB per issue. We skip files exceeding these limits and provide a manifest of skipped files with URLs for manual handling. Photo evidence captured in Taskworld's audit and inspection feature migrates as standard attachments linked to the relevant issue.

Taskworld task comments and project chat messages migrate as Jira Comments. We extract comment text, author attribution (mapped to Jira user by email), and timestamp. Thread structure is preserved where Jira Comments support threading. Project chat messages are flattened and attached to the relevant issue as comments ordered by timestamp. Chat history is only available on Business and Enterprise plans and may not include the full historical archive if the retention window has passed.

Taskworld tags and labels migrate to Jira Labels. We extract the tag string from each Taskworld task and apply it as a Jira Label on the corresponding issue. Tag hierarchy, if present, is flattened to a single-level label set. Jira Labels are project-scoped by default but can be made site-wide by the Jira admin.

Taskworld workspace members and guest collaborators map to Jira Users. We resolve each user by email against the destination Jira site's user directory. Taskworld Business plan guests (up to 30) have limited workspace access that maps to Jira project-level roles (Viewer or Contributor) rather than site-wide access. The customer's Jira admin provisions any missing users and assigns them to the appropriate permission scheme before migration. Users deactivated in Taskworld are created as inactive Jira users to preserve historical assignment attribution.

Taskworld automations trigger actions based on task events (status change, due date, assignment). Jira Automation for Jira uses a different rule model with triggers, conditions, and actions that are not structurally compatible with Taskworld automation logic. We do not migrate automations as code. We deliver a written inventory of every active Taskworld automation rule with its trigger event, conditions, and actions, mapped to the recommended Jira Automation for Jira equivalent. The customer's admin rebuilds these in Jira post-migration.