Migrate from Rocketlane to Jira

Rocketlane Projects map directly to Jira Projects as the top-level container. We preserve project name, description, start date, end date, and status. Each Rocketlane Project becomes a Jira Project with a corresponding project key (e.g., RL-PROJ-001 maps to a Jira project with key PROJ). We configure Jira project type (team-managed or company-managed) during scoping based on the customer's scale and need for shared scheme configurations.

Rocketlane Phases require a two-path resolution strategy. If a Phase has a defined time-box (start and end date within the project timeline), we map it to a Jira Sprint. If a Phase represents a logical grouping without time-boxing (e.g., Discovery, Design, Build), we map it to a Jira Epic with child Stories and Tasks. The Phase name becomes the Sprint name or Epic summary. Phase dependencies (Phase B starts after Phase A completes) do not automatically create Jira Sprint dependencies — we document the sequencing so the customer's Jira admin configures Sprint-to-Sprint links or Epic predecessor relationships post-migration.

Rocketlane Tasks map to Jira Issues. During scoping we define the mapping rule: tasks with no estimate typically become Jira Tasks; tasks with story-point estimates become Jira Stories; tasks flagged as bugs become Jira Bugs. Assignee, due date, priority, description (markdown), and checklist items (Rocketlane subtasks are checklist items, not distinct records) migrate to the equivalent Jira Issue fields. Status mapping follows the Rocketlane-to-Jira status category table (To Do → To Do, In Progress → In Progress, Completed → Done).

Rocketlane custom fields (TEXT, MULTI_LINE_TEXT, YES_OR_NO, DATE, SINGLE_CHOICE, MULTIPLE_CHOICE, SINGLE_USER, MULTIPLE_USER, RATING, NUMBER) map to Jira custom field types with equivalent data representation. SINGLE_USER and MULTIPLE_USER migrate to Jira User Picker (single/multi) fields with owner resolution. RATING migrates to Jira Number field or a custom Jira Marketplace field type if the customer licenses one. We enumerate all workspace-level custom field schemas during scoping and pre-create the destination fields before task migration begins.

Rocketlane team member records (name, email, role) map to Jira Users. We match by email against the destination Jira site's user directory. Guest or inactive Rocketlane accounts are flagged for exclusion or Jira access-level decisions during scoping. Rocketlane Client records (external stakeholders with portal access) do not map to Jira Users directly — we flag them for the customer's admin to configure as Jira project roles with email-based access if client-facing visibility is required.

Rocketlane Clients are external stakeholders with dedicated portal access and project-level visibility. Jira has no native client portal concept. We map Client records to Jira project roles (Viewer or Member) with the customer defining which projects get external access. For teams that need a document-sharing and status-update workspace, we recommend mapping Rocketlane Spaces to a shared Confluence Space with the client as a Confluence external user — this is documented in the handoff deliverable but requires separate Confluence licensing.

Rocketlane Documents are rich-text objects with panels, tables, approval workflows, and freeze states. They cannot export as structured content — Rocketlane Documents export to PDF only. We extract the document body as raw text, attempt to rebuild structural elements (panels, tables, sections) in markdown, and place the reconstructed content in the Jira Issue description field for Tasks that correspond to document-linked tasks. Approval history, freeze state, and comments do not transfer. Standalone Documents without a linked Task are migrated as Jira Attachments (if a file format is available) or documented for manual recreation.

File attachments on Rocketlane Tasks and Documents download via the Rocketlane API and re-upload to the corresponding Jira Issue. Filename, file size, and file type are preserved. We map Rocketlane task-attached files to Jira Issue attachments by resolving the task-to-issue mapping at upload time. Files exceeding Jira's attachment size limits (10 MB default on Cloud) are flagged for the customer's admin to host externally and link.

Rocketlane Time Entries (available on Premium and Enterprise tiers) map to Jira Issue Worklogs. We preserve hours logged, date of entry, billable/non-billable flag, and description. The Jira Issue key is resolved from the Rocketlane task mapping before worklog import. Time entry attribution (which team member logged the time) resolves to the Jira User via email match. Jira requires the Log Work permission on the target project; we coordinate with the customer's Jira admin to grant this before worklog migration.

Rocketlane project templates and document templates define reusable project blueprints. Template content migrates as documentation of the original structure (phase names, task lists, default assignees, pre-populated fields) rather than as executable Jira objects. We deliver a template migration note with recommended Jira project templates, Issue Type Schemes, and Jira Automation rules that replicate the source template logic. Template-level default assignees and phase pre-population require manual reconfiguration in Jira.

Rocketlane automations are plan-gated (Standard includes automations, Premium adds unlimited automations, Enterprise adds form automations) and do not migrate as executable code to Jira Automation. We audit every active automation rule during scoping, document its trigger (e.g., task status change, due date approaching, phase completion), conditions, and actions, and deliver a written inventory recommending the equivalent Jira Automation rule (Jira's native automation engine is free on all tiers). The customer's Jira admin rebuilds automations post-migration using our documented trigger-action mapping.

Rocketlane Spaces provide the client-facing workspace within a Project, combining a shared timeline, document library, and activity feed. Jira has no equivalent client portal. We map Space structure and membership to either a Confluence Space (for document collaboration and status pages) or Jira project roles with external email access. This is a configuration decision made during scoping and documented as a post-migration configuration task.