Migrate from Resource Management by Smartsheet to Jira

Smartsheet Sheets are the primary project container and map directly to Jira Projects. We create Jira Projects in the destination Cloud or Data Center instance using the Jira REST API before any Issue migration. Each project gets a configured Issue type scheme that maps Smartsheet Row types (tasks, milestones) to the appropriate Jira Issue types (Story, Task, Epic). Sheet-level metadata (name, description, start date, end date) migrates to the Jira Project's Description and Jira's native Start date and Due date fields on the top-level Issue.

Smartsheet Rows map to Jira Issues. Row name becomes Issue Summary; Row cells become Issue fields. Parent-child Row hierarchies (subtasks within rows) map to Jira Subtask-Parent Issue relationships using Issue Links. Predecessor/successor dependencies from Smartsheet dependencies columns map to Jira Issue Links of type Blocks or Blocked By. Jira requires each Issue to have a valid Project and Issue Type, so we map the primary row type to the default Issue Type in the project's Issue Type scheme.

Resource Management People objects (name, role, email, availability) map to Jira User accounts. We match People by email against the Jira destination User directory. Allocation percentages per project from Resource Management are not a native Jira field, so we store them as a structured custom field (RM Allocation %) on each Issue after the assignee is resolved. Any Person without a Jira User account is added to a provisioning queue for the customer's Jira admin before Issue migration begins.

Each Resource Management Assignment links a Person to a Row with hours and allocation percentage. We map the assignee to Jira's native Assignee field and store the allocation hours as a custom Number field (RM Allocation Hours) and allocation percentage as a custom Number field (RM Allocation %) on the Issue. If a Person has multiple assignments across rows, each becomes a separate Jira Issue with the same assignee.

Smartsheet Phases are hierarchical groupings of Rows within a project. Jira has no native Phase concept. We offer two migration strategies during scoping: Phase as Jira Labels (one label per Phase name applied to all Issues within that Phase grouping) or a Phase custom Select field pre-populated with Phase names. The customer chooses based on whether they want Phase data filterable via JQL. Phase ordering is preserved by setting the earliest Row start date within the Phase as the Phase grouping anchor.

Resource Management Portfolios aggregate multiple projects with capacity and timeline summaries. Jira does not have a native Portfolio object, but Jira Premium includes Advanced Roadmaps (previously Structure) which supports multi-project views. We export the Portfolio's project list and key metrics (total hours, utilization percentage) as a structured CSV inventory for the customer's admin to configure in Advanced Roadmaps or a linked Confluence page. Portfolio dashboards are not replicated natively.

Smartsheet column types (Text, Date, Contact List, Dropdown, Multi-Select Dropdown, Checkbox, Number, Duration, Formula) map to equivalent Jira custom field types. We pre-create all custom fields in the destination Jira project before Issue migration. Contact List columns map to Jira User Picker; Dropdown maps to Jira Select; Multi-Select Dropdown maps to Jira Multi-Select. Formula columns are exported as their computed value and stored as read-only text fields in Jira since Jira does not support computed columns on Issues.

Smartsheet row-level predecessor/successor dependencies export as dependency relationships. Jira Issue Links of type Blocks and Blocked By carry the same information. We resolve the target Issue key for each dependency using the Row's position in the migrated project and create the link via the Jira Issue Links API. Cyclical dependencies (A blocks B, B blocks A) are flagged as a gotcha and broken into a single-direction link during migration.

Smartsheet Row-level Discussion and Comment entries migrate to Jira Issue Comments. Each comment thread from a Row becomes a chronological comment thread on the corresponding Jira Issue. Comment author maps to Jira User by email match; timestamp preserves the original date. Comments containing @mentions are preserved as plain text since Jira mention syntax differs.

Resource Management timer entries that are still editable (within the one-week lock window) are exported via CSV during discovery before migration begins. We import hours logged per assignment as a custom Number field (Hours Logged) on the Jira Issue and as a structured CSV handoff for the customer's admin to import into a Jira-compatible time tracking tool such as Tempo or the native Jira time tracking feature if enabled on the destination plan.