Documentation Index
Fetch the complete documentation index at: https://ekso.dev/llms.txt
Use this file to discover all available pages before exploring further.
What ekso migrate is
ekso migrate is a built-in importer that moves projects, work items, comments, attachments, links, and time history from another platform into your Ekso tenant. One source picker, one set of commands, one cache format.
It currently supports five sources:
| Source | Branch | Read |
|---|
| Atlassian Jira | ekso migrate jira | Migrate from Jira |
| Linear | ekso migrate linear | Migrate from Linear |
| Azure DevOps | ekso migrate devops | Migrate from Azure DevOps |
| Zendesk | ekso migrate zendesk | Migrate from Zendesk |
| Countersoft Gemini | ekso migrate gemini | Migrate from Gemini |
Two phases — collect and apply
The migrator splits cleanly into two commands:
ekso migrate <source> collect ... # source platform → local SQLite cache
ekso migrate <source> apply ... # local SQLite cache → Ekso REST
- A 50,000-issue Jira collect can take an hour. A network blip during apply must not force re-fetching from the source.
apply --dry-run walks the cache and tells you exactly what would be created — no Ekso writes — before you commit.apply is resumable. Every successful create writes the source-id → Ekso-id pair into a local IdMap table; a re-run skips already-applied rows.- The two phases can run on different machines. Collect on a workstation that can reach the source platform; copy the SQLite file; apply from a CI runner with Ekso credentials. This is the on-prem migration story.
The cache lives at ~/.ekso/migrate/<source>-<timestamp>.sqlite by default. Override with --working-dir.
What you get on the Ekso side
The migrator preserves authoring fidelity. Every comment, every worklog, every attachment is attributed to the user who created it on the source platform — not to the running CLI user.
| Source concept | Ekso shape |
|---|
| Project / Team / Org | DataContainer |
| Issue / Ticket / Work Item | DataItem |
| Comment / Discussion | DataAnnotation |
| Attachment | DataFile (multipart upload) |
| Worklog / Time entry | DataItem.Time[] (in the same item POST) |
| Sprint / Cycle / Iteration / Version | DataCycle |
| Component / Area / Group / Tag | ConfigLabel + DataItem.Tags |
| User / Agent / Identity | DataUser (matched by email or minted) |
| Issue link / Subtask | DataLink |
| Custom field | DataItem.Field[] (via field-map) or Meta (lossless) |
Identity resolution — three strategies
External platforms attribute every comment, worklog, and item to a user. Ekso has to record those authors faithfully or the audit trail breaks. The CLI offers three strategies via --user-strategy:
| Strategy | What it does |
|---|
match-or-create (default) | Match each source user by email; if no Ekso user has that email, mint one (random password, no invite email sent). |
match-only | Match by email only. Source users with no Ekso match fall back to --fallback-user (or the running CLI user). |
migration-bot | Force every author to a single fallback user. Lossy, but simple if author fidelity isn’t important. |
What does not migrate
Honest list:
- Workflow definitions / state machines. The migrator snapshots the current state of each item. State-transition rules and screen layouts on the source platform don’t transfer — the customer’s destination process defines the new shape.
- Permissions / role assignments. Source-platform ACLs don’t map. Configure access on Ekso’s side after the migration.
- Brand customisations. Themes, logos, custom domains are platform-specific.
- Source-platform automations (Jira automations, DevOps build pipelines, Zendesk macros, Gemini rules). Re-author them as Ekso rules.
- Reverse migration. This is one-way — Ekso → source is not supported.
- Ongoing sync. This is a one-shot migration tool, not an integration.
Each per-source page calls out additional source-specific gaps.
Before you run anything
Read Before you start — prerequisites, secrets policy, token rotation. Then pick your source.
Where to next
