What Happens to Your Feedback History When You Switch Support Tools?
Short answer: you start closer to zero than you'd like. For Zendesk to Intercom and Jira to Linear, the accounts, users, and structural content (help articles, project fields) generally do transfer, because every vendor building a migration tool wants the new signup to feel populated on day one. Slack to Teams doesn't get that benefit of the doubt: there's no vendor-built importer for either side of it, not even the accounts and channel structure, and the section below on that pair covers why. On the two pairs where a migration tool actually exists, what doesn't reliably transfer is the history layered on top of those tickets and conversations: the tags a support team built by hand, the requester lists behind them, the running count of who asked for what. That layer is usually the reason a feature-request tracking system worked at all, and it's the part every vendor treats as optional.
The honest version of the answer depends on which pair of tools you're moving between, because "migration" means different things to each vendor. Intercom's own guide for switching from Zendesk covers importing users as a CSV list and migrating help center articles in one click, with the organizational structure of your help content preserved. It does not claim that ticket or conversation history comes along the same way. Moving that requires Intercom's separate Inbox Migration path, a distinct project rather than a checkbox in the same import flow. Below is what actually crosses the line for each of these moves, and what a support or product team needs to pull out manually before it's gone.
issue filed·
report writtenWhat Zendesk actually lets you take with you
Zendesk's data isn't locked in during an active subscription. The friction shows up at the boundary of canceling it. Per Zendesk's Main Services Agreement, a customer "may export Service Data" during the subscription term and for 30 days after it ends, and Zendesk "is not obligated to maintain or provide deleted Service Data" past that window. In practice that means the real deadline for a Zendesk migration isn't the day you flip the new tool on. It's 30 days after the old subscription actually terminates, whichever export method you're using.
For anything tagged as a feature request, that export needs to preserve three things: the tag itself, the ticket's requester and organization, and the underlying comment thread the tag was attached to. A view exported to CSV carries the first two easily. The comment thread, the part that shows why the customer wanted the thing, usually needs a slower pull through the Zendesk API or a dedicated migration tool, because CSV exports built for reporting tend to flatten fields rather than preserve full conversation bodies.
What Intercom's importer brings over, and what it skips
If a team runs only the standard CSV and help-content import and assumes conversation history came along with it, they find out otherwise the first time someone searches for a request they know was raised months earlier and gets nothing back. The tag that used to surface it lived on a Zendesk ticket that Intercom's default import never touched. Picking it up requires the separate Inbox Migration path the same Intercom article points to, not an extra checkbox inside the CSV and help-center flow.
Fallbrook Rentals loses its "top requests" list mid-quarter
Fallbrook Rentals is a five-person team building booking software for short-term rental hosts, and Grant Ibekwe handles its support inbox. For two years that inbox lived in Zendesk, and the team had a standing habit of tagging any ticket that asked for something the product didn't do yet, feature-request plus an area tag. Once a quarter Grant pulled a view of open feature-request tickets to build a ranked list for the product roadmap review.
The company moved to Intercom in October, mostly for Fin's AI-resolution rate on routine questions. Grant ran the standard Zendesk-to-Intercom import, and it worked as advertised. Users came over cleanly, and the twelve help center articles migrated with their categories intact. He didn't think about the tags again until he was prepping for the January roadmap review and went looking for the running count on "calendar sync with Airbnb," a request he knew had come up at least a dozen times. He couldn't find it, so he flagged the problem in the team's Slack channel ahead of the meeting rather than walk in guessing:
Grant, in #product-roadmap: "I know we've heard this one a lot, but I can't tell you the actual number anymore. The Zendesk tag had 14 tickets on it in September. Intercom's been live for three months and none of that carried over, so right now it just looks like a request three people happened to mention this quarter."
The requests hadn't stopped. The count just reset the day the tool changed, because the tag was the only place that count lived, and the tag didn't survive the switch. Fallbrook still had 30 days of Zendesk export access left when this came up, so Grant was able to pull the old ticket data by hand and rebuild the list. A team that notices four months later than Grant did wouldn't have that option.
Jira to Linear, and Slack to Teams
The same pattern holds outside support tools, with slightly different mechanics.
Linear's issue importer explicitly maps data from the source tool "to the closest concept in Linear," and says plainly that some source concepts may not carry over. Applied to a Jira Service Management project used for customer requests, the issues, comments, and labels generally map across, but anything specific to how your team encoded "who asked" — a custom field, a linked Confluence doc, a particular label scheme — is exactly the kind of source-specific structure the importer's own framing warns you to check before assuming it's included.
Slack to Teams has no importer at all. Slack's own export documentation describes exports built for legal and compliance purposes or for moving between Slack workspaces. None of it describes a path into Microsoft Teams. A standard export also excludes messages older than a year on some plans and includes only links to files rather than the files themselves. If your product team has been mining a #feature-requests Slack channel by hand, that channel's history doesn't migrate to Teams in any vendor-supported way; someone has to read through it and re-file whatever's still relevant before the Slack workspace goes quiet.
How much volume changes the answer
Below a certain volume, the manual version above is genuinely fine. Export what you can before the retention window closes, read through it once, and re-file anything still open in the new tool. That's a few days of someone's time for a small team with a few dozen tagged requests.
Past a certain volume, that patch stops holding. Once tags are doing real analytical work, like ranking requests by how many accounts asked, telling a customer their year-old request shipped, or feeding a roadmap review that assumed the count was continuous, a manual re-file is only a one-time fix on a system that already proved it doesn't survive a tool change. The same gap reopens the next time a vendor gets replaced.
That's the case for reading feedback where it happens instead of counting it inside whichever tool holds it this year. Modem connects to Zendesk, Intercom, Slack, Jira, and Linear at the same time, classifies every conversation into a topic as it arrives, and keeps the requester and the running count attached to the topic rather than to any one vendor's tag. A migration becomes a source change inside a graph that already existed, not an event that zeroes the counter. We build Modem, so weigh that against your own situation; a wider look at that graph is in what a customer context graph is, and the deeper mechanics of counting requests without a manual tagging step are in how to centralize customer feedback. Below the volume where tags were carrying real weight, the export-and-re-file plan above is the right amount of process.
Before you sign the new contract
Ask the export question before the migration, not after. Find out what the new tool's importer actually claims to bring over, in writing, and what the old tool's terms say about how long you can still pull data once the subscription ends. Put a date on the calendar for the export, inside that window, whether or not the migration itself is finished by then. Fallbrook got its list back because the 30 days hadn't run out. That's closer to luck than plan, and it's the one habit that turns luck into a plan the next time a vendor changes.
