Migrating surveys off Qualtrics: what breaks, what QSF import saves, and a checklist
Moving a survey program between platforms is mostly a metadata problem. Here is what survives a QSF export, what silently breaks (logic, embedded data, quotas), and a field-tested checklist for migrating without losing a wave.
The survey is the easy part
Teams switch survey platforms for the usual reasons: cost, consolidation, a feature gap, a procurement mandate. The switch itself is routinely underestimated, and almost never because of the questions. Question text and answer options move easily. What breaks is everything wrapped around them: branching logic, embedded data, quotas, piped text, and the accumulated tribal knowledge of why the survey is built the way it is. Understanding what travels and what does not is the difference between a two-week migration and a quarter of firefighting.
What a QSF file actually contains
Qualtrics exports each survey as a QSF file: a JSON document describing the survey's structure. Inside is the block layout, every question with its type, wording, choices and validation, the survey flow (the tree of branches, randomizers, and embedded data assignments), quota definitions, and display logic conditions. It is a genuinely complete structural description, which is why QSF import is the standard mechanism for moving Qualtrics surveys anywhere.
What a QSF does not contain matters just as much: no response data (that exports separately as CSV or SPSS files), no contact lists, no distribution history, no workflows or automated actions, and no themes beyond basic look-and-feel references. A migration plan that only accounts for the QSF has planned about 60 percent of the move.
What breaks, in rough order of pain
1. Logic that references platform-specific concepts. Simple display logic ("show Q5 if Q3 = Yes") maps cleanly. The trouble starts with logic referencing Qualtrics-specific constructs: embedded data fields set mid-flow, branch logic keyed on randomizer outcomes, or quota states used as conditions. The importing platform has to translate each construct to its own equivalent, and where no equivalent exists, the condition arrives disabled or dropped. Every migrated survey needs a logic audit, question by question.
2. Embedded data. Fields injected from contact lists or URL parameters underpin personalization, routing, and downstream analysis. The field references travel in the QSF; the pipeline that populates them does not. You are rebuilding the data plumbing (URL parameters, contact attributes, integration payloads) on the new platform, and every piped mention of those fields needs re-pointing.
3. Quotas. Quota definitions may import, but quota counts do not, and quota semantics differ subtly between platforms: what happens at quota-full (terminate, screen out, flag), whether checks run at entry or at the qualifying answer, how cross-quotas nest. If you migrate mid-field, treat quotas as a rebuild with manually seeded targets, not a transfer.
4. Question type mismatches. No two platforms have identical type systems. Signature Qualtrics types (highlight, hot spot, certain slider variants) may have no direct counterpart and get mapped to the nearest equivalent or to a placeholder. The good news: for the types that carry 95 percent of real questionnaires (choice, matrix, text entry, NPS, rating scales), mapping is mechanical and reliable.
5. Piped text. Carry-forward choices and piped answers use platform-specific syntax. Imports translate the common patterns; exotic nesting needs manual attention. Search the imported survey for any leftover raw pipe syntax before fielding.
6. Trend continuity. Not a technical break, but the one stakeholders care about: if question wording, scale direction, or option order shifts even slightly in the move, your tracker has a seam. Decide explicitly which items are frozen verbatim and diff them character by character after import.
A migration checklist that has survived contact with reality
- Inventory first. List every live survey, its logic complexity, embedded data fields, quotas, active distributions, and connected integrations. Kill the zombies; most accounts field far fewer surveys than they store.
- Export everything, not just QSFs. Response data (labeled SPSS or CSV), contact lists, and screenshots of flow diagrams for the three most complex surveys. You will want the reference when auditing logic.
- Import and audit one complex survey before committing the timeline. The gnarliest survey teaches you the real conversion cost; the simple ones teach you nothing.
- Rebuild the data plumbing deliberately: embedded data sources, URL parameters, integration payloads, then re-point every piped reference.
- Rebuild quotas natively and seed counts manually if migrating mid-field.
- Test-field every migrated survey end to end, on desktop and mobile, walking every logic branch with scripted test personas before a single real invitation goes out.
- Run parallel for one wave on your most important tracker if you can afford it. A one-wave overlap is cheap insurance against a discontinuity you cannot repair afterward.
Migrate surveys the way you would migrate a database: inventory, dry run, audit, cutover. The QSF is the schema dump, not the whole database.
Where Sinova360 fits
Sinova360 imports Qualtrics QSF files directly, with automatic question type mapping into its native types, so the structural transfer (blocks, questions, choices, and validation) is a file upload rather than a re-keying project, and every piece of display logic is flagged for a quick, deliberate rebuild in the Logic tab. The surrounding machinery is native rather than translated: quotas, carry-forward, and loop and merge are first-class features you configure once on the imported survey, and exports (including labeled SPSS, Word, and PowerPoint) keep your downstream reporting intact. For the plumbing rebuild, native connectors for Salesforce, HubSpot, Zendesk, Slack, and the rest of the connector library, plus an OData feed for Power BI and Tableau, cover most of what teams had wired into their old account.
However you migrate, hold one rule: the platform is replaceable, the trend line is not. Every decision in the move should be tested against a single question: will wave-over-wave comparisons still be honest after the cutover?