Migrate your Dart data
Dart is a project management platform with a Flutter-backed mobile workflow focus, rated highly by small teams who value its simplicity and integrations.
In its favor
Why people choose Dart
The signal that keeps Dart on the shortlist. Sourced from G2, Capterra, and customer scoping calls.
AI-native data model — Dart was built ground-up with AI agents, chat, and skills as first-class objects rather than bolted onto a traditional issue tracker, which lets teams delegate routine task creation, property filling, and subtask generation to the platform itself.
Generous free Personal tier (up to 4 teammates, unlimited tasks and docs, AI task execution, ChatGPT and Claude integrations) makes evaluation and small-team adoption frictionless.
Native CLI plus Python and TypeScript SDKs (pip install dart-tools / npm install dart-tools) plus a documented OpenAPI spec at app.dartai.com/api/v0/public/docs/, giving engineering teams scriptable automation that most PM tools require third-party glue to achieve.
MCP server support lets Dart plug into LLM agent ecosystems with an auth-token-secured remote URL rather than running a local Node process — useful for teams already standardising on MCP.
Y Combinator-backed with a clear pricing ladder ($0 Personal / $8 Premium / $12 Business per teammate annually) and per-seat economics that compare favourably with Linear and Jira at small-team scale.
Smaller installed base and ecosystem than Linear, Jira, Asana, or ClickUp — fewer prebuilt apps, no large marketplace, and limited third-party reporting connectors beyond the documented Slack, Discord, GitHub, and Zapier integrations.
AI-heavy positioning means heavy reliance on ChatGPT/Claude credentials and model availability; teams in regulated industries or with strict data-residency requirements may need to disable or vet those integrations carefully.
Public API rate limits and bulk endpoints are not published outside the OpenAPI spec, so large historical exports require a careful test loop rather than relying on a documented batch contract.
Business-tier features such as SAML SSO, SCIM, advanced analytics, and granular access management require the top tier; teams that need SSO without a deep AI roadmap find the Premium-to-Business price jump harder to justify.
As a newer product, change cadence is high — feature names, MCP server endpoints, and integration patterns have shifted recently (per the vendor's own help docs noting a simplified hosted MCP), which can introduce migration churn.
Reasons to switch
Why people leave Dart
The recurring reasons buyers give for replacing Dart. Presented as facts, not knocks.
Platform scorecard
Strengths, weaknesses, and where Dart fits
Grades across six dimensions, plus a SWOT-style view of where the platform shines and where it falls short.
SWOT — strengths, weaknesses, and use-case fit
Strengths
Weaknesses
Where it works
Where it struggles
Pricing tiers
Dart pricing overview
Dart uses a subscription model with monthly and yearly billing cycles, accepting both credit card and ACH payment. Pricing tiers are not publicly listed on the product's website, and a custom quote is required for mid-to-large team deployments.
Personal
Tier 1 of 3
$0/teammate (free)
What's included
Need help selecting your Project Management?
Book a free 30 minute consultationPricing is informational. FlitStack AI does not bill on Dart's schedule — see our quote-based pricing →
What gets migrated
Dart object support
Object-by-object support for Dart migrations. Per-pair details surface during scoping.
Projects
Mapping requiredDart Projects are the top-level container. We migrate project metadata, settings, and the full task hierarchy as child records, preserving parent-child relationships via the task IDs assigned in Dart.
Tasks
Fully supportedTasks carry standard fields (title, description, due date, assignee, status) and optional custom fields. Standard fields migrate 1:1; custom fields require field-level mapping against the destination schema.
Workspaces
Mapping requiredWorkspaces are the organizational unit in Dart, roughly equivalent to organizations in other PM tools. We migrate workspace membership and permission roles, but role name mapping depends on the destination's permission model.
Subtasks
Fully supportedSubtasks are nested under tasks with a clear parent_id reference. We preserve the nesting depth and reconstruct the full subtask tree in the destination platform using the appropriate sub-item mechanism.
Assignees
Mapping requiredAssignees reference user IDs. We cross-reference Dart user email addresses against the destination platform's user directory and create unresolvable assignee placeholders if a user does not exist in the target system.
Attachments
Mapping requiredDart stores file attachments as linked resources on tasks or projects. We download each attachment to temporary storage, upload to the destination's file storage, and relink the attachment to the target record. File size limits are enforced per the destination platform.
Custom Fields
Mapping requiredCustom fields in Dart are defined at the project or workspace level and applied to tasks. We extract the field definitions separately from field values, map field types to the destination equivalent, and recreate field definitions in the target before loading data.
Time Entries
Mapping requiredTime entries in Dart are linked to tasks and users. We migrate the entry values, duration, and billable flag, but note that the user association requires the same user resolution pass as Assignees.
| Object | Support | Notes |
|---|---|---|
| Projects | Mapping required | Dart Projects are the top-level container. We migrate project metadata, settings, and the full task hierarchy as child records, preserving parent-child relationships via the task IDs assigned in Dart. |
| Tasks | Fully supported | Tasks carry standard fields (title, description, due date, assignee, status) and optional custom fields. Standard fields migrate 1:1; custom fields require field-level mapping against the destination schema. |
| Workspaces | Mapping required | Workspaces are the organizational unit in Dart, roughly equivalent to organizations in other PM tools. We migrate workspace membership and permission roles, but role name mapping depends on the destination's permission model. |
| Subtasks | Fully supported | Subtasks are nested under tasks with a clear parent_id reference. We preserve the nesting depth and reconstruct the full subtask tree in the destination platform using the appropriate sub-item mechanism. |
| Assignees | Mapping required | Assignees reference user IDs. We cross-reference Dart user email addresses against the destination platform's user directory and create unresolvable assignee placeholders if a user does not exist in the target system. |
| Attachments | Mapping required | Dart stores file attachments as linked resources on tasks or projects. We download each attachment to temporary storage, upload to the destination's file storage, and relink the attachment to the target record. File size limits are enforced per the destination platform. |
| Custom Fields | Mapping required | Custom fields in Dart are defined at the project or workspace level and applied to tasks. We extract the field definitions separately from field values, map field types to the destination equivalent, and recreate field definitions in the target before loading data. |
| Time Entries | Mapping required | Time entries in Dart are linked to tasks and users. We migrate the entry values, duration, and billable flag, but note that the user association requires the same user resolution pass as Assignees. |
Gotchas
What to watch for in Dart migrations
Issues we've hit on past Dart migrations, tagged by severity. FlitStack AI handles every one — surfacing them up front because buyer engineering teams want to know.
Sparse public API documentation limits pre-migration discovery
Workspace-level custom field definitions require separate migration step
Attachment storage model requires double-handling
| Severity | Issue |
|---|---|
| High | Sparse public API documentation limits pre-migration discovery |
| Medium | Workspace-level custom field definitions require separate migration step |
| Medium | Attachment storage model requires double-handling |
Leaving Dart?
Where Dart customers move next
5 destinations Dart can migrate to.
How a Dart migration works
Four steps, Dart-specific
Connect
API token (bearer) per user, configured via the DART_API_TOKEN environment variable or `dart login` from the CLI. Auth flow and bearer schema documented in the public OpenAPI spec at app.dartai.com/api/v0/public/docs/. into Dart. Scopes limited to read-only on the data we move.
Map
We translate Dart-specific structures (custom fields, objects, value lists) to the destination's model.
Sample
Test with a 50–200 record subset to validate Dart quirks before production.
Migrate
Full migration with Dart rate-limit handling. Rollback available throughout.
FAQ
Dart migration FAQ
Answers to the questions buyers ask most during Dart migration scoping. Not seeing yours? Book a call.
Can't find your answer?
Walk through your Dart migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationOther project management tools we support
Ready when you are
Migrate Dart.
Without the rebuild.
Free scoping call with a migration engineer. Tell us about your Dart setup and destination — written quote back within a business day.