Migrate from InLoox to Jira

InLoox Projects map directly to Jira Projects as the top-level container. We extract project name, description, status, start and end dates, and project-level custom fields during discovery. Jira Projects must be created before any issues load, and the Jira project key (e.g., PROJ) becomes the prefix for all issue keys in that project. Teams with multiple InLoox projects typically create multiple Jira projects, though Jira's Shared Filters and Dashboards can surface cross-project reporting.

InLoox Phases are sequenced sub-containers within a project that carry ordering and milestone flags. Jira does not have a native phase object; we map phases to Fix Versions (Jira's release management object) when they represent time-ordered releases, or to a single-select or text custom field (Phase__c) when they represent process stages within a project. Milestone flags from InLoox migrate to Fix Version released=true or to a Milestone__c checkbox field. Phase ordering is preserved by setting the Fix Version release date or ordering the custom field values alphabetically. If phases are used differently across projects, we apply the mapping strategy per project during discovery.

InLoox Tasks map to Jira Issue records. The mapping to Jira Issue Type (Task, Story, Bug, Epic) is determined during scoping based on task content and project context; tasks with acceptance criteria map to Story, development tasks map to Task, and defect-tracked tasks map to Bug. We preserve the InLoox task description, due date, priority, assignee, and completion status as Jira summary, due date, priority, assignee, and status. Sub-task hierarchy is preserved by creating Jira Subtask issues with ParentLink to the parent Jira issue.

InLoox subtasks flatten to Jira Subtask issue type with the ParentLink pointing to the parent Jira issue resolved from the InLoox task hierarchy. Each subtask carries its own assignee, due date, status, and checklist completion state. Jira Subtasks do not have their own Fix Version; they inherit the parent's Fix Version, which is resolved at migration time by lookup from the parent task's Jira issue ID.

InLoox resource assignments on tasks and projects map to Jira User records. We extract every InLoox user reference (resource name, email, assignment percentage) and match by email against the Jira destination project's user list. Unmatched users go to a reconciliation queue for the customer's Jira admin to provision before record import resumes. Jira assigns issues to users by issue Assignee field; the migration user must have the Jira Administrator or project-level Edit Issues permission for bulk assignment.

InLoox time entries (date, duration, user, description, billable flag) map to Jira Work Logs on the target issue. Billable status from InLoox maps to a custom field billable__c on the Jira issue or to a Tempo Timesheets custom field if the customer licenses that app. Hourly rate from InLoox is preserved in a custom field billable_rate__c because Jira does not natively model billing rates in work logs. Work logs are loaded after issues are created to satisfy the parent issue requirement, and we set started and timeSpent on the Jira Worklog object directly via REST API.

InLoox document links (SharePoint Online URLs, file server paths) migrate as Jira issue attachments by URL or as Jira remote issue links pointing to the original document. File content migration depends on the destination configuration: SharePoint Online links are preserved as remote links, and file server paths are flagged for the customer's admin to update to a Jira-compatible storage location post-migration. InLoox attachment URLs with expiry dates require manual re-authentication after migration.

InLoox budgets and budget lines have no direct Jira equivalent. We map budget total and line items to Jira custom fields (Budget__c as currency, Budget_Lines__c as a Jira Issues macro or custom app like Structure PPM if the customer licenses one). Probability, impact, and financial fields from InLoox risk records map to Jira custom fields or to the target project's custom fields. We flag any budget or risk field that cannot map cleanly to a Jira field type in the migration scope document for the customer's admin to configure post-migration.

InLoox risk management objects carry title, description, probability, impact, and status. We map these to Jira custom fields on the project issues (Risk_Probability__c, Risk_Impact__c, Risk_Status__c) or create a dedicated Risk issue type in the project if the customer requires risk records as standalone issues. Probability and impact numeric values migrate directly; status maps to a Jira custom field or label if no dedicated risk issue type exists in the target project.

InLoox Gantt task dependencies (predecessor and successor relationships) and date ranges migrate as Jira Issue Links (Blocks, Is Blocked By, Dependency) and as the Jira issue due date field. We extract every predecessor-successor pair from InLoox and create the corresponding Jira issue link during issue import. Jira does not natively support Gantt chart visualization, so teams needing Gantt views post-migration require a Jira Marketplace app (Structure, BigGantt) that we flag in the post-migration handoff document.

InLoox Kanban column definitions (project-specific column names and card positions) migrate as Jira Board configuration. We extract column names from InLoox and create a Jira Kanban board with matching columns mapped to Jira status categories (To Do, In Progress, Done). Card position order is preserved by setting the Jira issue priority or using a positional custom field; Jira's native ranking (Issue Rank or the older rank field) is set during migration to maintain relative ordering.

InLoox inline checklists on tasks store each checklist entry with its completion state and parent task association. We map each checklist entry to a Jira Subtask if Jira subtasks are desired as visible issues, or to a custom field (Checklist__c) as a text list if the customer prefers a lightweight representation. The completion state of each checklist item is preserved in the Jira representation; Jira subtasks carry their own status (To Do / Done) while checklist custom fields preserve state as a formatted text string.