Migrate from Stackby to Jira

Stackby Stacks map to Jira Projects as the top-level organizational container. Each Stack becomes a standalone Jira project with its own issue type scheme, workflow, and permission scheme. We recommend creating Jira Projects in advance and selecting the project type (Team-managed or Company-managed) before migration because this determines the automation and field configuration surface area in Jira. Team-managed projects offer simpler administration; Company-managed projects allow cross-project dependencies and shared configurations.

A Stackby Table maps to a Jira Issue Type (Story, Task, Bug, or Epic) within a Jira Project. If a Stackby workspace contains multiple Tables representing distinct work types, each Table becomes its own Issue Type within the same Jira Project. We use the Table name as the Jira Issue Type name and configure the project's Issue Type Screen Scheme to display the appropriate fields. If a Table is referenced by another Table via linked columns, we map the relationship to Jira Issue Links (Blocks, is blocked by, Relates to).

Stackby Rows map directly to Jira Issues. The Row's primary text field becomes the Issue Summary. Row-level data in text, number, date, and select columns maps to Jira standard fields or custom fields we create in the destination project. Status column values from Stackby map to Jira Status (To Do, In Progress, Done) or to a custom status workflow if the customer has a multi-step process. Rows without a status assignment default to To Do in Jira.

Stackby text columns map to Jira Summary (if it is the primary name field) or to the Jira Description field. Jira requires a Summary field on every Issue; we use the first non-empty text column as Summary and consolidate additional text columns into Description with labeled sections. Rich text formatting in Stackby (if used) converts to Jira's Wiki Markup or plain text depending on the destination field configuration.

Stackby numeric columns (Number, Currency, Rating) map to Jira Number custom fields. We create a matching custom field in Jira during schema setup and map the Stackby column name to the custom field name. Currency symbols in Stackby Currency columns are stripped and the numeric value is stored; Jira does not support native currency fields in Jira Software, so a custom number field plus a note in the field description handles the semantic intent.

Stackby date and datetime columns map to Jira Due Date (if the column represents a deadline) or to a custom Date custom field. Jira's standard Due Date field renders in issue views and sprint boards natively. Datetime columns with time-of-day precision store in a custom datetime field since Jira's standard Due Date does not carry time. We set the Jira Due Date at migration time using the source column value; no date arithmetic is applied.

Stackby Select columns map to Jira single-select custom fields (Dropdown); Multi-select columns map to Jira multi-select custom fields (Multi-select). We pre-create the Jira custom field with the same label and populate the allowed values with the distinct options from the Stackby column during migration. Jira's field context determines which projects and issue types the custom field applies to.

Stackby Attachment columns migrate to Jira Issue Attachments via the Jira REST API. We download each attachment from Stackby's API and upload it to the corresponding Jira Issue. Jira imposes a 33MB per-file limit on attachments; we flag any attachment exceeding this during discovery and alert the customer to the truncation risk. Null-filename attachments in Stackby (a known issue in Jira migrations) are flagged and excluded from the migration with a note in the reconciliation report.

Stackby formula columns compute values dynamically at render time. During migration, formula columns transfer as their current computed values — not as live formulas. Jira Software does not have a native formula engine equivalent to Stackby's column formulas. If the destination requires computed fields, we document the original Stackby formula expression and the customer rebuilds the logic in Jira using a marketplace app (like ScriptRunner or JQL Custom Fields) or accepts the static value. We flag every formula column during discovery so this is a conscious decision, not a silent data loss event.

Stackby system columns (Auto Number, Created By, Modified By) map to Jira Issue ID, Creator, and Reporter fields. The Jira Creator field is set at issue creation time using the Jira API; the migration service account serves as the Creator unless the customer provisions Jira user accounts matching the Stackby creator emails. We preserve the original Stackby creation timestamp in a custom field stackby_created_at__c for audit purposes.

Stackby view configurations (Kanban board grouped by a status column, Calendar view on a date column, Gallery view on an attachment column) are platform-native display settings that do not transfer to Jira. We document each view's grouping column, sorting, and filter configuration during discovery. Jira Boards (Scrum and Kanban) are configured manually in Jira based on the documented Stackby view structure. Jira's native Board requires a Jira project with an active sprint or kanban column configuration.

Stackby's Organization > Workspace > Stack hierarchy maps to Jira's site-level organization (Atlassian account or Jira site) and individual Projects. User accounts from Stackby map to Jira users by email match. We audit all Stackby workspace permissions during discovery and document the corresponding Jira project role assignments required post-migration.