You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am setting up a new Orbit workspace because I want to leave Jira, Linear, or a spreadsheet. Orbit gives me a name, a default team, and a handful of starter issues. That is it.
I already have hundreds of tickets with statuses, labels, assignees, and dates. There is no way in the product to bring that work in. Analytics can export a filtered CSV of issues that are already here. A single doc can download as Markdown. GitHub pull requests can backfill. None of that helps me migrate onto Orbit.
The roadmap says getting off a paid tracker should take minutes. On current main, nothing a new admin can click does that.
What you do instead
Recreate issues by hand, or ask an agent to call createIssue one row at a time through MCP. Both are fine for a demo and useless for a real team. Most people stay on the old tracker.
Any thoughts on the shape
I do not want this to collide with the importer cluster that already exists.
#359 is the shared runner (dry-run vs apply, tenant-safe, blocked until designed). #127 is Linear parsing that never writes. #229 is Jira and GitHub Issues, closed until the runner exists. Those are operator / database jobs. This idea is the product door: a skippable step after workspace create, and the same flow later under Settings.
What feels right from using Linear and Jira:
Import first. Export and leave-Orbit backup can wait. Workspace deletion already deferred that.
One import = one team. A Jira project or Linear team maps to one Orbit team. Multi-team is the same job run again, not a zip that invents teams.
The person picks the destination team. Skip is allowed. Skip keeps today's starter issues. A confirmed import should not plant those on top of the migrated set.
Detect a Jira all-fields CSV and a Linear export. Everything else, including Excel, is a column mapper.
Preview, then confirm. Show counts, statuses and labels that would be created, unmatched assignees, skipped columns. Write nothing until confirm. No undo in a first version if the preview is honest.
Admin only after onboarding. Do not create users from an assignee column. Do not fire an inbox notification per imported issue.
I would rather this discussion decide whether the UI waits on #359, or whether a first in-app CSV apply is in scope once the runner's safety rules are agreed. I do not want a second write path beside ImportRows.
Prior art
Linear Settings → Administration → Import/Export. Admin only. Named assistants for Jira, GitHub, Asana, plus generic CSV. One Jira project into one team. Preview. Static copy unless Jira Sync was set up first. 7-day undo. CLI for sources without an assistant.
Jira External System Import for CSV, and Backup Manager for a whole-site dump. The dump is the leave path, not the arrive path.
Orbit already has Plane and Linear readers under packages/db/src/import/, plus issue_identifier_alias for keeping JIRA-1234 links. #287 removed the old runner because it was tenant-specific and destructive. That constraint should stay.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
What is painful today
I am setting up a new Orbit workspace because I want to leave Jira, Linear, or a spreadsheet. Orbit gives me a name, a default team, and a handful of starter issues. That is it.
I already have hundreds of tickets with statuses, labels, assignees, and dates. There is no way in the product to bring that work in. Analytics can export a filtered CSV of issues that are already here. A single doc can download as Markdown. GitHub pull requests can backfill. None of that helps me migrate onto Orbit.
The roadmap says getting off a paid tracker should take minutes. On current main, nothing a new admin can click does that.
What you do instead
Recreate issues by hand, or ask an agent to call createIssue one row at a time through MCP. Both are fine for a demo and useless for a real team. Most people stay on the old tracker.
Any thoughts on the shape
I do not want this to collide with the importer cluster that already exists.
#359 is the shared runner (dry-run vs apply, tenant-safe, blocked until designed). #127 is Linear parsing that never writes. #229 is Jira and GitHub Issues, closed until the runner exists. Those are operator / database jobs. This idea is the product door: a skippable step after workspace create, and the same flow later under Settings.
What feels right from using Linear and Jira:
I would rather this discussion decide whether the UI waits on #359, or whether a first in-app CSV apply is in scope once the runner's safety rules are agreed. I do not want a second write path beside ImportRows.
Prior art
Linear Settings → Administration → Import/Export. Admin only. Named assistants for Jira, GitHub, Asana, plus generic CSV. One Jira project into one team. Preview. Static copy unless Jira Sync was set up first. 7-day undo. CLI for sources without an assistant.
Jira External System Import for CSV, and Backup Manager for a whole-site dump. The dump is the leave path, not the arrive path.
Orbit already has Plane and Linear readers under packages/db/src/import/, plus issue_identifier_alias for keeping JIRA-1234 links. #287 removed the old runner because it was tenant-specific and destructive. That constraint should stay.
All reactions