Systems and records
Kantata project history: exporting before you switch PSA tools
By SourceX Editorial · Updated
Short answer
A Kantata data export before a PSA switch should capture five record families with their native IDs intact: projects and tasks, resourcing, time and expenses, budgets and invoices, and status reports with comments. Migrations often carry over only active work, so export closed projects and full history separately, before the old contract ends.
Key takeaways
- A PSA migration often moves active work only; closed project history needs its own export.
- Every exported file should keep Kantata's native IDs for projects, tasks, people and clients.
- Status reports and comment threads hold the delivery judgment that hours and invoices do not.
- Historical rates and budgets are easily overwritten, so export them as they stood at the time.
- Client confidentiality, not the export mechanics, is usually the hardest question in consulting project history.
What project history does Kantata hold?#
Kantata holds the delivery history of a consulting firm: which projects were sold, who was staffed on them, where the hours went, how budgets held up and what the team reported along the way. Many firms still call it Mavenlink, its earlier name, and older exports and integrations may carry that label.
Map the records before choosing an export path. The record map below is a working starting point; field names depend on how your account was configured, so confirm each family in your own instance.
| Record family | What it captures | Why it matters later |
|---|---|---|
| Projects, phases and tasks | Scope, milestones, owners, dates and status changes | Shows how engagements were structured and where they slipped |
| Resourcing | Resource requests, allocations, roles and skills | Shows staffing decisions against plan |
| Time and expenses | Time entries, approvals, billable flags and expense lines | Ties effort to tasks, people and invoices |
| Budgets and financials | Fees, budgets, bill and cost rates, invoices | Shows margin and overrun patterns by project type |
| Status reports and posts | Status narratives, risks, comments and replies | Holds the reasoning behind decisions in the team's own words |
| Files and attachments | Statements of work, plans and draft deliverables | Often client-confidential and handled separately |
| Custom fields and users | Practice area, industry, client tier and user roles | Needed to segment and rejoin everything else |
Which export paths exist, and what does each keep?#
Kantata history usually leaves through three routes: report and list exports to spreadsheets, the vendor's API, and whatever bulk export your contract provides at the end of the term. Each keeps a different slice, so most firms combine at least two.
Check which routes your plan and contract include before the migration project starts. That answer shapes the timeline more than the volume of records does.
| Export path | Good for | Weak on |
|---|---|---|
| Saved reports exported to CSV or Excel | Time, budgets, utilization and project lists in a familiar format | Comment threads, attachments and change history |
| API pull by a developer or integration partner | Complete records with native IDs and timestamps | Needs someone who knows the data model, and runs into rate limits |
| Vendor-assisted or contractual export | A bulk copy near the end of the term | Timing, format and what the contract actually promises |
| Manual saves of key status reports | A handful of flagship engagements | Scale and consistency |
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
What a PSA switch usually loses#
A PSA switch usually loses the connective tissue, not the headline numbers. Hours and invoices survive because finance needs them; the link between a status comment, the task it concerns and the person who wrote it often does not.
- Comment threads detached from their tasks, or dropped entirely.
- Historical bill and cost rates overwritten by the current rate card.
- Resource requests and soft allocations that never became time entries.
- Deactivated users whose names turn into blanks or generic labels.
- Approval history on timesheets, expenses and change requests.
- Status narratives stored as posts or rich text rather than fields.
- Attachments that exist only as links back to the old system.
Keep the IDs, or the history will not rejoin#
Native IDs are what turn a pile of exports into a usable history. Every file should carry the project ID, task ID, user ID and client ID exactly as Kantata stored them, plus created and updated timestamps.
Build a crosswalk as part of the migration: old project ID to new project ID, old user ID to employee number, old client ID to CRM account. Without it, an old status report cannot be tied back to the hours, the budget or the team that produced it.
Store the crosswalk with the exports and treat it as a record in its own right. It is the first thing anyone asks for when the history is reused for pricing, a dispute or a data review.
Export sequence before the switch#
The export runs alongside the migration, not after it. Start when the new PSA is chosen, and finish before the old contract's end date with enough slack to check the results.
- Confirm who holds admin rights in Kantata and whether API access is enabled for your account.
- Ask the vendor in writing what export support the contract includes at the end of the term.
- Freeze the record map and agree which closed projects are in scope.
- Run report exports for time, expenses, budgets, invoices and utilization across the full date range.
- Pull projects, tasks, status posts and comments with their IDs through the API or a partner.
- Download attachments with their parent project and task IDs.
- Reconcile totals: hours and invoiced amounts in the export should match the system's own reports.
- Store everything in company-controlled storage with a manifest and the ID crosswalk.
Illustrative: an operations consulting firm leaves Kantata#
Illustrative: a fictional operations consulting firm with supply chain and pricing practices moves to a PSA module bundled with its new ERP. The migration partner plans to load active projects and open time only.
The managing partner asks the COO to keep the closed work too. The team exports time, budgets and invoices by year through saved reports, then has a developer pull projects, tasks and status posts with comments through the API. A crosswalk maps old project IDs to the new system and to the CRM.
The outcome: the firm keeps a searchable archive of how engagements were scoped, staffed and reported. When partners price a new pricing-strategy engagement, they compare it with similar past projects instead of relying on memory, using a copy with client names masked.
Client confidentiality in consulting project history#
Client confidentiality is usually the hardest question in consulting project history. Status reports name clients, describe their problems and sometimes quote their figures, and engagement letters often limit how client information can be used.
Separate the firm's own records from client material. Staffing patterns, effort by task type, budget variance and internal reasoning are generally the firm's operating records; deliverables and client data may be owned or restricted by the client. Review engagement terms with counsel before any reuse beyond internal operations.
How SourceX looks at PSA history#
SourceX treats PSA history as project records with outcomes: scope, staffing, effort, budget and the narrative that explains them. Under the SourceX five-step transaction (Supply, Rights, Preparation, Approval, Delivery), the first conversation uses only metadata such as systems, years covered and record families.
If a firm proceeds, the Rights step separates firm-owned operating records from client-controlled material, and Preparation removes client names and personal details. The SourceX Enterprise Data Value Framework explains why connected, human-written status narratives tend to rate higher than hours alone: domain expertise and human-generated signal raise value, while privacy burden and preparation cost reduce net value.
Frequently asked questions
Will the new PSA vendor's migration service bring over closed projects?
Sometimes, but rarely in full. Migration services focus on what the new system needs to run: active projects, open time, current rates and users. Ask for the scope in writing. If closed projects are excluded, export them yourself and keep them as an archive rather than forcing them into the new tool.
What format should the archive use?
Use plain, durable formats: CSV for tables, JSON for API pulls that include nested comments, and original file types for attachments. Add a readme that explains each file, the date range covered and the ID crosswalk. Avoid any format that needs the old system to open.
How long should a consulting firm keep project history?
There is no single rule. Contracts, tax rules and professional obligations set minimums for some records, and the firm's own needs set the rest. Agree a schedule with counsel and finance, keep the business events, and reduce personal details that no longer serve a purpose.
Is old PSA data useful beyond reporting?
Yes. Firms use it to price new work, staff engagements and teach new managers how projects were run. Some firms also license de-identified project records to AI developers building tools for professional services, after a rights review and client carve-outs. Under a license the firm keeps ownership.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.