Migrate from LiquidPlanner to Jira

LiquidPlanner organizes all data under a Workspace containing Projects, Members, and Settings. Jira has no Workspace equivalent; we map each LiquidPlanner Workspace to a Jira Site (for multi-org strategies) or to a top-level Jira Project. Workspace-level custom fields migrate as project-level custom fields in Jira. Workspace-level settings (billing rates, timesheet approval rules) do not have direct Jira equivalents and are flagged in the pre-migration configuration document for the customer's admin to configure in Jira or a compatible app like Jira Tempo.

LiquidPlanner Projects map 1:1 to Jira Projects. We preserve the project name, baseline dates, project status (Active, On Hold, Completed), and any project-level custom field values. Jira Project key (e.g., PROJ) is derived from the LiquidPlanner project name abbreviation or assigned by the customer during scoping. Project hierarchy (parent-child projects) maps to Jira's project hierarchy feature available in Jira Premium and Enterprise.

Packages are grouping containers within a LiquidPlanner Project, similar to a high-level phase or initiative. We map them to Jira Epics when the destination project uses the Scrum issue hierarchy (Epic > Story > Task > Sub-task). When the destination uses a Kanban configuration, Packages map to Jira Components with the component Owner field set to the package lead if available. Custom field values attached to the Package migrate to the Epic's custom fields.

LiquidPlanner Tasks are the core work items and map to Jira Issues. We map task name to Summary, task description to Description, and the lower bound of the LiquidPlanner range estimate to the Jira Start Date with the upper bound as Due Date. Tasks with no range estimate (fixed-duration tasks) map to Jira with a single Due Date and no Start Date, or with a Start Date set manually by the customer's PM. Tasks with multiple assignees are flagged for the 1:N split: each assignee receives a separate Jira issue with a reference note to the source multi-owner task. Custom field values migrate to equivalent Jira custom fields.

LiquidPlanner Sub-Tasks map to Jira Sub-task issues within their parent issue when the destination Jira project has sub-tasks enabled. If the destination project uses a flat issue hierarchy (Story and Task only, no Sub-task), we flatten Sub-Tasks into checklist items within the parent issue Description using a structured format (e.g., '- [ ] Sub-task name'). The customer chooses the hierarchy approach during scoping based on their Jira project configuration.

LiquidPlanner finish-to-start, start-to-start, and custom wait-day dependencies map to Jira Issue Links. We create Blocks and Is Blocked By links between the relevant Jira issues. Start-to-start dependencies in LiquidPlanner have no direct Jira equivalent; we convert them to a Jira Blocks relationship and add a note on the blocking issue indicating the start-date dependency. Wait days are preserved as a comment on the blocking issue. Long dependency chains are flagged individually because LiquidPlanner's automatic rescheduling behavior will not replicate in Jira's static-date model.

LiquidPlanner Milestones are zero-duration tasks with a target date. We map them to Jira Issues with the type set to Epic or to a standard Jira Issue with a Milestone label, depending on the customer's preference. The milestone name and target date migrate. Milestones that drive downstream dependencies via LiquidPlanner's scheduling engine are flagged for manual review because the auto-rescheduling logic will not carry over to Jira's static-date system.

Time tracking data — hours logged, billable vs. non-billable flags, billing rates, and approval status — migrates as Jira worklog entries on the corresponding issue. Billable status and billing rate are preserved as custom fields on the worklog if the destination Jira project has Tempo installed; otherwise, they are flagged for the customer's admin to configure post-migration. Individual time entries with notes migrate as worklog comments. Timesheet summary records do not have a Jira equivalent; we deliver a CSV export of timesheet summaries for the customer to use in billing reconciliation.

LiquidPlanner custom fields at the Workspace and Project level migrate to Jira custom fields of equivalent type (text, number, date, picklist, multi-select picklist). Custom field definitions (names, options, types) must be recreated in Jira before migration; we provide a Jira custom field creation guide based on the LiquidPlanner field inventory. Jira has field-level naming limits (255 characters) and option list limits; we flag any LiquidPlanner fields that exceed Jira's limits during scoping.

LiquidPlanner Members (email, name, role, billing rate) map to Jira User accounts. We resolve Members by email match against the Jira destination site's user directory. Any LiquidPlanner Member without a matching Jira User goes to a reconciliation queue for the customer's admin to provision before migration. Virtual Members (external clients or stakeholders without a full license) are flagged: they become full user accounts in Jira with an explicit note in their display name indicating they are a Virtual Member, or the customer chooses to import them as a Jira Contact instead.

File attachments on LiquidPlanner Tasks and Projects migrate as Jira attachments when the destination Jira site has sufficient storage. If Jira storage limits are a concern, we export attachments to a shared cloud storage location (Google Drive, Dropbox, or Box) and create Jira issue links pointing to the external files. This decision is made during scoping based on the customer's Jira storage allocation and attachment volume.

LiquidPlanner's priority ranking (numeric or named priority tiers) maps to Jira Priority values (Highest, High, Medium, Low, Lowest). If LiquidPlanner uses a custom priority scale (e.g., 1-10), we map it to the nearest Jira Priority tier and preserve the original numeric value in a custom Jira field for detailed ranking within each priority band.