Hey everyone. I've been knee-deep in a migration project this month, moving a client from an older help desk to a more modern platform. The biggest hurdle, as always, was getting the historical ticket data across cleanly. It's not just about the text; it's the metadata, attachments, and timelines that really matter.
I wanted to share my step-by-step approach and see how others have tackled this. Here's what worked for us, roughly in order:
First, we audited the source data. We exported a sample of tickets and mapped every field we cared about—status, priority, tags, custom fields, notes, attachments—to what was available in the new system. We found that internal notes didn't always map cleanly, so we had to decide to convert them to public comments or leave them as private based on a flag.
Then came the extraction. We used the old platform's API to pull tickets in batches, being careful with rate limits. For attachments, we downloaded them to a secure bucket with a clear naming convention linking them to each ticket. The actual import used a combination of the new platform's API and CSV uploads for the initial ticket data, then a separate script to re-attach files and preserve the chronological order of replies.
The tricky parts? Maintaining agent and customer IDs for proper user association was a puzzle. We ended up creating a mapping table. Also, some automation rules in the new platform triggered on ticket creation, so we had to temporarily disable those during the import window.
Has anyone else gone through this recently? I'm especially curious about handling satisfaction survey data or migrating SLAs correctly. There are a lot of niche tools and scripts out there now, and I'm wondering if there's a better way for next time.
– John
Always testing.
That extraction step sounds tricky. How did you manage the rate limits on the old API? Did you have to build in delays, or was there a better way?
Also, I'm curious about the attachment bucket. What naming convention did you find worked best to keep everything linked? I'm worried about losing that link during the upload phase.
Totally get that hurdle with internal notes. We ran into something similar with a Freshdesk to Zendesk migration last year. Our solution was to add a custom field in the new system called "Legacy Internal Note" and dump the content there, along with the original agent's name and timestamp. That way the context isn't lost, but the new public comment thread stays clean for the client team. It felt like a good compromise.
Less hype, more data.
The initial audit you described is the part everyone tries to skip, and it always comes back to bite them. I've seen teams jump straight to the API script only to realize halfway through that their status mappings are fundamentally broken because "pending" in the old system had three different underlying meanings.
Your point about deciding what to do with internal notes based on a flag is crucial. That's the kind of business logic that needs to be documented and agreed upon with the client before a single record is moved. It's easy to get lost in the technical extraction and forget that these are judgment calls.
Stay grounded, stay skeptical.