BuildCaster.

Guide · BUILDCASTER

Move your feedback. Know what comes with it.

A migration should preserve the customer problem without inventing a new voting history or signing people up for email. Start with a small, private import and check the result before moving your portal.

We tested the prepared sample below through BuildCaster’s actual importer. It is illustrative data based on Canny’s documented export fields, not a file exported from a Canny account. This is a CSV migration, not a full account transfer.

1. Keep an untouched export

Canny documents two ways to export posts: Board Settings → Export Data, or the download action on the Feedback page after applying filters. Its export documentation lists title, detail, total votes, status and post URL among the fields. Interfaces and headers can differ; match the columns in your actual file rather than assuming the sample is identical.

Keep the original export outside BuildCaster. Make a working copy for cleanup, remove material you should not retain, and split it into files under 400 KB with at most 500 ideas and 20 distinct columns. Preserve source URLs in an extra column if you need to trace a record later. Extra columns are retained privately as source material, not displayed on the public card.

2. Map the meaning, not just the column name

BuildCaster accepts Considering, Planned, Building, Shipped, Declined / Not planned, and Cancelled / Canceled. Normalize an “in progress” value to Building and a “complete” value to Shipped only when those meanings match your actual process. Pending moderation is separate from delivery status: even a Shipped import stays unpublished until reviewed.

Source informationBuildCaster fieldWhat to check
Post titleTitle3–120 characters. Use a clear customer need.
Post detailProblem / desired outcome3–5,000 characters. Remove private support context from the public summary.
Total vote count / scoreImported supportOptional whole number, 0–1,000,000. Remains separate from verified votes.
Post statusStatusOptional. Normalize values first, or omit the mapping to start in Considering.
Your added explanation columnOutcome explanationRequired for Shipped, Not planned and Cancelled. Explain availability or the decision.
Original post URL and other retained fieldsPrivate source materialPreserved as provenance. Not a redirect, identity import or public link migration.

3. Try four example records first

The prepared sample uses fictional product needs and illustrative imported support counts. It covers an undecided request, planned work, a shipped improvement with an availability note, and a declined request with a reason. None of these numbers is a BuildCaster customer vote.

In your workspace, open Settings → Import & export. Upload the sample and map Post Title to Title, Post Detail to Problem, Post Status to Status, Score to Imported support, and Outcome explanation to the explanation field. Preview before importing. The interface reports invalid rows before anything is committed.

Download the prepared CSV example
Actual BuildCaster CSV import preview showing four fictional requests with status and imported support before confirmation.
The real import preview. Check each status and support count here; confirmation adds pending ideas to the Inbox.

4. Check the review inbox before publishing

  1. Confirm the imported count matches the preview. The sample creates four pending records; it does not make four public posts.
  2. Open a record. Check the title, problem, imported support and retained source material. Real verified votes should still be zero.
  3. Check closed outcomes have the intended explanation. Importing a shipped card must not create a release announcement.
  4. Review and approve the records you want your portal’s audience to see. If the sample is only a rehearsal, remove those example records instead.
  5. Continue in small batches. Repeating confirmation for the same preview is safe; uploading the file again creates a new import and can create duplicates.
BuildCaster Inbox after importing four sample requests, each awaiting team review.
After import: pending review, with no new verified votes, followers or release email. The delivery status is retained separately.

What this move does not recreate

If those omissions would break your workflow, pause the move and evaluate the gap. The BuildCaster–Canny comparison describes the broader tradeoffs. The spreadsheet guide covers cleanup and review ownership.

  • Individual voter identities, comments, notification permissions, attachments, custom fields and historical status transitions are not reconstructed as native records.
  • An imported vote total is a legacy count. It does not become a list of verified people and does not enroll anyone in email.
  • Retained source URLs help you trace records. They do not redirect old Canny links to new BuildCaster cards.
  • A CSV import cannot transfer a Canny domain, subscription or complete account. Keep the old archive and plan the portal change separately.

FROM FEEDBACK TO FINISHED

Keep the conversation connected.

A customer portal, a roadmap, and release updates. One record from the first idea to the announcement.