Migrate your KANNA data
Construction-focused project management platform with integrated task boards, Gantt charts, and photo-reporting workflows. Targets small to mid-size field teams with a per-seat pricing model.
In its favor
Why people choose KANNA
The signal that keeps KANNA on the shortlist. Sourced from G2, Capterra, and customer scoping calls.
Users consistently highlight KANNA's ease of use for team collaboration and task management without a steep learning curve.
The platform combines project management, task assignment, and document/photo reporting in a single tool, reducing the need for multiple systems on field projects.
Per-user pricing with a modest minimum (5 seats) makes it accessible for small to mid-size construction or field teams.
The Gantt Chart and calendar views provide multiple perspectives on project timelines, helping site managers stay on top of phased work.
Custom input fields on project templates allow teams to capture property-specific or client-specific data without relying on spreadsheets.
The minimum 5-seat billing requirement forces small solo operators or two-person teams into paying for unused licenses.
Teams that outgrow construction-only workflows report that KANNA lacks the broader PM capabilities (resource management, advanced reporting) needed for scaling.
Migrating away is difficult because KANNA's native export covers Projects, Customers, Properties, and Reports but not the full historical comment or chat thread history in a portable format.
Enterprise pricing is inquiry-only with no published limits, creating uncertainty for growing teams evaluating total cost of ownership.
Reasons to switch
Why people leave KANNA
The recurring reasons buyers give for replacing KANNA. Presented as facts, not knocks.
Platform scorecard
Strengths, weaknesses, and where KANNA 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
KANNA pricing overview
KANNA uses a per-seat model with a mandatory 5-seat minimum on Light, Pro, and Pro Plus plans, billed annually at a 20% discount or monthly at a higher rate. The Enterprise tier is quote-only and not available in Japan or Thailand.
Light
Tier 1 of 4
$15/user/month (annual); $75/month total (5-seat minimum)
What's included
Need help selecting your Project Management?
Book a free 30 minute consultationPricing is informational. FlitStack AI does not bill on KANNA's schedule — see our quote-based pricing →
What gets migrated
KANNA object support
Object-by-object support for KANNA migrations. Per-pair details surface during scoping.
Projects
Fully supportedProjects are the top-level container in KANNA. They carry a name, status, date range, and belong to a client or property. We export Projects 1:1 and map them to the destination project's equivalent container.
Tasks
Fully supportedTasks sit inside Projects and Sub-projects, support due dates, assignees, and status fields. We migrate tasks with their parent-child hierarchy intact and preserve the original assignee mapping.
Sub-projects
Mapping requiredSub-projects allow work to be broken into phases or sites within a parent Project. Where the destination does not support a Sub-project object, we flatten the structure and mark the parent relationship as a custom property on each Task.
Custom Input Fields (Project Templates)
Mapping requiredKANNA allows customization of input fields via Settings > Customize Settings for Project templates. These fields are template-bound, not global. We capture the field definitions and their values, then map them to destination custom fields by name.
Photo Reports / Photos
Mapping requiredPhoto reports are a first-class export in KANNA's data export feature. We extract the photos and their captions and attach them to the corresponding Task or Project in the destination system.
Documents
Mapping requiredDocuments are associated with Projects and Tasks. We preserve the file and its association during migration; document content itself is not extracted or transformed.
Comments / Chat / Reporting Threads
Mapping requiredKANNA provides in-platform chat and reporting threads on Projects and Tasks. We treat these as comment threads, preserving the author, timestamp, and text content.
Clients / Properties
Mapping requiredThe Data Import/Export feature separately handles customer information and property information. These are distinct data types in KANNA's model. We map them to the destination's equivalent contact or property object.
Gantt Chart Data
Mapping requiredKANNA displays work as a Gantt Chart. The chart data is derived from task start dates, end dates, and dependencies. We export the underlying task dates and reconstruct the Gantt structure in the destination PM tool.
Pipeline Stages / Statuses
Mapping requiredProject and Task statuses in KANNA are configurable per workspace. We capture the full status taxonomy and map each to the nearest equivalent status in the destination system.
Users / Assignees
Mapping requiredUser accounts and task assignments are exported separately. We map each KANNA user to a destination user by email address, and flag any assignee with no corresponding destination account.
| Object | Support | Notes |
|---|---|---|
| Projects | Fully supported | Projects are the top-level container in KANNA. They carry a name, status, date range, and belong to a client or property. We export Projects 1:1 and map them to the destination project's equivalent container. |
| Tasks | Fully supported | Tasks sit inside Projects and Sub-projects, support due dates, assignees, and status fields. We migrate tasks with their parent-child hierarchy intact and preserve the original assignee mapping. |
| Sub-projects | Mapping required | Sub-projects allow work to be broken into phases or sites within a parent Project. Where the destination does not support a Sub-project object, we flatten the structure and mark the parent relationship as a custom property on each Task. |
| Custom Input Fields (Project Templates) | Mapping required | KANNA allows customization of input fields via Settings > Customize Settings for Project templates. These fields are template-bound, not global. We capture the field definitions and their values, then map them to destination custom fields by name. |
| Photo Reports / Photos | Mapping required | Photo reports are a first-class export in KANNA's data export feature. We extract the photos and their captions and attach them to the corresponding Task or Project in the destination system. |
| Documents | Mapping required | Documents are associated with Projects and Tasks. We preserve the file and its association during migration; document content itself is not extracted or transformed. |
| Comments / Chat / Reporting Threads | Mapping required | KANNA provides in-platform chat and reporting threads on Projects and Tasks. We treat these as comment threads, preserving the author, timestamp, and text content. |
| Clients / Properties | Mapping required | The Data Import/Export feature separately handles customer information and property information. These are distinct data types in KANNA's model. We map them to the destination's equivalent contact or property object. |
| Gantt Chart Data | Mapping required | KANNA displays work as a Gantt Chart. The chart data is derived from task start dates, end dates, and dependencies. We export the underlying task dates and reconstruct the Gantt structure in the destination PM tool. |
| Pipeline Stages / Statuses | Mapping required | Project and Task statuses in KANNA are configurable per workspace. We capture the full status taxonomy and map each to the nearest equivalent status in the destination system. |
| Users / Assignees | Mapping required | User accounts and task assignments are exported separately. We map each KANNA user to a destination user by email address, and flag any assignee with no corresponding destination account. |
Gotchas
What to watch for in KANNA migrations
Issues we've hit on past KANNA migrations, tagged by severity. FlitStack AI handles every one — surfacing them up front because buyer engineering teams want to know.
Minimum seat billing regardless of usage
Chat threads and reporting comments may not export cleanly
Custom input fields are template-bound, not global
Enterprise plan not available in Japan and Thailand
No documented public API for automated migration
| Severity | Issue |
|---|---|
| High | Minimum seat billing regardless of usage |
| High | Chat threads and reporting comments may not export cleanly |
| Medium | Custom input fields are template-bound, not global |
| Medium | Enterprise plan not available in Japan and Thailand |
| Medium | No documented public API for automated migration |
Leaving KANNA?
Where KANNA customers move next
5 destinations KANNA can migrate to.
How a KANNA migration works
Four steps, KANNA-specific
Connect
Not publicly documented into KANNA. Scopes limited to read-only on the data we move.
Map
We translate KANNA-specific structures (custom fields, objects, value lists) to the destination's model.
Sample
Test with a 50–200 record subset to validate KANNA quirks before production.
Migrate
Full migration with KANNA rate-limit handling. Rollback available throughout.
FAQ
KANNA migration FAQ
Answers to the questions buyers ask most during KANNA migration scoping. Not seeing yours? Book a call.
Can't find your answer?
Walk through your KANNA 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 KANNA.
Without the rebuild.
Free scoping call with a migration engineer. Tell us about your KANNA setup and destination — written quote back within a business day.