# One import, then Retasc is the queue > The import runs once and never writes back: what comes across from Linear, Jira, ClickUp, Asana and Shortcut, what stays, and how to export it all again. Source: https://retasc.com/migrate · Markdown for agents; the same page as HTML with the diagrams described in a line each. [Connectors](https://retasc.com/connectors) Retasc reads your old tracker once, at the moment you import, and never writes back. This page is the whole story: what comes across, what stays behind, and how to get everything out again if you change your mind. Updated September 2026 · 5 min read ## It runs once, and it runs one way Importing is a copy, not a connection. Retasc pulls your issues at the moment you run the import and then stops looking. It never reads the source again, never writes to it, and never reconciles the two. From that point the two are separate systems: Retasc is where the work is dispatched, and the old tracker is a frozen copy of the day you left. That is a deliberate choice, not a gap we intend to close. Two-way sync means owning a conflict rule across two different status models, deciding who wins when both sides edit, and suppressing the echo loops that follow. It is a permanent cost paid by every team so a few can keep a second tracker alive. *Diagram: The import is one directional and happens once* GitHub is the one source Retasc writes to, and for a reason that does not apply to a tracker you are leaving: it is where outside contributors file. Point a repo at Retasc and its issues and pull requests sync in as work. When an agent marks a synced issue done or canceled, Retasc closes it with a state reason. A synced pull request only closes back when its work is canceled, a done PR is left for a human to merge, and it already carries a comment from when it came in. An imported backlog has no such path, and is not meant to. ## What comes across Paste your own API key in the Dash, pick a target (a Linear team, a Jira project, a ClickUp list, an Asana project, a Shortcut group), map the source columns onto Retasc statuses, and run it. Each target becomes a Retasc project. Your agent can run the same import over MCP. *Diagram: What the import brings over* Identifiers survive where the source has real ones. Linear, Jira and Shortcut number their issues, so `ENG-42` stays `ENG-42` and every link you have written down still resolves. ClickUp and Asana use opaque ids, so Retasc assigns fresh numbers in the same order. Your source key is passed straight to the import run, lives in memory for the length of that run, and is never written to a table or a log. Revoke it in the old tool once the import finishes. ## What stays behind Retasc models a dependency-ordered queue, not a project-management suite, so the concepts that only exist to organise humans are not read at all. From Linear that means milestones, cycles, initiatives, estimates, SLA fields, the archive, git branch links, source URLs and per-field state history. The equivalents in the other sources are dropped the same way. Two things change shape rather than disappear. A Linear Project has no equivalent nesting level in Retasc, so it collapses onto each of its issues as a `project: name` label you can still filter by. And Linear’s untyped *related* link is dropped on purpose: it carries no direction and drives nothing in dispatch, unlike the blocking edges, which are the whole point. Then the part that matters most, and the reason this page exists: the old tracker itself stays behind. Nothing you do there after the import reaches Retasc. ## Cutting over Re-running an import reconciles against the same source ids instead of duplicating, so a second run updates what it already brought over rather than creating a second copy of your backlog. That exists so you can rehearse: import early, look around, then take a fresh snapshot on the day you actually switch. Use it that way and not as a standing sync. The honest cutover is a single afternoon: run the final import, tell the team the queue has moved, archive the old workspace so nobody files into it by accident, and point your agents at `https://mcp.retasc.com/mcp`. ## Getting back out The door out is open and does not involve talking to us. An owner exports the org from the Dash in either of two shapes. JSON is the complete bundle: issues, comments, labels, relations, members, state history and the attachment files themselves, and it restores into a fresh org, so you can move a workspace, keep a cold archive, or hand the lot to whatever you use next. CSV is the issue list on its own, for when you just want a spreadsheet. Deleting an org is the harder end of the same promise. Your content is encrypted under a key held per org, and deleting the org destroys that key, so what is left is unreadable by anyone, us included. Export first, then delete. ## Questions that come up **Does Retasc sync with Linear?** No. The import runs one way and one time. Retasc reads your Linear team at the moment you import and never writes anything back, never reads it again, and never keeps the two in step. After the import Retasc is the queue and Linear is a frozen copy. The same is true of Jira, ClickUp, Asana and Shortcut. **What happens in the old tracker after I import?** Whatever you decide. Nothing you do there reaches Retasc, and nothing Retasc does reaches it. Most teams archive the old workspace on cutover day so nobody files into it by accident. **Is anything ever written back to the source?** Only GitHub, and only because that is where outside contributors file. *It runs once, and it runs one way* above says exactly what closes back. Imported trackers have no such path. **Can I get my data back out of Retasc?** Yes, at any time and without asking anyone. An owner exports from the Dash in two shapes: JSON is the complete bundle (issues, comments, labels, relations, members, state history and the attachment files) and restores into a fresh org, and CSV is the issue list on its own. Deleting an org destroys its encryption key, so the content is unrecoverable by anyone including us. **Are my source API credentials stored?** No. The key lives in memory for the length of the run and is never written down; *What comes across* above has the detail. Revoke it in the old tool once the import finishes. ## Related guides ### [Linear vs Jira vs an agent-first tracker The tracker evaluation changes when agents work the backlog. The new criteria, and a reversible migration. [evaluation][migration]6 min](https://retasc.com/guides/linear-vs-jira-vs-agent-first) ### [Turn GitHub Issues into a work queue your agents drain Connect a repo and its issues sync in as a claimable, deduped queue. Done in Retasc closes the issue at the source. [intake][webhooks]7 min](https://retasc.com/guides/github-issues-ai-agents) ### [What is an agent swarm, and how do you keep one from colliding? The definition, the three failure modes, and the three server-side controls that make a swarm usable. [definition][controls]7 min](https://retasc.com/guides/agent-swarm) ## Get started Bring your backlog across first $10 on us · no card · our busiest agent runs $9 a month ```sh $ npx @retasc/cli@latest bind ``` [Other ways](https://retasc.com/wire?via=web)