Migrating Your Past Tickets to Siit via MCP

What you can do

If you're moving to Siit from another ticketing system, you don't have to leave your ticket history behind. Connect Claude to Siit, share your export from your old system, and Claude will map, import, and verify your historical tickets — including requester, conversation history, attachments, and original dates — so you keep a full record for continuity, compliance, and reporting.

This is meant for historical tickets: things already closed in your old system. Anything genuinely still open is usually better recreated fresh in Siit, so it benefits from live routing, SLAs, and the Triage Agent going forward, rather than being imported as a static record.

What you need before you start

An export of your tickets from your legacy system (CSV or JSON), including requester, assignee, timestamps, status, conversation history, and attachments. Most ticketing tools support this from their admin console.
A Siit API key with permission to create requests and users — an Owner or Admin can generate this under Settings → API.
A rough mapping of your legacy categories to Siit services. For example, "Zendesk: Hardware" → "Siit: Equipment Requests." Claude can help you refine this once it can see your actual service list.
File URLs for attachments, if you want them migrated. Attachments are pulled from a public HTTPS link (like a pre-signed export link), not uploaded directly — worth checking your export gives you this.
The Siit MCP connected to Claude (Settings → Connectors, or the Claude connector directory).

The end-to-end flow

Share your export with Claude, along with your category → service mapping.
Claude checks your mapping against your live Siit workspace — services, admins — and flags anything that doesn't line up before creating a single ticket.
Claude builds the import from your export, mapping each field to Siit's format (see below).
Claude runs the import using your API key.
Claude verifies the results — pulling a sample of imported tickets back to confirm dates, statuses, requesters, and attachments all landed correctly.

You can do this in one pass or in batches (by date range, by category, or by volume) — ask Claude to break it up however makes sense for your export.

What actually gets migrated

Legacy field	Comes into Siit as	Notes
Subject/title	Title
Body/description	Description
Requester	Requester	Matched by email — Siit creates the person if they don't already exist.
Assignee	Assigned admin	Must already be a Siit admin. Decide upfront how to handle tickets assigned to people no longer at the company.
Category/queue	Service	Based on the mapping you and Claude agree on.
Status	Open or Resolved	A resolved date on the legacy ticket brings it in as Resolved; otherwise it stays Open. Intermediate statuses like "in progress" or "waiting" come in as Open.
Created date	Original creation date	Preserved, so your historical timeline and reporting stay accurate.
Conversation history	Messages	Customer-visible replies and internal-only notes are kept distinct, so old internal notes don't become visible to the requester.
Attachments	Attachments	Supported on the ticket and on individual messages, via a public link.
Custom fields	Custom fields or free-form data	Matched to an equivalent Siit field where one exists, otherwise carried over as a label/value pair.
Priority	Priority	Optional.

What it doesn't do

Workflows and notifications never fire on imported tickets — including if you reopen one later. A two-year-old ticket won't suddenly ping an approver or trigger today's automations.
SLA timers aren't backfilled the way they run on live tickets, since the creation date is set retroactively rather than reflecting a real-time submission.
Approval history isn't recreated as a live approval record. If you need to preserve evidence of past approvals for compliance, that's best captured in a note or custom field rather than expected to show up as an Approval object.

Prompt template

Once your export, mapping, and API key are ready, this is a good starting prompt for Claude:

I'm migrating historical tickets from [previous system name] into Siit. I have the Siit MCP connected, and I have a Siit API key ready.

Here is my ticket export: [attach file]

Here is my rough category → Siit service mapping: [attach or describe]

Please:

1. Check my mapping against our actual Siit services and admins, and flag anything that doesn't match before creating anything.

2. Map resolved tickets to come in as Resolved, and open tickets to stay Open, preserving original creation dates.

3. Keep internal agent notes separate from customer-facing replies.

4. Import the tickets, breaking the work into batches if needed.

5. After importing, pull back a sample of the results so I can confirm statuses, dates, requesters, and attachments look right.

FAQ & troubleshooting

Does this go through Siit's MCP directly? Mostly, but not entirely. Claude uses the Siit MCP to read your services, admins, and existing data, and to verify the results afterward. The actual creation of historical tickets runs through Siit's API import endpoint rather than the MCP itself — the MCP doesn't currently expose a "create ticket" action, by design (ticket creation for live traffic goes through the Triage Agent, workflows, or the API). In practice this is invisible to you: you just talk to Claude, and it uses whichever connection it needs for each step.

Is there a limit on how much I can import at once? Yes — imports are capped at 200 tickets per batch, and roughly 500 attachment downloads across a batch. Claude will chunk a larger export into multiple batches automatically; you don't need to plan this yourself.

What happens if an import batch fails partway through? A single bad row (an unrecognized service, a malformed date, etc.) rolls back that entire batch — nothing partial gets created. This is why Claude checks your mapping against live Siit data before running anything; it's the main

Migrating Your Past Tickets to Siit via MCP

A guide for teams moving from your previous ticketing system to Siit, who want their historical tickets carried over — for continuity, GDPR record-keeping, and reporting — using Claude connected to Siit.