Feedback Tool Migration Checklist
Plan a feedback tool migration with a copyable checklist for exports, field mapping, privacy review, pilot imports, customer links, and rollback readiness.
By Feedbackly · Updated
Product walkthrough
Watch how customers use requests, voting, and status updates on a Feedbackly board.
Watch the product walkthroughSee the destination workflow
Practical context for Feedback Tool Migration Checklist
A feedback tool migration needs two decisions: which customer requests move to the new system, and which historical records stay in a retained archive. Copy this checklist into your planning document and assign a named owner to each check. Completion means the behavior has been verified, not merely that an export file exists.
Keep the original system and export available during the pilot. Test the destination's ownership and publication model before importing the backlog. A public board with one owner can suit a founder's workflow, but it does not preserve private team administration or research access by default.
Copy the migration checklist
Record the source workspace, destination, intended audience, and decision owner first. Identify the records needed for continuity: requests, descriptions, votes, comments, identities, attachments, statuses, private notes, and source links. Mark each as transferred, manually recreated, archived, or excluded.
A missing field is a decision to resolve, not a reason to silently discard history. If your team needs an unsupported capability, keep the relevant system or choose a different destination before the public launch.
Migration owner: [Name] Source and export date: [Workspace, date, applied filters] Destination and audience: [Board, public/private requirements] [ ] Confirm destination access, ownership, and required capabilities. [ ] Save original exports and verify they contain the intended records. [ ] Decide the destination for every data type and private artifact. [ ] Map selected titles and descriptions; retain source IDs in an internal log. [ ] Review content for the destination audience. [ ] Pilot with representative requests and inspect every resulting record. [ ] Verify counts, formatting, duplicates, status, and vote behavior. [ ] Test submission, comments, voting, and a status update where applicable. [ ] Record old-to-new links and the customer communication plan. [ ] Define a stop condition and a return path if the pilot fails. [ ] Approve the public link change after checks pass. [ ] Retain the archive and assign an owner for later questions.
- +Use a separate verification result for each data type.
- +Retain a dated source export and a record of any filters used.
Test a representative sample
Include a short request, a description containing commas, a multiline description, a duplicate, a completed item, and a record with private context. Compare the preview with the source before publishing. Count selected source records, preview records, and published requests separately; deduplication and deliberate exclusions can change those counts.
Feedbackly's CSV setup accepts up to 100 requests per preview, titles of at most 120 characters, and descriptions of at most 5,000 characters. Use explicit title and description headers. Imported requests begin under review with zero votes. Existing identities, votes, attachments, comments, and roadmap statuses are not restored automatically.
- +Check multiline fields and escaped quotes rather than opening only the first row.
- +Review a duplicate before deciding whether it represents repeated evidence.
- +Keep an internal mapping from source record to destination request.
Change customer links after the pilot is accepted
Invite a small group to try the new public feedback path. Confirm they can find a request, add useful context, and understand its status. Record any access or participation problem before changing the link in your app, help center, or customer communications.
Explain which historical information remains available and where customers can ask about an old request. Choose a stop condition such as missing required records or an unusable submission path, and keep the old route available while investigating. A retained export is useful evidence, but it is not a tested way to restore the entire old workflow.
- +Assign the person who changes and verifies customer-facing links.
- +Avoid running two unowned queues indefinitely.
- +Keep cancellation or deletion decisions separate from the import test.
Keep exploring this topic
These next reads help you move from the concept on this page to a framework, tool, template, or deeper comparison you can apply right away.
Questions teams usually ask
Does a CSV export guarantee a complete migration?
No. The export can contain data the destination does not accept. Compare each field and relationship separately, including votes, identities, comments, attachments, and statuses.
Can we import every historical request into Feedbackly at once?
Board setup previews up to 100 requests at a time. Plan the selected backlog within the supported workflow and confirm the process for any larger migration before committing.
Does Feedbackly create these checklist fields in a board?
No. The checklist is for your planning document or internal tracker. Feedbackly provides public requests, comments, votes, and statuses; this template does not add custom migration fields.
Try a small request import before switching
Use Feedbackly's reviewed CSV setup to test selected public-safe requests and check the resulting board before changing your customer feedback link.