Migrate from RoboHead to Jira

RoboHead Projects map directly to Jira Projects. Each RoboHead projectId becomes a Jira Project with projectKey derived from the RoboHead project name (sanitized to uppercase alphanumeric). Project status (active, draft, archived) maps to Jira Project status via the Jira Projects API. Projects that were created from Templates are flagged as isTemplate=true during extraction and mapped to standard Jira Projects with a custom field rh_template_source__c set to the original template ID for manual review.

RoboHead Campaigns are top-level organizational units that group related Projects. We map each Campaign to a Jira Epic within the destination Jira Project, using campaignId and campaignName from the RoboHead API. If no Jira Epic exists, we create one before importing linked Projects. The Epic description carries the Campaign's summary. Campaign-to-Epic mapping is the highest-dependency link in the migration graph; we resolve this before Projects import to avoid orphaned project references.

RoboHead Requests are intake forms submitted before a Project is created. Each Request carries a form type, requester metadata, and ListColumns representing custom brief fields. We map Requests to Jira Issues of type Story (for structured creative briefs) or Task (for action-oriented requests). Custom ListColumn fields migrate as Jira custom fields of the corresponding type (text, date, select, multi-select). Requester metadata becomes the Issue reporter or a custom field rh_requester__c.

RoboHead Tasks belong to Projects and carry status, assignees, due dates, and role associations. We map Tasks to Jira Issues of type Story (top-level deliverables) or Subtask (nested work items). Assignee resolution uses email matching against Jira User records. Status mapping requires a status-to-status translation table because RoboHead status values (e.g., Not Started, In Progress, Submitted) do not map 1:1 to Jira workflow statuses. Due dates migrate directly as Due Dates on Jira Issues.

RoboHead Users have email, name, role assignments, and optionally user-level billing rates. We map each User to a Jira User account by email. Any RoboHead User referenced in Tasks or Projects without a matching Jira account enters a reconciliation queue for the customer's admin to provision. Role assignments (Designer, Writer, QA) migrate as Jira Project Role memberships and optionally as Labels on Issues for reporting purposes.

RoboHead Task Roles are organizational categories for work types (e.g., Designer, Writer, QA) with optional billing rates attached to the role rather than individual users. We map role names to Jira Project Roles (if the Jira project uses a role scheme) or to Label values on Issues (for filtering and reporting). Role-level billing rates have no Jira native equivalent; we document them as a separate rate-card export for the customer's billing team.

RoboHead custom fields on Projects, Campaigns, and Requests use the ListColumns API with optionIds for list-type fields. RoboHead requires callers to first call GetAllFields to retrieve field identifiers before those fields can be populated in Add or Update operations. We discover all active custom fields and their option lists during scoping, bake the ID-to-name mapping into the transform layer, and create equivalent Jira custom fields with matching types (text, date, select, multi-select) before any record import. optionIds are resolved to display values during transform so records write with correct option references in Jira.

File attachments on RoboHead Tasks and Projects are stored in RoboHead's document management layer. We migrate file references and re-attach files to the corresponding Jira Issues via the Jira Attachments API. Attachments with null filenames (a known RoboHead edge case) are flagged separately because Jira does not accept null filenames; the customer's admin resolves these in RoboHead before migration begins.

Notes on RoboHead Projects and Tasks support @mentions and are stored as structured objects. We map Notes to Jira Comments on the corresponding Issues. @mention user references from RoboHead are converted to @-mention format in Jira Comments. If the mentioned user does not have a Jira account, the mention text is preserved as plain text without an active link.

RoboHead Projects can be saved as templates, optionally copying tasks, files, budget details, and team structure. When a Project is created from a Template in RoboHead, role assignments and team member links are copied from the template and may reference inactive or removed users (orphaned references). We detect template-derived Projects during migration, flag any orphaned user references, and set a custom field rh_template_id__c on the Jira Project record so the customer's admin can review and reconfigure team assignments post-migration.