Import from JIRA, Trello, monday and Asana
Bring a JIRA Cloud or Asana project, or a Trello or monday.com board, into Hilbana: issues, states, labels and comments.
Importing brings your work from another tool into a Hilbana project. There are four sources today: JIRA Cloud, Trello, monday.com and Asana. Either way it’s a one-time import, not a sync: what you change in the source afterwards doesn’t travel on its own, and what you change in Hilbana doesn’t go back. You can run it again whenever you want, but each run is a move, not a permanent link between the two tools.
Everything happens in Settings → Import, on a single screen, and you need to be a workspace admin. You pick the source at the top and its panel opens below (Linear is shown dimmed, as “Coming soon”).
How to use it
The path is the same for all four sources:
- Connect the account. This part differs per source; see below.
- Pick what to bring: a JIRA or Asana project, or a Trello or monday board, with its issue count.
- Pick the target project in Hilbana, either existing or created right there. The whole import lands in a single project.
- Analyse. This is a read-only preview: it walks the whole source and reports how many issues, comments, labels and people there are, what will be dropped, and a proposed set of mappings.
- Confirm the mappings. Source states map one to one onto yours, with the proposal pre-filled and the option to create a missing one. An unmapped state blocks the import: no issue ever lands in a guessed state. People are matched against workspace members, and no new users are ever created.
- Review and run. The last step repeats the numbers, states what stays behind and only then writes. On a large project it takes a while and you’ll see progress.
- History. Every run is recorded with what it created, skipped and updated.
From JIRA
What you need
- Your JIRA site URL (something like
yourcompany.atlassian.net). - Your Atlassian email and a personal API token, which you create at
id.atlassian.com. Copy it right away: Atlassian won’t show it again.
The token is stored encrypted and is never shown back, not even masked. It grants access to everything you can see in JIRA, so you can revoke it from the screen itself — with Disconnect — or from Atlassian whenever you want.
What comes across
| From JIRA | Into Hilbana |
|---|---|
| Summary | Issue title |
| Description | Description, converted to markdown |
| Status | Workflow state, per the mapping you confirmed |
| Priority | Priority (Highest → urgent, Lowest/Low → low…) |
| Assignee | Assignee, per the people mapping |
| Labels | Labels; missing ones are created |
| Created, updated, resolved and due dates | The same dates |
| Story points | Estimate |
| Epics and sub-tasks | Parent/child issue hierarchy |
| Comments | Comments, with their original date |
People are matched by email and, if your JIRA site hides it, by name.
What doesn’t come across
- Attachments.
- Change history of each issue.
- Sprints (they don’t become cycles).
- Versions (they don’t become milestones).
- Issue links (“blocks”, “relates to”…). The parent/child hierarchy is kept; the other links are not.
Fields with no equivalent are dropped too, such as resolution, environment, votes or time spent. The confirmation step tells you how many attachments and versions stay behind before anything is written.
JIRA Cloud only. If you’re on JIRA Server or Data Center, today’s route is your agent: with the MCP connected it can read your JIRA and create the issues.
From Trello
What you need
Just the API key of a Trello app of yours, which you get at
trello.com/power-ups/admin by creating a Power-Up with any name. The screen does
the rest: you paste the key, hit Authorise on Trello, accept there and come back
to Hilbana already connected. There’s no token to copy.
Two details that avoid the one common stumble:
- On that Trello page, below the key, there’s a “Secret”. It’s no use here and isn’t needed at all; if you paste it, Trello answers “invalid key”, blaming the key — which will be perfectly fine.
- To be able to bring you back, Trello requires Hilbana’s address to be listed under “Allowed origins”, on that same page. The screen shows it to you with a copy button before you leave.
The permission requested is read-only and for 30 days: the app cannot comment, write, or read your email — you’ll see it spelled out on Trello’s own screen. It’s stored encrypted, never shown back, and withdrawn with Disconnect or from your Trello account.
What comes across
| From Trello | Into Hilbana |
|---|---|
| Board | The target project you pick |
| List | Workflow state, per the mapping you confirmed |
| Card | Issue |
| Description | Description, in markdown |
| Checklists | A task list inside the description, tickable and keeping what was done |
| Labels | Labels; the ones with no name come across by their colour |
| Card members | Assignee, per the people mapping |
| Comments | Comments, with their author and original date |
| Due date | Due date |
| Position in the list | The order within the board column |
| Card creation date | Creation date |
On states: Trello doesn’t classify its lists in any way, so the proposal comes from each list’s name (“Done” → a completed-type state, “Doing” → a started one…). Give it a look before running; it’s a suggestion, not a certainty.
On people: Trello does not expose its members’ email through its API, so there’s nothing to guess here and you pick who is who, from a list of your workspace members. With no match the issue arrives unassigned. And a card with several people keeps the first one: a Hilbana issue has a single assignee.
What doesn’t come across
- Attachments. Trello’s API won’t hand them over without further credentials; the confirmation step tells you how many stay in Trello before anything is written.
- Archived cards and lists.
- Card start dates.
- Power-Ups, Butler automations and the calendar or timeline views.
- Covers, votes and reactions.
Trello has neither priority nor estimates, so issues arrive without either: inventing them from labels would be guessing about your work. There’s no card hierarchy to bring over either.
From monday.com
What you need
Just your monday personal token. You get it inside monday by clicking your avatar (bottom left) → Developers → My access token, and you paste it into Hilbana. There’s no app to register and no addresses to authorise.
Two warnings that save the usual stumble:
- The importer will see exactly the boards you see with that token. If you work across several monday accounts, generate the token inside the account whose boards you want to bring over.
- If that menu option isn’t there, your admin has tokens restricted: ask them.
The token is stored encrypted and never shown back. The importer only reads: it writes nothing into monday. You withdraw it with Disconnect or by revoking it from your monday account.
What comes across
| From monday | Into Hilbana |
|---|---|
| Board | The target project you pick |
| Group, or the status column you pick | Workflow state, per the mapping you confirmed |
| Item | Issue |
| Subitem | Sub-issue, hanging off its parent |
| Long text columns | Description, in markdown |
| People column | Assignee, matched by email |
| Date or timeline column | Due date |
| A “Priority” column | Priority (High, Medium, Low…) |
| A number column for points or estimates | Estimate |
| Dropdown, tags and any other status columns | Labels; missing ones are created |
| Updates | Comments, with their author and original date |
| Creation and update dates | The same dates |
| Item order on the board | The order within the board column |
On states, which is monday’s own quirk: there’s no status field as such here. Every team keeps it differently — some in the board’s groups (the coloured bands) and some in a status column — and both habits are equally common. So you pick, before analysing, in the same step where you pick the board, with your groups and columns in front of you. Whichever you pick, you then confirm the mapping one by one, just like in the other sources.
On subitems: they arrive as sub-issues of their parent item, and they inherit the parent’s state. The reason is that in monday subitems live on a separate board, with their own groups and columns, which aren’t the ones you mapped; inheriting is the only option that doesn’t invent a state you never chose.
On people: monday does expose member emails, so most of them match on their own. Check the ones that don’t. And an item with several people keeps the first one: a Hilbana issue has a single assignee.
What doesn’t come across
- Files from file columns. The confirmation step tells you how many stay in monday before anything is written.
- Columns with no equivalent in Hilbana: formulas, mirrors, buttons, votes, dependencies, time tracking and the like. The ones that do have an equivalent are in the table above.
- Boards that aren’t data boards: subitem boards and dashboards don’t show up in the list.
- Automations and integrations, forms, docs and the calendar or timeline views.
Two mapping details, so they don’t surprise you: if the board has several date columns, the first one is used as the due date; and only a number column that says so in its name (points, estimate, story points) comes across as an estimate, not any number — a budget is not an effort estimate.
From Asana
What you need
Just your Asana personal access token. You create it inside Asana by clicking your photo (top right) → Settings → Apps → View developer console → Create new token, or by going straight to the developer console. Give it any name, copy the token and paste it into Hilbana. There’s no app to register.
The importer will see exactly the projects you see in Asana, across all your workspaces. If you have both a personal and a work account, create the token with the account whose projects you want to bring over.
The token is stored encrypted and never shown back. The importer only reads: it writes nothing into Asana. You withdraw it with Disconnect or by revoking it from the Asana developer console.
What comes across
| From Asana | Into Hilbana |
|---|---|
| Project | The target project you pick |
| Section | Workflow state, per the mapping you confirmed |
| Completed task | The state you pick for «Completadas en Asana», with its real completion date |
| Task | Issue |
| Subtask (at any depth) | Sub-issue, hanging off its parent |
| Description | Description |
| Assignee | Assignee, matched by email |
| Start and due date | Start date and due date |
| Tags | Labels; any that don’t exist are created |
| Comments | Comments, with their original author and date |
| Created and updated dates | The same dates |
| Task order within each section | The order within the board column |
On states, which is the Asana-specific bit: there’s no status field here. There are sections (the board columns) and, separately, the completed tick. Each section maps onto one of your states, but a completed task always goes to a row of its own in the mapping, «Completadas en Asana» (the row keeps that name in either language), whatever section it sits in. That way a task that was completed without being moved out of “In progress” doesn’t reach Hilbana as open, and it keeps the day it was closed.
On subtasks: they arrive as sub-issues of their parent. In Asana they don’t belong to any section, so unless they’re completed they take their parent’s section.
On people: Asana does share its members’ email, so most match on their own. Review the ones that don’t, especially guests from outside your organisation, who may come without an email.
What doesn’t come across
- Attachments, which stay in Asana.
- Custom fields, including priority if you keep it in one.
- Portfolios, goals, rules, forms and the timeline or calendar views.
- Each task’s activity history: only comments come over.
Asana milestones arrive as regular issues, with their date.
Re-importing
Hilbana remembers which source issue each of its issues came from, so re-importing doesn’t duplicate: the ones already there are skipped by default.
If you want to refresh them, there’s an “Update the ones you already imported” checkbox, unticked on purpose. Ticking it resets title, description, state, priority, assignee, labels, dates and estimate to the source values — that is, it overwrites whatever you’ve done in Hilbana since the previous import. Comments already brought over aren’t duplicated, and an issue created by hand in Hilbana is never touched.
Undo
Every row in the history has Undo, which deletes the issues and comments of that run. Before you confirm it tells you how many there are, how many of those issues have been touched since, and whether any later issue will be left without a parent. Anything created afterwards is untouched, and labels stay: you may be using them elsewhere.
Details
- Importing is available on every plan, including the free one, and the only requirement is being a workspace admin. Free brings over 200 issues per import (the confirmation step tells you the real number before you start, and the summary tells you how many stayed behind); paid plans have no cap.
- Numbering is Hilbana’s: imported issues get their own identifier, not the source one.
Related: Projects · Issues · Workflow states · Members & roles.