Migrate from Kantata Professional Services Cloud (formerly Mavenlink + Kimble) to monday Work Management

Kantata Workspaces (the primary project container in both OX and SX) map to monday.com Boards. Each Workspace's name, description, status, start/end dates, and budget fields migrate as Board metadata and text columns. Workspace archived state maps to Board archived status. For mixed OX/SX Kantata deployments, we apply the schema-mapping layer during extraction so that SX workspaces (which use Opportunity and Milestone naming in Kantata SX) resolve to the same Board structure as OX workspaces before writing to monday.com.

Kantata Tasks (OX) and Stories (OX) share the same underlying API object and map directly to monday.com Items. Task name, description, status, start date, due date, and custom field values migrate as Item data and column values. The parent Workspace-to-Board relationship is resolved at migration time so Items insert into the correct Board. We preserve task nesting via parent-child relationships that map to monday.com sub-items.

Kantata Subtasks attach to parent Tasks and inherit some parent-level fields, and map to monday.com Sub-items. The WBS numbering that can misfire with deep subtask nesting in Kantata's New Task Tracker is flagged during extraction; we migrate the subtask structure without the WBS path, and document affected records in the migration report for manual verification. monday.com supports unlimited sub-item nesting depth.

Kantata Users (internal staff and contractors) map to monday.com team members. We extract user name, email, role, and permission settings, and resolve by email match in monday.com. Inactive or archived Kantata users are flagged in the migration report; the customer decides whether to provision them as inactive monday.com members or exclude them from the import entirely. Contractor vs employee classification is preserved as a People column value.

Kantata Resource Assignments link a User to a Task within a Workspace, carrying hours allocated, role, and billing rate. We map these to monday.com Items using the People column type, assigning the mapped User to the corresponding Item. The role and billing rate information migrates as separate text and number columns on the Item because monday.com's native resource management capabilities are limited to the Workload view on Pro and above. Rate precision and effective-date handling vary between OX and SX, which we account for during extraction.

Kantata Time Entries record billable or non-billable hours against a task with date, user, and notes. We migrate these to monday.com Items using the Time Tracking column if the customer has the Time Tracking add-on enabled ($10/seat/mo), or as structured updates in the Item's activity log if not. Historical time-entry records that predate the add-on purchase are preserved as a text column recording date, hours, and user. Billable vs non-billable flag migrates as a Status or Label column value.

Kantata Estimates model supply-and-demand scenarios using role-based resource composition and margin projections. monday.com has no native estimate or scenario comparison feature. We migrate estimates as board Items with structured columns for estimate name, total hours, total cost, role breakdown (as text columns), and margin percentage (as a number column). Each versioned scenario within a Kantata workspace migrates as a separate Item linked to the same Board, and we document the version chain in the migration report. Margin and profitability analysis requires rebuilding in monday.com's Dashboards or a separate BI tool.

Kantata Custom Fields are organized by subject_type (Estimate, Story, User, Workspace) with separate API calls required for Custom Field definitions and Custom Field Values. We extract both the field definition (name, type, applicable subject_type) and all values, then map each to the equivalent monday.com column type: picklist becomes Labels or Status; number becomes Number; currency becomes Number with a label annotation; date becomes Date. Custom Fields and Custom Field Values are separate API objects with independent rate limits in Kantata, which we manage during extraction to avoid 429 errors.

Kantata's billing module allows multiple invoices per project, with financial data tied to workspace and resource assignment records. monday.com has no native billing or accounts receivable module. We treat billing records as archived reference data: invoices migrate as Items with structured columns (invoice number, date, amount, status) and the original invoice PDF is attached to the Item as a file. Line item detail referencing billing rates and expense codes migrates as a structured text column. The customer should plan to handle active billing through a dedicated accounting tool post-migration.

Kantata WorkspaceGroups organize workspaces into folders or portfolios and carry their own custom fields. Group-level custom field values require a separate API call scoped to WorkspaceGroup. We map WorkspaceGroups to monday.com Board Folders (if the account has Folders enabled) or use a naming prefix convention on the Board name. Group-level custom fields migrate as columns on the Group's constituent Boards. If the customer uses WorkspaceGroups for portfolio-level reporting, we document the grouping structure in the migration report for manual recreation in monday.com Dashboards.

Kantata SX (formerly Kimble) workspaces may contain External References linking to Salesforce records (Opportunities, Accounts). These links are API-accessible via external_reference_service_model and external_message fields. We preserve the external URL as a Link column value on the corresponding monday.com Item so that the Salesforce relationship context is visible to users. The link does not create a live sync; the customer configures a separate Salesforce integration if bidirectional sync is required.

File attachments live in Kantata's collaboration workspace and activity feed. Attachment URLs are accessible via the Kantata API, and we map these to monday.com File columns on the corresponding Item. File size limits and storage quotas vary per Kantata workspace tier; we flag any attachments that exceed monday.com's file size limits (250 MB per file) in the migration report. Attachments that cannot migrate directly are documented with their source URL for manual re-upload if needed.