Migrate from Runrun.it to Jira

Runrun.it Projects map directly to Jira Projects. The Project name, description, start date, and end date migrate as Project metadata. We create Jira Projects in the destination instance before any Issue migration so that parent-project references are satisfied at insert time. Jira Projects require a Project key (e.g., PROJ) that is derived from the Runrun.it project name if not pre-configured by the customer's admin.

Runrun.it Tasks map to Jira Issues. We assign Issue types based on Task metadata: Tasks with bug-related labels or status indicators map to Jira Bug; Tasks marked as deliverables or user-facing work map to Jira Story; general work items map to Jira Task; and epics or top-level milestones map to Jira Epic. The Runrun.it task priority, due date, estimated hours, and actual hours migrate to Jira Priority, Due Date, and custom time-tracking fields. The Kanban stage name becomes the initial Jira status by resolving it against the destination Project's Workflow statuses.

Runrun.it Kanban stages are free-form and configurable per Project. Jira Workflow statuses are defined per Project and Issue type combination. We inventory every distinct stage name across all Runrun.it Projects during discovery, map each to a corresponding Jira status (To Do, In Progress, In Review, Done, Blocked), and configure the Jira Workflow with matching transitions before Issue migration begins. Stages that have no Jira equivalent go to a reconciliation list for the admin to define.

Runrun.it time entries track date, duration, and optional notes against Tasks. Jira stores worklogs on each Issue via the worklog field or in the Logs tab. We migrate time entries as Jira worklog entries linked to the parent Issue, preserving date, duration, and description. If Jira's native worklog is insufficient for billing workflows, we create custom fields (Time Entry Date, Duration, Billable flag) during schema setup and populate those instead. Duration rounding is explicit: we convert Runrun.it's duration format to Jira's time-tracking units to avoid silent rounding differences.

Runrun.it's two-step document upload requires us to POST to the document creation endpoint first, then push the file to the returned Amazon S3 presigned URL. We handle both steps during migration. The file is downloaded from S3, re-uploaded to Jira as an Issue Attachment via the Jira REST API, and linked to the parent Issue. If the S3 bucket credentials are unavailable or expired, we flag the document record as broken-link and deliver a list of unresolved attachments for the customer to re-upload manually.

Runrun.it Users with roles, email addresses, and hourly rates map to Jira Users. We resolve Jira Users by email match against the destination instance's user directory. Any Runrun.it User without a matching Jira User is placed in a reconciliation queue for the customer's Jira admin to provision before record migration resumes. Hourly rate maps to a custom field on the User record if billing visibility is required in Jira.

Runrun.it custom fields on Tasks use field_label in the API and are configurable per Project. We migrate custom field definitions and values as Jira custom fields of equivalent type (text, number, date, select, multi-select). Jira Cloud requires custom fields to be created in the destination instance before data import; we create them via the Jira REST API before migration and map field values per Issue. Custom fields that do not map to a Jira field type (e.g., complex structured data) are stored as JSON in a text custom field and flagged for the admin's review.

Runrun.it tags_data arrays on Tasks map to Jira Labels. Labels are added to Issues via the Jira Labels REST API during migration. Jira Labels are project-scoped by default; we apply labels consistently across Issues regardless of project context so that the tagging taxonomy from Runrun.it is preserved. Jira's label storage limit is respected per Issue.

Runrun.it attachments of type URL (link-based, not file-based) migrate as Jira remote issue links via the remotelinks API endpoint. The attachable_type and attachable_id relationship is preserved by linking the remote URL to the correct Jira Issue. If the remote URL is inaccessible at migration time, the link is logged as broken and delivered in a remediation list.

Runrun.it comments are attached to Tasks. The API documentation does not expose a dedicated Comments endpoint, so we verify comment accessibility during discovery scoping. If comments are accessible via the Tasks endpoint or a related sub-resource, we migrate them as Jira Comments on the corresponding Issue, preserving author, timestamp, and body text. If comments are not accessible via API, we flag this gap in the discovery report and the customer decides whether to export manually or skip comment migration.