How do you migrate from YouTrack to Plane without losing issue history?
The migration is mostly an export and mapping exercise for issues, comments and attachments, with links, workflows and integrations as the main rework. If a renewal, subscription change or data residency requirement has pushed you toward self-hosted Plane, plan for the issue data to move cleanly and for everything around it to need manual attention. Confirm the export options available in your own YouTrack version before you commit to a method, because the formats and fields you can pull out determine how much of the history survives intact. Plane's importers cover several sources, and its CSV importer is available on the self-hosted Commercial Edition and on the plans that include it, as described in the Plane importers documentation. Confirm with Plane which edition and plan your deployment needs before you build the pipeline around it.
Platform or IT teams usually run this work, often with an implementation partner who writes the transformation scripts, runs test imports and checks the results field by field. The effort turns on three things: the volume of issues and attachments, how many custom fields and states YouTrack projects use, and how many integrations, such as source control hooks, build pipelines and helpdesk routes, point at YouTrack issue IDs. Ask for a sample migration of one representative project before scoping the rest, and record which fields arrive as plain text, which lose their type, and which have no Plane equivalent. Those findings become the decision list for the business owners of each project.
Plan to run both trackers for a period so teams can finish open work and update links in commits, documents and external systems. Keep the YouTrack instance read-only once cutover is agreed, and map old issue identifiers to new ones in a lookup table that stays available for support staff and auditors. Before you retire YouTrack, verify that comment authorship, timestamps and attachment counts match the source for a sample of issues, and retain an archive of the original export under your own retention policy. These checks are cheap to run early and expensive to reconstruct after the source is gone.
Which YouTrack capabilities map to Plane and which need rework
This table pairs each main YouTrack capability with its closest Plane equivalent and rates the migration effort as clean, needs rework or gap. Plane's importer documentation lists CSV import on the Commercial Edition, but field-level mapping from YouTrack should be proven in a test import. Items marked to confirm need checking against current Plane documentation before the migration plan is set.
| YouTrack capability | Plane equivalent | Migration note |
|---|---|---|
| Projects | Plane projects with work items, cycles and modules | Clean: map one YouTrack project to one Plane project. Confirm how project identifiers carry over. |
| Issues, fields and tags | Work items with properties, assignees, dates and labels | Needs rework: map each YouTrack field to a Plane property in the CSV template. Tags usually become labels. Confirm supported property types. |
| States and workflow | Workflow states grouped into backlog, unstarted, started and completed | Needs rework: YouTrack transition rules do not carry over. Recreate states and confirm how groups map. |
| Comments and attachments | Work item comments and file attachments | Needs rework: comments may import as text and files often need a separate transfer. Test on a sample project. |
| Agile boards | Board layouts and cycles for sprint-style work | Needs rework: swimlanes, WIP limits and board-specific settings must be rebuilt. Confirm current layout options. |
| Saved searches and query language | Views and filters | Gap: YouTrack query syntax does not import. Rebuild saved searches as Plane views and confirm filter coverage. |
| Links between issues | Work item relations such as blocking and duplicates | Needs rework: confirm whether the importer keeps link types. Recreate critical dependencies by hand. |
| Time tracking | Time logging, to confirm in current Plane documentation | Confirm: export worklogs from YouTrack separately and decide where historic time is stored. |
| YouTrack Helpdesk | No direct Plane equivalent | Gap: keep a separate helpdesk such as Zammad or FreeScout and link tickets to work items. |
What data to export from YouTrack and what to rebuild in Plane
A YouTrack move to Plane splits into data that travels through an export and configuration that has to be rebuilt by hand. Plane's documented importers cover Jira, Linear, Asana, ClickUp, Notion, Confluence, Flatfile and CSV, so a YouTrack export is usually handled as CSV. Confirm the export format for your YouTrack version before you plan the work.
Issue fields and comments
Issues are the core of the move. Export issues with their summary, description, state, priority, assignee, dates and comments, using the export or query output available in your YouTrack version. Confirm that comments come with author and timestamp, because a CSV row holds one value per column and multi-line comment threads need a deliberate layout. In Plane, issues land as work items, so check that the imported text keeps its formatting and that links between issues survive.
Attachments
CSV exports carry references to files, not the files themselves. Plan a separate download of attachments from YouTrack and confirm how your version packages them. Decide whether files are re-attached to each imported work item in Plane or kept in an archive that the team links to. Check file size limits and storage capacity on your Plane object storage before the first trial import.
Users, roles and permissions
Map YouTrack users to Plane members by email address, and check that every assignee and commenter has an account before import. Plane counts seats by users with paid roles, so the role mapping directly affects the license scope on the Commercial Edition. Permissions in YouTrack, such as project-level visibility, do not transfer as rules, so rebuild them as project membership in Plane.
States, tags and custom fields
Mapping is where most imports go wrong. YouTrack states, tags and custom fields need a written mapping to Plane states, labels and properties before any import runs. Export the field configuration as well as the issues so that you can compare value lists. Values with no Plane equivalent should be merged or stored in a description field, and every decision belongs in the mapping document that the team signs off.
Saved queries, dashboards and agile boards
YouTrack saved searches, dashboards and agile board configurations do not move with the issue data. Export the query text for each saved search so you can see which filters the team depends on, then recreate the views in Plane using its cycles, modules and filters. Confirm which dashboards are used every week before you rebuild any of them, because unused views are a common source of wasted effort.
Git, CI and chat integrations
Commit links, CI status and chat notifications are configured in each external tool and must be rebuilt, not carried over. List every integration that writes to or reads from YouTrack, then recreate the connection to Plane through its webhooks or API. Commit references such as issue IDs will break unless the identifiers in Plane match the old keys, so test one repository before you switch the rest.
What happens in each phase of the YouTrack to Plane migration
The sequence moves YouTrack work into Plane in controlled stages, so each project is checked against a written inventory before anyone relies on it. Each phase closes with a named artifact and a sign-off, so the cutover is a decision rather than a surprise.
Inventory projects, workflows, fields and integrations
Export a list of every YouTrack project, its issue counts, workflow states, custom fields, tags, saved queries, agile boards, linked helpdesk or CI tools, and the users who hold each role. Record which items must move and which will be retired. The owner of each project and the platform team sign off on the inventory document, which becomes the scope baseline for the rest of the migration. Ask your Plane implementation partner to confirm which YouTrack field types map cleanly and which need manual rework.
Pilot one project in a non-production Plane instance
Stand up a non-production Plane instance, choose one low-risk YouTrack project, and run an export and import using Plane's CSV importer. Check that issue titles, descriptions, states, priorities, assignees, comments and tags arrive correctly, and record every field that was dropped or altered. Attachments usually need a separate step, so confirm how they are carried before you treat the pilot as complete. The pilot is done when the project owner signs a mapping log that lists each field's source, target and any manual fix.
Run a parallel period with YouTrack read-only
Import the remaining in-scope projects into Plane, then set YouTrack projects to read-only so teams can work in Plane while still consulting history in YouTrack. Compare issue counts and sample records weekly between the two systems to catch gaps early. Keep a running list of defects found in the imported data and who owns each fix. The platform lead and each team lead sign off when open issues match and the defect list is closed or accepted as a known gap.
Cut over links, notifications and integrations
Update every link that points to YouTrack issues, including commit messages references, wiki pages, runbooks and email templates, so they point to Plane work items. Reconfigure notifications, webhooks and CI integrations to target Plane, and retire any automation that still writes to YouTrack. Confirm with a test branch or test issue that each integration reaches Plane. The release owner and the security lead sign off on a cutover checklist listing each link and integration with its verification result.
Decommission YouTrack and keep a retained export archive
After the agreed read-only period, take a final full export from YouTrack, store it in an access-controlled archive on your own infrastructure, and document its format and retention period. Remove or disable YouTrack users, integrations and licenses, and confirm with your JetBrains account team that any subscription or license is ended on the terms in your contract. The CISO or records owner signs the decommission record, which lists the archive location, checksum and retention owner.
What drives the cost and duration of the move
This table lists the factors that change the cost and effort of moving from YouTrack to Plane, why each one matters, and how to keep it manageable. Read it before requesting a quote, because the same product can be a small or a large job depending on these inputs. The main takeaway is that the scope of your data and integrations, more than the tool itself, sets the effort.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Number of projects and issues | Each project needs a mapping decision, and issue volume drives the import run time, validation and cleanup work. | Archive closed projects, migrate only active backlogs and history you must keep, and confirm the import limits with Plane before you start. |
| Custom field complexity | YouTrack custom field types, enum values and multi-value fields rarely map one to one onto Plane properties, so each one needs a decision. | Inventory every custom field, merge duplicates and drop unused fields before mapping. |
| Attachment volume | Attachments add storage, transfer time and a separate check that links still resolve after the move. | Set a cutoff for old attachments, keep them in an archive, and confirm how the importer handles files with your version. |
| Depth of integrations | Git commits, CI links, helpdesk tickets and external webhooks that point at YouTrack IDs must be rewired, and each one is separate work. | List every integration that references issue keys, rewire the high-traffic ones first, and retire the rest. |
| Number of workflows to remap | YouTrack workflows and states must be translated into Plane states and transitions, and automations usually need rebuilding by hand. | Consolidate states before the move and document which automation rules are rebuilt rather than migrated. |
| Self-hosted infrastructure choice | Docker Compose suits smaller teams, while Kubernetes with Helm adds high availability but also more components to run and patch, including PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage. | Match the method to the availability you need, and reuse managed or existing database and object storage services where your policy allows. |
| Commercial Edition licensing step | Paid plans on self-hosted Plane require switching from Community to the Commercial Edition with a license key, and the Plane Kubernetes guide installs the Commercial Edition, so the choice affects setup and seat counts. | Decide the edition and plan before installation, count seats by users with paid roles, and ask Plane to confirm the current terms in writing. |
| Plane plan pricing | Plane's pricing page lists Pro at 6 to 8 and Business at 13 to 15 US dollars per user per month, with Enterprise Grid on request, so seat count and plan tier drive recurring cost. | Request a written quote from your scope rather than estimating from list prices, and confirm which features your plan needs. |
What usually goes wrong when moving from YouTrack to Plane
Most failed YouTrack to Plane moves fail on data meaning, not data volume. The risks below come up in almost every move: loose mapping, lost attachments and authorship, broken references, conflicting edits during the parallel run, and a wrong assumption about which Plane edition includes the CSV importer.
Loose state and field mapping
Mapping YouTrack states and custom fields to Plane states and properties by name alone can merge distinct workflow stages, so a ticket that was waiting on a customer looks identical to one in active development. Build a written mapping table per project covering every YouTrack state, custom field, tag and issue type, and decide where each one lands before the first test import. Checkpoint: pick ten issues from each project, trace their state history by hand and confirm the meaning survives the import.
Lost attachments and comment authorship
A CSV import carries issue fields well, but attachments and the original author of each comment may not arrive intact, and a re-imported comment can appear as written by the migration user. Confirm with Plane which attachment and comment data your chosen import path carries, then test one issue with a file and a multi-author thread. Checkpoint: open the imported issue in Plane and compare attachment count, file integrity and comment authors against YouTrack.
Broken links from commits and documents
Commit messages, pull requests, wiki pages, release notes and other tools still reference YouTrack issue keys such as project-prefixed IDs, and those links stop resolving once the tracker is retired. Inventory every system that stores issue keys, including the Git host and CI pipelines, then decide which references need rewriting and which can point to a frozen YouTrack archive. Checkpoint: sample recent commits and wiki pages and confirm each key resolves to a live Plane item or the archive.
Conflicting updates during parallel runs
When teams keep both trackers open, the same issue can be edited in YouTrack and Plane, and the second change silently overwrites or forks the first. Set a cutover date per project, make YouTrack read-only for migrated projects once the final sync runs, and announce which tool owns new work. Checkpoint: after cutover, confirm YouTrack shows no edits to migrated projects and that open items were reconciled once.
Assuming Community includes the CSV importer
Plane's importers are listed for Plane Cloud and the self-hosted Commercial Edition, and a self-hosted Community install does not automatically include them. Teams that plan a Community deployment and then discover the importer is missing lose time and may need to switch editions mid-project. Confirm in writing with Plane which edition and plan includes the CSV importer for your deployment, and check the editions documentation before you schedule the import. Checkpoint: run a test import on the exact edition you will run in production.
How the migration differs by team size and starting point
A small team on YouTrack Cloud usually has a limited number of projects, a short list of states and a few custom fields. The migration scope is mostly about issues, comments and attachments, and the main question is how much of the existing workflow is worth recreating in Plane rather than starting fresh. Because the source is hosted, you do not manage the YouTrack side, but you still depend on the export options your plan gives you, so confirm them before planning.
- Export access: Confirm which export formats and attachment downloads your Cloud plan and admin role allow, since this sets the extraction method.
- Simple field mapping: Map a handful of states, priorities and tags to Plane states and labels, and decide early which fields are not carried over.
- Fresh start option: Consider moving only open issues and recent history, with closed work kept as a read-only archive.
- Hosting choice: Decide whether Plane runs on Plane Cloud or on your own servers, since that affects where attachments and data sit.
- Cutover window: Plan a short period where both trackers run, so links from commits and documents can be updated.
Confirm with your YouTrack administrator which export and attachment options your Cloud subscription includes before you commit to a migration scope.
A larger team on self-hosted YouTrack Server usually has many projects, long issue histories, extensive custom fields and bespoke workflows. Here the migration is mostly a mapping exercise. Each custom field type needs a decision: a direct equivalent in Plane, a label or text field, or retirement. The Plane importers include a CSV path and the Jira importer, but a YouTrack-specific route should be confirmed with Plane before you rely on it.
- Custom field inventory: List every custom field, its type and its use in queries and dashboards, since these drive the mapping work.
- State and workflow mapping: Map each YouTrack state and transition to a Plane state group, and record which transitions carried business rules.
- Link types: Decide how parent, subtask, duplicate and related links are represented after the move.
- Database and attachments: Plan how large attachment volumes are copied to Plane's S3-compatible storage, and how permissions are rebuilt.
- Dual running: Keep YouTrack read-only for a period after cutover so historical links keep resolving.
Confirm the server version and the export tooling you have access to, and ask Plane which import paths support your field types, before you estimate any effort.
Some teams use YouTrack Helpdesk to receive customer tickets and route them into development work. Plane does not provide a helpdesk function, so the migration has two parts: moving the work items into Plane, and deciding which tool replaces the ticket intake. This means the reporter, email thread and customer-facing history need a separate home, and links between tickets and development items must be rebuilt rather than assumed to survive.
- Ticket intake: Decide on a separate ticket tool, such as Zammad or FreeScout, and define how tickets become Plane work items.
- Reporter history: Export helpdesk conversations and attachments separately, since they are not the same data as development issues.
- Link rebuilding: Record which tickets link to which work items, and recreate those references in the new tracker.
- Access rules: Confirm which agents and customers can see which tickets, because helpdesk permissions differ from project permissions.
- Two-system cutover: Plan a period where both the ticket tool and Plane operate, so new email threads are not lost.
Confirm with your support team which helpdesk features they depend on, such as SLAs or customer portals, before choosing the replacement.
Questions teams ask before moving from YouTrack to Plane
How much does a migration from YouTrack to Plane cost?
The cost is mostly labor, plus the Plane edition and hosting you choose. The supplied facts do not give a migration price, so ask for a written quote built from your scope. Main cost drivers: number of projects and issues to map, how many custom fields and workflow states need translating, attachment volume, how many people need training, and whether you run the Community Edition or pay for a Commercial Edition plan. Plane's pricing page lists Pro at 6 to 8 US dollars and Business at 13 to 15 US dollars per user per month, with Enterprise Grid on request, so confirm current plan contents and rates with Plane before budgeting. Recurring costs include Plane seats, servers, PostgreSQL, Redis or Valkey, RabbitMQ, object storage and staff time for upgrades.
How long does a YouTrack to Plane migration take?
Timing depends on how much history you carry and how much mapping work your projects need. No duration is supplied for this migration, so treat any number you hear as an estimate to verify. Timelines grow with the number of YouTrack projects, the depth of custom fields and state models, the volume of attachments and comments to move, and the number of workflows that depend on YouTrack query language or Helpdesk. Fixed-scope work agreed in writing before it starts makes the timeline easier to hold. Plan for a parallel run period in which both trackers stay live until links, integrations and team habits have moved over.
What does our team need to provide for the migration?
Your team supplies the source data, the mapping decisions and the sign-off. Start by confirming which export options your YouTrack version offers, since exports vary by edition and release, and confirm them with JetBrains. Then decide how YouTrack projects map to Plane projects, how states map to Plane states, how tags and custom fields translate, and who owns each decision. Name an approver for each project, define acceptance checks such as issue counts, comment completeness and attachment links, and agree a cutover date. Without named owners and written mapping rules, the migration tends to stall at the first disputed field.
Can an internal team migrate from YouTrack to Plane alone?
An internal team can do a small migration alone if it has the skills and time, and it is a sensible option for a few projects with simple fields. The work involves exporting data, cleaning CSV files, mapping states and custom fields, moving attachments, testing imports on a copy and running Plane in production. Teams that lack Plane administration, Docker or Kubernetes experience, or time for repeated test imports often bring in an implementation partner for part of the work. DeployOpen plans, implements, integrates and documents self-hosted platforms in your own infrastructure under a fixed scope agreed in writing.
Is Plane's CSV importer available on the Community Edition?
The supplied facts list importers, including CSV, as available on Plane Cloud and on the self-hosted Commercial Edition, not on the Community Edition. The Community Edition is licensed AGPL-3.0 and matches the feature set of the Plane Cloud Free tier, so confirm importer availability for your exact edition with Plane before planning around it. If the importer is only on the Commercial Edition, moving to it requires a license key and a seat count based on users with paid roles. Ask Plane which plan includes which importer and what changes when you switch from Community to Commercial.
How do we run YouTrack and Plane side by side safely?
Run both trackers in read-write mode only for a short, defined period, and make one tracker the system of record for each project at any time. Freeze new work in YouTrack for a project once its issues are migrated, then update links from commits, documents, dashboards and other tools to Plane. Keep the YouTrack instance under its existing access controls and backups until you have verified the migrated data. Check the sync direction and log every cutover step. Confirm with JetBrains how long your YouTrack license and support cover the parallel period, since the supplied facts do not cover this.
How DeployOpen scopes and runs the move to Plane
DeployOpen plans, implements and hands over the move from YouTrack to a self-hosted Plane instance inside your own cloud account, data center or air-gapped network. Scope, deliverables and timelines are agreed in writing before any migration work starts, and ongoing support is available as a retainer.
How we scope
- Inventory of YouTrack projects, custom fields, states, tags, workflows and linked issues to be migrated
- Decision on which Plane edition and deployment method fit your hosting and seat requirements
- Written list of what is excluded, such as YouTrack Helpdesk, agile board configuration or external integrations
- Agreed cutover plan covering a period where both trackers run in parallel and links are updated
How we build
- Self-hosted Plane deployed with its PostgreSQL, Redis or Valkey, RabbitMQ and S3-compatible storage components
- Field and state mapping documented per project, with test imports run against a copy of your data
- Attachment and comment transfer checked on sample issues before any full import is attempted
- Authentication and access configured to match your identity setup, with the required edition confirmed first
How we hand over
- Runbook covering the deployment, the import steps, the mapping tables and the rollback path
- Reconciliation report comparing issue counts, comments and attachments between YouTrack and Plane
- Redirect and link update list so that commits, documents and bookmarks point to the new tracker
- Admin training for your platform and project leads on the new workflows and permissions
How we support
- Operational support for upgrades, backups and patching of the Plane instance on your infrastructure
- Retainer options for continued administration, configuration changes and release upgrades
- Regular review of Plane release notes so that upgrades are scheduled and tested before rollout
- Escalation path agreed in the written scope, including who responds to incidents and within which hours

