Migrate from Kantree to Microsoft Project

Kantree Workspaces are top-level containers that hold independent project configurations, card-type schemas, views, and automations. MS Project does not have a direct workspace equivalent; each standalone Project plan is a separate file or Planner Plan. We offer two destination paths during scoping: a per-workspace migration that creates one MS Project .mpp file or Planner Plan per Kantree Project, or a consolidated migration that aggregates all Kantree Projects under a single enterprise portfolio in Project Online or Planner Premium. The choice depends on whether the customer needs portfolio-level resource management across all original workspaces.

Kantree Projects hold card collections, groups (columns), and per-project views. Each Kantree Project migrates to a dedicated MS Project file (.mpp) or Planner Plan, preserving the project name, description, start date, and target date. Project-level custom fields map to custom fields on the MS Project Summary Task row. If the customer chooses Planner as the destination, Kantree Project Groups map to Planner Buckets and card collections map to Planner task groups.

Kantree Cards are the atomic work unit with card type, custom field values, assignees, dates, attachments, comments, and relationship links. We migrate each Card to an MS Project Task with the card title as Task Name, start and due dates as Start and Finish, assignee as Resource assignment, and card type mapped to a custom field. Card status (Open, In Progress, Done) maps to Task Percent Complete or a Status custom field. Cards with no dates receive a default duration of 1 day unless the customer specifies otherwise during scoping.

Kantree card types define the available field schema per card category (Bug, Feature, Invoice, Patient). MS Project supports custom fields per task but does not enforce type-specific field sets. We extract the card-type schema for each workspace and create a corresponding set of MS Project custom fields (number, date, text, or flag) with a naming convention that preserves the card type context (e.g., Bug_Reproducible, Feature_Effort_Hours). If the destination is Planner, card type maps to a Planner Label or bucket classification. Card types without any custom fields (plain cards) import as Tasks with no additional field configuration.

Kantree supports 20+ field types. We map text, number, date, single-select, and multi-select fields to equivalent MS Project custom field types (Text, Number, Date, Flag, OutlineCode). Rating fields map to a Number custom field or a Flag for binary complete/incomplete ratings. Kantree formula fields compute dynamically and cannot be stored as a formula in MS Project; we export the last-known computed value as a static Number custom field and document the formula logic for manual recreation or Power Apps computation if needed. Card reference fields map to predecessor-successor links if the relationship is hierarchical, or to a text field listing related card IDs for non-hierarchical M:N relationships.

Kantree supports 1:1, 1:N, and M:N card relationships defined at the workspace level. We map hierarchical parent-child relationships to MS Project outline structure (indented summary tasks and subtasks). Non-hierarchical relationships (related cards, blocked-by, depends-on) map to predecessor-successor links with Finish-to-Start dependency by default. The customer chooses the dependency type during scoping; we document the original relationship type in a custom field for reference. M:N relationships without a natural hierarchy become a text custom field listing all related card IDs.

Kantree comments are timestamped text entries attached to cards with a 2-hour editable window and moderation access. We export comments as MS Project Task Notes (rich text, preserving line breaks and formatting). If the destination is Planner, comments map to the Planner Notes field or to a Planner Checklist item as a workaround since Planner does not have a native per-task comment thread. Comment author and timestamp are preserved in the Notes field header for audit purposes.

Kantree attachments are files uploaded directly to cards via drag-and-drop. We export file metadata and download URLs from Kantree's storage layer and re-upload to the destination's attachment storage. For MS Project Desktop, attachments are stored as linked files or embedded objects in the .mpp file. For Planner or Project for the Web, attachments upload to the associated SharePoint document library or OneDrive. We preserve attachment file names, upload timestamps, and the card-task association. If the attachment count exceeds 5,000 files, we chunk the upload by project and run in off-peak hours to avoid throttling.

Kantree automations consist of KQL-based triggers, conditional branches, and action chains (set field, move card, post comment, copy card). MS Project has no native automation engine. We do not migrate automations as executable code. We extract every active automation rule from Kantree's export API, document its trigger, conditions, branches, and actions in a written inventory, and map each action to a recommended Power Automate trigger and action equivalent. The customer's admin or a Power Automate consultant rebuilds the flows post-migration.

Kantree views are saved configurations of Kanban, Table, Matrix, List, Timeline, Calendar, and Gantt with per-view field selection, filters, and sort orders. MS Project and Planner have fixed view types without saved field selection per view. We export view definitions including filters, sort orders, and visible columns as a written reference document. The customer's admin rebuilds the most critical views in MS Project using its built-in view editor, noting that KQL-powered filters cannot be replicated in Project's static filter model.

Kantree distinguishes between billable organization members, free observers, and external guests. MS Project uses a Resource pool for all assignable individuals. We export all Kantree members with their email, display name, and role. Observers and guests without edit permissions cannot be assigned as Resources in MS Project without converting them to full Microsoft 365 users. We flag each observer and guest account during scoping and the customer decides whether to provision a Project license for each. Active members map directly to Resources with their email as the unique key.