How to migrate off Canny to another feedback tool
Migrating off Canny means three separate jobs, and Canny only makes one of them easy. Pulling your data out is a CSV export or a handful of API calls. Deciding where it goes and remapping it depends entirely on the destination: some tools have an importer, most don't. And keeping customers from hitting a dead board after you cancel is a redirect you have to set up yourself, before the subscription lapses and the domain stops resolving.
There's no "migrate to X" wizard inside Canny itself, but at least one common destination has built its own. Featurebase advertises a one-click importer that pulls existing feedback, changelogs, and users over from Canny, with the feature-table row "One-click import" to prove it. Linear's Customer Requests docs describe a different intake model, from support tools, CRM, email, and Slack, not competitor boards, so a board-to-board move onto Linear has no equivalent shortcut. Either way, an importer only solves one of the three jobs above. It doesn't set up the redirect, and it doesn't touch what you send voters once they're moved. So the honest plan is a real project with a day on the calendar. Export everything Canny holds, or confirm your destination's importer actually caught all of it, pick where it's actually going, and treat the cutover like a launch, not a background task.
The two exports Canny actually gives you
Canny's data lives in two places you can reach without asking support. The API reference documents a secret API key (found under company settings at /admin/settings/api) authenticating calls to posts/list, votes/list, comments/list, boards/list, users/list, and companies/list. Posts and votes paginate by skip and limit; comments, users, and companies paginate by cursor. Between those six endpoints you can reconstruct every board, including who posted what, who voted, who commented, and which company each voter belongs to.
There's also a CSV export in the admin panel for a faster, lower-fidelity pull of posts and their vote counts, useful for a quick backup or a spreadsheet import, but it won't carry comment threads or company attribution the way the API does. If you need the full requester history intact, budget time for the API pull; if you just need a record of what was asked and how many votes it had, the CSV is faster.
Either way, pull this before you touch your subscription:
- Every post, with status, tags, and vote count
- The voter list per post, so you know who to notify when it ships
- Comment threads, since customers often add the context that didn't fit the original post
- Company/organization data if you used Canny's account-based tracking, so you can weight requests by customer value later
Deciding what's actually replacing the board
This is the step teams skip, and it's the one that determines whether the migration is a week of remapping or a permanent improvement. Canny is a public or private voting board built from a post, a vote count, and a status field. What replaces it depends on why you're leaving.
If the complaint is pricing or missing features but you still want a public roadmap customers can browse and vote on, you want another board, something like Featurebase, Productboard, or UserVoice, each compared against Canny directly in our Canny alternatives guide. If your team already lives in Linear, Customer Requests attaches feedback straight to issues instead of running a separate portal. If the real problem is that most feedback never made it to the board in the first place, because it arrived in a support ticket or a Slack thread that nobody copied over, a board of any kind just reproduces the gap, importer or not.
Moving 340 open posts without losing who asked
Here's what this looks like end to end, walked through on a stand-in team (illustrative, not a single customer's story, but built from the pattern most Canny migrations follow). Call the company Loomwork, a project-tracking tool for agencies. Canny had been its public roadmap for two years, and the board had accumulated 340 open posts, a few hundred more closed ones, and a familiar habit: engineers would ship something and nobody remembered to update the post, so the same requests kept getting re-filed.
The board itself wasn't really the problem. Most of the actual demand arrived through the support inbox, and someone had to notice a pattern and manually go post it to Canny before votes even started counting.
The team pulled the full API export, posts, votes, comments, and the company field they'd been populating from their CRM sync, into a spreadsheet as a permanent record. For anything with an open status and at least three votes, they filed a Linear issue by hand, with the voter list pasted into the description. Everything else got archived read-only. They pointed their custom domain at a short static page linking to the new intake channel, and mentioned the move in their next release notes email since that list overlapped heavily with active voters.
The spreadsheet step took an afternoon for a couple of people. The part that actually mattered came after: going back through the support inbox and checking what had been landing there that never made it to a post at all. That was the bigger number.
Redirecting the board so votes don't hit a 404
Once you know the destination, sequence the cutover so customers never land on a dead page:
- Export first, cancel last. Pull the full API export before you touch billing. Canny's pricing page puts even the Business tier at a tracked-user model, and once a plan lapses, admin access to run fresh exports can lapse with it.
- Post the move on the board itself, with a pinned update naming the new destination and a date. Anyone with an open post gets a notification for free, since Canny already emails voters when a post updates.
- Redirect the custom domain, if you used one, to the new tool or to a static "we moved" page, rather than letting DNS point at a cancelled Canny board.
- Re-notify from the new side once requests land in their new home, especially for anything with an in-progress or planned status. A voter who never hears again assumes the request died, even if it's further along than it ever was on Canny.
What the export doesn't fix
The Canny export solves the archive problem of getting your existing posts and votes out before the subscription lapses, and for a straight board-to-board move, a destination's built-in importer like Featurebase's can even skip the spreadsheet step. Neither one touches the reason Loomwork's board undercounted requests in the first place, which is that voting boards only capture the people motivated enough to visit one. Voting boards have a well-documented failure pattern where most feedback happens in support tickets, sales calls, and chat, and never gets copied to the board at all.
issue filed·
report writtenThat's the point where we'd bring up Modem, which we build, so weigh the recommendation with that in mind. Instead of replacing the board with another board, Modem reads the conversations Loomwork already has (support tickets, Slack, sales calls) and cross-references mentions of the same request into one counted topic, with every requester's exact words attached, then files the issue directly in Linear, Jira, or GitHub. There's no portal for customers to remember to visit, and no manual step where someone decides a request is common enough to deserve a post. Pricing is unlimited users on every plan starting at $80/month, with a free tier, rather than the per-tracked-user model Canny and most boards use. See Modem as a Canny alternative for the direct comparison, including where a public roadmap is still the better tool for the job.
If your Canny board mostly gets requests you also handle through Linear day to day, syncing Canny into Linear is worth reading before you migrate away entirely. It solves a real chunk of the status-drift problem above without a full switch, and it's a fair comparison point for what you're trading away by leaving Canny for good.
Before you cancel
Confirm the export ran clean (spot-check a post's vote count and comment thread against the live board), confirm the redirect resolves, and confirm at least one active voter has heard where their request went. Those three checks are cheap, and they're the difference between a migration and a data loss incident with a due date attached.
