Migrate from another tool

A step-by-step playbook for moving feedback from another tool or a spreadsheet into Quackback, from mapping columns to switching off the old tool.

JM
James Morton
Written By James MortonLast updated 1 day ago

Switching feedback tools is disruptive: users have bookmarks, you have years of history, and it's easy to lose momentum. This guide is a step-by-step playbook for moving from another feedback tool or a spreadsheet into Quackback cleanly, from preparing your workspace to switching off the old tool.

Before you migrate

Set up your Quackback workspace completely before importing anything:

  • boards are created and named
  • statuses are configured (the defaults are usually fine)
  • tags are ready
  • your portal's look is set (logo, theme)
  • sign-in and portal access are configured
  • at least one teammate has admin access

Importing into a half-configured workspace means reconfiguring things afterwards. Get the foundation right first. See Structure your workspace if you haven't already.

Export from your old tool

Most tools can export posts as CSV. Quackback imports one CSV template, so the work is mapping your export's columns onto it.

From another feedback tool

  1. Export your posts from the old tool as CSV.
  2. In Settings > Imports & exports, click Download template.
  3. Map your export's columns onto the template:

Your old tool

Quackback column

Title

title

Description or body

content

Status

status

Category or tags

tags

Board or forum

board

Author name and email

author_name, author_email

Vote count

vote_count

Created date

created_at

Original ID

source_id

Statuses, boards, and tags that don't exist yet are created during the import, and a filled source_id lets you re-run the import without duplicates. See Import and export data for the full format.

Tip: Categories in your old tool often map well to boards. If you had five or more categories, consider consolidating into 2-3 boards and using tags for the rest.

Comments, votes, and internal notes

The in-app import brings in posts and vote counts. To also bring individual comments, voters, and internal notes, use the command-line importer included in the open-source Quackback repository on GitHub (scripts/import). It reads separate CSV files for posts, comments, votes, and notes and writes them through the REST API using an API key from Settings > Developers. It works against Quackback Cloud and self-hosted installs alike.

From a spreadsheet

If you've been tracking feedback in a spreadsheet or form tool, clean it up first:

  1. Add the template headers. At minimum title and content, plus author_email or author_name. Add status, vote_count, and created_at if you have them.
  2. Clean dates. Convert dates to ISO 8601 (2026-01-15T00:00:00Z).
  3. Normalize statuses. Use your Quackback status names or slugs (open, under_review, planned, in_progress, complete, closed).
  4. Remove empty rows and duplicates.

Save as a UTF-8 CSV.

Tip: With fewer than 50 entries, consider creating the most important posts by hand instead. It takes longer but lets you curate quality from the start.

Support history and contacts

The CSV import is for feedback posts. To bring contacts and support history over from a support tool, use the REST API:

  • create or update users (with their attributes) with the users identify endpoint
  • create tickets and add replies to them through the tickets endpoints

Support conversations can't be created through the API, so past chat history stays in your old tool or in an archive. See API overview and the full reference at /api/v1/docs on your workspace.

Clean your data first

  • Remove spam and junk. Don't import test posts or garbage. Start clean.
  • Merge duplicates in the old tool. It's easier in a tool you know than after import.
  • Decide your status mapping. If the old tool had "In Review" and you use "Under Review", decide before importing.
  • Decide what to leave behind. Posts that are years old, have no votes, and are clearly outdated can stay behind.

Note: Do a test import first. Import into one board, check vote counts, dates, and statuses, then import the rest. Catching a mapping error after 500 posts is painful.

Import

Import board by board, starting with your most important board.

  1. Prepare your CSV with the right column mapping.
  2. Import it in Settings > Imports & exports, and check the preview of every row before you commit.
  3. Verify the result:

    • the post count matches your export (minus anything you left out on purpose)
    • 5-10 spot-checked posts have the right title, content, and status
    • vote counts on your top posts are right
    • tags were created and applied correctly
  4. Repeat for each board.

If something looks wrong, it's usually a column mapping issue. Fix the file and run it again; with source_id filled, existing rows are updated instead of duplicated.

Tell your users

Don't surprise people. Tell them what's changing, why, and what they need to do.

First announcement (1-2 weeks before):

We're moving our feedback portal to a new home. All your existing posts and votes are coming with us. We'll share the new link soon. No action needed yet.

Second announcement (on the day):

Our new feedback portal is live at (new URL). Your existing posts and votes have moved over. Here's what's new: (1-2 improvements). Share your next idea at (link).

Announce by email to active contributors (they care most), in your app, and with a notice on the old tool pointing to the new one.

Users have bookmarks and links in chat and support tickets. If you control the old tool's domain, set up 301 redirects from old post URLs to the matching Quackback posts, or at least to your new portal. If you can't, put a "We've moved" notice with the new link on the old tool's landing page.

Switch off the old tool

Don't run two feedback tools side by side. It splits your users and doubles your triage work.

  1. Day 0: the new portal is live, the announcement is sent, and old links redirect if possible.
  2. Weeks 1-2: watch both tools and reply to anything new on the old one with a pointer to the new portal.
  3. Week 2: make the old tool read-only.
  4. Month 1-2: shut it down.

Set the dates in advance and share them: "The old portal goes read-only on March 1 and shuts down on April 1."

Post-migration checklist

  • All boards imported and verified

  • Vote counts correct on high-priority posts

  • Tags clean (no near-duplicates from the import)

  • Status mapping correct

  • Teammates have access to the new workspace

  • Old tool redirects or shows a notice

  • Users notified twice

  • Old tool set to read-only

  • Shutdown date scheduled

Was this helpful?

Your feedback shapes what we write next.