Import from another tracker
A one-time move of a whole list into tasks Peractor owns, for a team migrating off.
Connecting a tracker mirrors it: the list is read again every thirty seconds and Peractor's copy follows.
An import is the other thing — a one-time move of a whole list into tasks that Peractor owns, for a team migrating off the tracker. The source is left exactly as it was.
Connect, sync, import
- Connect is the relationship: authorizing a tracker for the organization, and telling a project which of its lists to follow.
- Sync is the traffic on it — issues arriving, statuses written back.
- Import is a move. It needs the organization's authorization and nothing else: a project can import a list it never connected, and connecting a list never imports it.
Where
On the board it fills. Settings → Peractor Tracker → Import on the phones and the Mac, Settings → Import on the dashboard, the desktop app, and the editor.
Admins only, and only while Peractor's own tracker is on — with it off there is nowhere for the tasks to land. Pick the tracker, the account when there is more than one, then the list: a Linear team or project, a Jira project, a repository, a GitHub Project, a Notion database, a Slack channel.
Read first, then start
Nothing is written until you have seen what will be. Reading the list answers with a plan:
- How much — issues found, and how many comments, attachments with their total size, sub-tasks, and relations come with them. On a second run, how many are already here and will be skipped.
- Where each status lands — every source status with the Peractor status it maps to: by the tracker's own category where it states one, by name where names match, otherwise the backlog. Change any row. A project with no statuses yet is offered the source's workflow as its own.
- What gets created — labels for tags that have no label here yet, and milestones for the source's projects, versions, or milestones.
- What will not come, said plainly — a parent outside the list, a relation to an issue that is not moving, a sprint with no cycle here to land in, a name that is not a member's.
Start import runs the move on the server. It keeps going if you close the page or put the phone down, every surface draws the same progress bar, and Stop keeps what has been written so far.
What comes across
Everything Peractor's tracker can hold. Each imported task gets a Peractor key, minted in the source's creation order, and every field is editable:
- Title and description, status through the plan's map, priority, assignee, labels, estimate, due date.
- Created, started, and completed dates — so a task that is years old says so.
- Comments with their dates and one level of replies; attachments copied into Peractor, so the tracker can be switched off. One over the upload cap stays a link, and the result says how many.
- Parents and sub-tasks, relations between issues in the list, milestones by name, and the sprint or cycle whose dates match a cycle here.
- The old handle: the source key and link stay on the task, so
ACME-12still finds it in search, and the detail says where it came from.
How deep each tracker goes: Linear and Jira bring all of the above; GitHub Issues brings comments, images, dates, milestones, and sub-issues; GitLab brings notes, attachments, weight, due dates, milestones, iterations, and links; GitHub Projects brings the board's issues with the Status field as status; Notion brings the mapped properties and comments; Slack brings the message, its thread as comments, and its files.
Pull requests are not importable — a pull request is a change, not a request for one. See GitHub for the pull request inbox instead.
Running it twice
An import is safe to repeat. A second run of the same list skips every issue already imported into this project and brings what arrived since, so a gradual move needs no mode of its own.
Where a list is both connected and imported, its synced rows are converted in place — same task, so runs, comments, and relations survive — and sync skips them from then on.
Undo
An earlier import can delete what it created, from the same screen. Tasks it converted stay, because they were here before and their runs may have been. The source tracker is never written to: no comment, no status, no close.