One access token. That's the entire connection step for an Asana import — no OAuth consent screen, no admin approval workflow. You generate a personal access token from your Asana profile settings, paste it into Spryn's import screen, and Spryn reads your workspace from there.
This isn't a pitch for switching. It's a walkthrough of what actually happens, mechanically, if you do: what Spryn's import reads from your Asana workspace, what it flattens, and what changes once your team is planning sprints instead of maintaining a project hierarchy.
Why teams start looking
Asana rarely loses a team because it can't do something. It loses them because a Project has quietly become five things at once — a place to track engineering work, a place marketing pastes campaign checklists, a place someone's tracking a hiring pipeline in Custom Fields nobody else uses. Multi-homing a task across three Projects felt clever in month two. By month eight, nobody can say with confidence where a given task actually "lives," or which of the four saved views is the one the team is supposed to trust this week.
> The complaint is rarely "Asana is missing a feature." It's "we have four different views of the same work, and none of them agree with each other anymore."
None of that is a criticism of Asana's design — it's what happens to any sufficiently flexible tool once enough people have configured it for enough different purposes. Engineering teams running sprints usually reach a point where they want one board that answers "what are we shipping this sprint," not a general-purpose work tracker doing double duty as a marketing calendar.
The core mapping
Asana and Spryn describe work differently in a few places, but the underlying objects translate more directly than the terminology suggests. A Task carries across as an Issue — title, description, and assignee intact. Subtasks come across as child issues under the parent. Due dates map one-to-one. Where the mapping gets interpretive is Sections: Asana uses Sections as a flexible grouping inside a Project (to-do / doing / done, or a phase name, or nothing consistent at all), and Spryn's import maps them to the closest equivalent board column it can find, then lets you re-map or collapse them once you're inside the app.
Custom Fields are the one piece that doesn't carry over automatically. If your team tracks story points, priority, or a status flag in a Custom Field, that data stays visible in Asana but isn't pulled into Spryn's structured fields during import — you'll re-enter it in Spryn's native priority and estimate fields as you plan your first sprint, which is also a natural point to decide whether you actually still need all of them.
What the personal access token can and can't see
A personal access token authenticates as you, scoped to your Asana account's own permissions — it's not a workspace-wide admin grant. That has one practical consequence worth planning around before you start: the import can only reach Projects you personally have access to. If your team's sprint work is split across Projects owned by different people, get everyone's access aligned in Asana first, or plan on running the import from whichever account already has visibility into everything you want to bring across.
1. Generate the token. In Asana, go to your profile settings and create a personal access token scoped to your account.
2. Paste it into Spryn's import screen. Spryn uses it to read your workspace — it never writes back to Asana or changes anything there.
3. Preview before you commit. You see exactly which Projects, Tasks, and Sections will be imported before anything is created in Spryn. Nothing happens automatically.
4. Choose your scope. Import everything, or just the Projects relevant to your next sprint — the rest stays in Asana until you need it.
5. Plan your first sprint. Once the import lands, set a sprint intent, pull in the work that fits your team's capacity, and lock the sprint.
Asana itself is completely untouched throughout this. The import is read-only: nothing is deleted, archived, or modified in your Asana workspace at any point, so there's no rollback risk if you want to keep both tools running side by side while your team gets oriented.
What changes once you're planning sprints instead of Projects
The biggest shift isn't visual — the board still has columns, cards still move left to right. It's that a Spryn sprint has a hard edge: a defined start, a defined end, and a single stated intent that everyone can see before they add anything to it. Asana Projects, by contrast, are usually open-ended — work accumulates for as long as the Project exists, with no natural checkpoint forcing a "did we actually finish what we said we would" conversation.
That checkpoint is where a lot of the value shows up. Spryn keeps capacity and scope visible side by side as you build a sprint, so overcommitment is visible before you lock it in, not after the first missed deadline. And because Sprint intent stays visible throughout, trade-off conversations mid-sprint start from shared context instead of someone scrolling back through a Project's activity log to reconstruct what was actually agreed.
None of this requires abandoning how your team already thinks about the work — the Tasks are still Tasks, the assignees are still the assignees. What changes is the frame around them: a sprint instead of an open-ended Project.
If you're not ready to fully commit yet
You don't have to import everything on day one. A common pattern is running one team's next sprint in Spryn while the rest of the org stays on Asana — the import is available any time, and because it's read-only, there's no cost to trying it against a single Project first. If Spryn isn't the right fit after that sprint, your data exports cleanly and Asana was never touched in the first place.
See the full list of supported import sources — Jira, Asana, ClickUp, Linear, and CSV — at spryn.io/switch-to-spryn, and the self-hosted pricing details at spryn.io/pricing.