Kantata data export: projects, time and resourcing history

What can you export from Kantata?#

Kantata, the professional services platform many firms still call Mavenlink, holds the operating record of a consulting firm: projects and budgets, task plans, time and expense entries, invoices, and the resource plans that decided who worked where. Most of it can be exported, but the route you use decides how much history and how many links come with it.

There are three routes to compare. Report exports from the built-in reporting and spreadsheet downloads from list views are quick and need no developer. The API returns records with their IDs and relationships intact, which is what a migration, a data warehouse or a long-term archive requires.

Object names in the API and in older Mavenlink-era scripts may not match the labels users see in the interface. Confirm current object names, endpoints, permissions and any plan-based limits in Kantata's developer documentation for your edition before scoping the work, and map each interface label to its API object in your data dictionary.

Object by object: what to export and what to watch#

Object-by-object planning keeps an export from missing the records that tie everything else together. The table lists the main record types, a sensible route for each and the gap to verify against vendor documentation and your own configuration, since setups differ widely between firms.

Time and approvals: export the trail, not only the totals#

Time and approval history is the record of who logged which hours to which task, when they submitted them, who approved or rejected them and what changed afterward. Finance usually needs only approved totals, but billing disputes, audits and any later analysis of estimates against actuals need the trail.

A summary report gives hours by person, project and period. A detailed export should carry each entry's date, task, billable flag, the rate applied, notes and approval status. If your configuration records approval events separately, extract them as their own table keyed to the time entry.

• 1Pull time entries with task IDs so hours tie back to the work plan.
• 2Keep the billable flag and the rate in effect on the entry, not today's rate.
• 3Capture approval status, approver and dates where the system records them.
• 4Include entry notes, which often explain an overrun better than any field.
• 5Reconcile totals against invoices for a sample of closed projects.

Resourcing history: snapshot what changes in place#

Resourcing history is the hardest Kantata record to recover after the fact, because allocations, resource requests and forecasts are edited as plans change. A query today shows the current plan. It may not show what the plan looked like when a project was sold or when a staffing call was made.

If that history matters for capacity planning, a migration or later analysis, start snapshots now. A scheduled export of allocations, open requests and utilization forecasts, stored with the snapshot date, builds the history the system does not keep for you.

Compare those snapshots with actual time entries to see where plans and reality diverged. For many firms that comparison, by practice and project type, is the most useful thing their resourcing data can teach them.

Steps to run a complete export#

A complete export follows dependency order, so every record has something to link to when it is reloaded or analyzed. The steps assume a developer or integration partner with API access and someone from operations who knows how the firm configured Kantata.

• 1Read the contract for export rights, post-termination access and data deletion terms.
• 2Export reference data first: users, roles, skills, rate cards, custom field definitions and picklists.
• 3Export clients and projects, then tasks, then time, expenses and invoices, keeping every ID.
• 4Pull attachments and receipts last, each indexed to the record it belongs to.
• 5Run report exports with the same filters and compare totals with the API extract.
• 6Store the result in a format the firm controls, with a short data dictionary.
• 7Test that a sample closed project can be rebuilt end to end from the archive.

Illustrative: an operations consultancy changes PSA after an acquisition#

Illustrative: a fictional operations consulting firm with three practices has run Kantata for years and must move to its new parent's ERP-based PSA. The COO assumes finance's report exports will be enough, until the practice leads ask for estimate-versus-actual history by project type and nobody can rebuild it from the spreadsheets.

The firm hires an integration partner to pull projects, tasks, time entries with notes, invoices and custom field definitions through the API. Past allocation plans cannot be recovered, so the firm starts monthly snapshots for the months before cutover and documents the gap in the data dictionary.

The finished archive answers margin questions by practice, and a new analyst can read it without the original Kantata administrator, who leaves shortly after the integration.

What a Kantata history is worth beyond the migration#

A Kantata history records how a consulting firm actually delivers work: how scopes were estimated, how staffing plans shifted, where hours ran over and why. Those linked records support internal benchmarks and pricing reviews and, after rights and privacy review, may be licensed to AI developers building tools for professional services.

SourceX reviews such archives through the SourceX five-step transaction of Supply, Rights, Preparation, Approval and Delivery, starting from a description of systems and years of history rather than files. The SourceX Enterprise Data Value Framework weighs drivers such as domain expertise, human-generated signal, recency, data cleanliness and rights, and client names, individual rates and personal details are removed or excluded before the firm approves anything.