Migrate from Spreadsheet.com to Jira

Each Spreadsheet.com Workbook maps to a Jira Project. We use the workbook name as the Jira Project key prefix and name. If the workbook contained multiple sheets representing distinct functional areas, we evaluate whether to split into multiple Jira projects or consolidate under one project with separate issue types per sheet. This decision is made during discovery based on the number of sheets, the presence of cross-sheet references, and how the team organized work in Spreadsheet.com.

Individual Sheets within a Workbook map to Jira Issue Types within a project. The sheet name becomes an Issue Type (or a label if the project uses a flat issue type scheme). If the sheet contained hierarchical rows (parent rows with child rows), we configure Jira's Epic > Story > Task > Sub-task hierarchy and map parent rows to the higher type. We also create a corresponding Jira Board for each sheet to preserve the team's Kanban or list-view working context.

Spreadsheet.com Rows map directly to Jira Issues. The row's primary identifier (typically the first column or a named ID column) becomes the Jira Summary field, which is required. If rows had a Status column with freeform text values, we map those to Jira Status values (To Do, In Progress, Done, or custom statuses defined in the project's workflow). Rows without a clear equivalent Jira status are set to the default start status with a note flagging the ambiguity for admin review.

Spreadsheet.com column type overrides (multi-select checkboxes, user picker, date, currency, formula output) map to Jira custom fields. Multi-select cells become Jira Labels or multi-select custom fields depending on usage. User picker columns become Jira User Picker fields, though user accounts cannot migrate directly since Spreadsheet.com had no user export mechanism; we document the usernames for manual provisioning. Date and currency columns map to Jira Date and Number fields respectively. Formula-computed cells flatten to their displayed text value; we flag these for the customer noting that the formula logic itself cannot migrate.

Spreadsheet.com Kanban view configurations (grouping column, swimlanes, card ordering) are not stored as exportable objects. We reconstruct the intended grouping from row data patterns — for example, if a sheet had a Status column with five distinct values displayed as Kanban columns, we configure a Jira Kanban board with those same columns and map the filter to the Status field. The reconstructed board is a best-effort configuration; the customer reviews and adjusts post-migration.

Spreadsheet.com Gantt view intent (start date, end date, duration, dependencies) reconstructs from row data if date columns existed. Jira's Roadmap and its issue-level Due Date and Start Date fields provide the basic Gantt equivalent. Full dependency arrows between issues require a manual review of which rows referenced other rows as dependencies, since Spreadsheet.com did not expose dependency columns as structured export fields. We flag this during discovery and produce a dependency map for manual Jira issue linking (Blocks, Blocked By, Relates To).

File attachments stored within Spreadsheet.com cells export as linked file references where available. We map these to Jira issue attachments, preserving original filenames. Spreadsheet.com's attachment storage is tied to the platform's shutdown, so any attachments not manually downloaded before May 31, 2024 are unrecoverable. We flag this clearly and document any partial attachment recovery from local backups.

Inline cell comments and sheet-level discussions export as text annotations. We append comment text to the relevant Jira Issue as a comment, preserving author attribution where the comment metadata was present in the export. If author attribution is absent, the comment is attributed to the migration service account with a note that the original author is unknown.

Spreadsheet.com Web Form submissions were stored as rows in the target sheet. We map form submission records to Jira Issues created via the Jira REST API or CSV importer, using the form field names mapped to Jira fields. Conditional logic defined in the form (field visibility rules, conditional validation) cannot migrate; we document the logic during discovery for the customer to rebuild using Jira Automation for Jira or a third-party form tool like Google Forms or Typeform.

Spreadsheet.com automation rules (triggers, conditions, and actions) were stored server-side with no user-facing export mechanism. At shutdown, no automation backup existed. We do not migrate automations as configured rules. During discovery, we interview the customer on their active automation logic and produce a written inventory describing each automation's trigger, conditions, and actions with a recommended Jira Automation for Jira equivalent. The customer's admin rebuilds these manually post-migration.

Spreadsheet.com user accounts and workbook-level permission sets are not exported via any shutdown tooling. We reconstruct the permission hierarchy from workbook sharing metadata where available — the list of email addresses with edit or view access. We map these to Jira Users (manual provisioning required) and Jira Project Roles (Administrators, Members, Viewers) or project-level permission schemes. Any permission configurations that cannot be determined from the export metadata are documented as gaps for the customer's admin to resolve.