How to Migrate from Qualtrics to Sprig: A Migration Guide

Example H2

Introduction

Migrating a survey program off Qualtrics takes five decisions in order. Audit what is actually still fielding, because a long-running programme usually accumulates more dormant instruments than live ones and only the live ones have to move.

Decide where your Qualtrics history is going to live, since Sprig documents no way to import historical survey responses from any source, which means your archive generally lands in a warehouse or a frozen export instead of in the new platform.

Rebuild the instruments rather than converting them, because the QSF file Qualtrics exports is readable only by Qualtrics and no public specification exists for it.

Plan for the tracked number to move. Changing platform changes how the question is administered and who is reachable to answer it, and both of those move a satisfaction score independently of anything your customers did.

Then find whoever owns your Qualtrics contract and read the termination clause, because the export deadline is contractual, it is specific to your agreement, and Qualtrics publishes no general post-termination data return period.

Most migration content typically treats this as an export-and-import exercise. It is not one. The instruments get rebuilt, the history stays behind, and the tracker takes a discontinuity that has to be measured rather than hoped away.

This guide covers:

Audit first, because the inventory decides the scope and most of it will not need to move
Rebuild instruments from a rendered questionnaire, since no interoperable survey-definition format exists
Archive Qualtrics history outside both platforms, as of September 2026 Sprig documents no response import
Treat the tracker break as a measurement problem with a bridge study, not a reporting inconvenience
Stop before you start if you need FedRAMP, since Sprig documents none

This is Sprig's own guide to moving onto Sprig. It is not a Qualtrics-endorsed migration path, and Qualtrics has not reviewed it. Platform capabilities and documentation cited here were verified against qualtrics.com, docs.sprig.com and sprig.com on September 17, 2026, and quoted passages are attributed to their source. No product prices for either platform appear anywhere in this guide.

What a migration actually involves

A survey platform migration is four separate projects that teams routinely mistake for one. Each generally has a different owner, a different failure mode, and a different deadline.

The four projects

The first is the instrument rebuild. Every survey that will keep running has to exist again in the new platform, and the rebuild is typically manual because no interoperable format moves a questionnaire between vendors.

The second is the data archive. Historical responses have to go somewhere durable, and where they go is a decision rather than a default.

The third is the measurement bridge. Any metric you report over time will move when the platform changes, and separating that movement from real change requires an overlap you plan in advance.

The fourth is the administrative cutover. Accounts, roles, single sign-on, integrations and downstream consumers all point at the old platform until somebody repoints them.

Why treating it as one project fails

The four have different critical paths. The archive is driven by your contract's termination date, which is often the hardest deadline in the programme and frequently the last one anyone checks.

The bridge is driven by your reporting calendar, and it generally has to start before the cutover rather than after it, which is the sequencing mistake most likely to be discovered too late to fix.

What this guide assumes

It assumes you have already decided to move, and that you have decided on Sprig specifically. The case for the decision lives in the comparison guide, the case for the shortlist lives in the Qualtrics alternatives roundup, and this page is the execution.

Read those two first if the decision is still open. Read this one if the decision is made and the question is how.

It also assumes a real programme with live trackers and downstream consumers. A team running three ad-hoc surveys a quarter can skip most of this and rebuild in an afternoon.

What does not port

This is the section to read before you commit to a date. Most of a Qualtrics programme typically moves with effort, and a specific set of things does not move at all.

One distinction runs through everything below. Where Sprig's documentation describes no equivalent, the honest statement is that it is not documented, not that it is unsupported.

A capability can exist without a docs page, and a reader planning a migration needs to know which claim they are acting on.

Question types with no documented Sprig equivalent

Fifteen Qualtrics question types have no counterpart documented on docs.sprig.com. Any instrument built on one of these commonly needs redesign rather than migration.

Hot Spot
Heat Map, as a question type
Highlight
Drill Down
Side by Side
Constant Sum
Pick, Group and Rank
Signature
Slider and Graphic Slider
Timing
Meta Info
Gap Analysis
File Upload
Captcha Verification
Descriptive Text and Graphic as standalone question objects

The one that catches Qualtrics veterans

Sprig documents a Heatmap. It is not the Qualtrics Heat Map question type.

Sprig's Heatmap is a study type that records where users click on a live page in your product. The Qualtrics Heat Map is a question that shows a respondent a static image and asks them to click on it.

Those are different instruments answering different questions, and a migration plan that maps one to the other will generally discover the difference during the rebuild.

The two that break real programmes

Authenticator has no documented Sprig equivalent, so any instrument that authenticates a respondent against a contact list before letting them in has no documented path.

Web Service has no documented Sprig equivalent either, so any instrument that calls an external service mid-flight has no documented path.

Both need redesign, not migration. Say that out loud to whoever owns the instrument, early, because these are the ones that turn a migration into a rebuild of the underlying research design.

Survey flow constructs

Qualtrics survey flow is a programmable graph. Sprig documents question-level logic rather than a flow object, and the gap is where enterprise instruments actually break.

| Qualtrics element | Documented Sprig equivalent | |:----------------------------------:|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:| | Branch | Skip Logic and Display Logic, with no flow-graph object | | Embedded Data element | None. The nearest is user Attributes, set by SDK, API or CSV, which is inbound targeting data rather than an in-flow variable you set and branch on mid-survey | | Randomizer over blocks or elements | Randomization, narrower, and documented as mutually exclusive with Response Piping | | Authenticator | None documented | | Web Service | None documented | | Table of Contents | None documented | | Reference Surveys | None documented | | Groups | None documented | | Text Sentiment topic branching | None documented as a flow construct | | Quotas | Partial. Response-based only, Enterprise only, criteria limited to Multi-Choice Single Select, Rating Scale and NPS. Quotas cannot be deleted or have their criteria changed after launch, and quota-filtered response views show a maximum of 3,000 responses |

The Embedded Data row is typically the one that surprises people. Teams use it as a general-purpose variable, setting values mid-flow and branching on them, and the Sprig equivalent is an attribute you set before the respondent arrives.

Partial ports, and why the restriction matters more than the mapping

A question type that exists in both platforms is not automatically available in your study. Sprig documents availability restrictions on several types, and a mapping table that marks these as a clean Yes is misleading.

Rank Order, Recorded Task and MaxDiff are Enterprise-only
Conjoint is available to Enterprise teams on link surveys only
MaxDiff is only available on Surveys in Standard Format
Validated Text is not available on Heatmap or Replay studies
Consent and Legal is only available on In-Product studies and Surveys
Video and Voice is not supported on Feedback Studies, and not supported in HIPAA-compliant environments

That second-order gap belongs in your inventory. An instrument can often map cleanly on question type and still be unfieldable in the channel you were planning to use.

What does port cleanly, so the list above stays in proportion

Most of a working programme moves. Single and multi select multiple choice, open text, matrix tables, NPS, rating and Likert scales, skip and display logic, answer-option randomization and standard screening all have documented equivalents.

A team whose instruments are built from those will find the rebuild tedious and not difficult. The list above matters because the exceptions are concentrated in the specialist instruments that senior researchers own, which is also where the political cost of a surprise is highest.

One near-match worth checking rather than assuming

Qualtrics Captcha Verification has no documented Sprig equivalent, and Sprig documents a Bot Detection feature. Those address the same problem through different mechanisms, and whether Bot Detection satisfies whatever drove you to add Captcha is a question to answer with your own requirement in hand.

That pattern recurs across the mapping. A capability that solves the same problem differently is neither a clean port nor a blocker, and the only way to tell which it is for you is to name the requirement before comparing the features.

How to use this section

Run your live instruments against the three lists above before you agree a migration date. Every hit is either a redesign, a channel change, or a conversation with the instrument's owner about whether the study still needs to exist.

The output of that pass is the real scope of your migration, and it is generally smaller than the instrument count and harder than the instrument count suggests.

Who should not migrate

Five readers should stop here, and one of them should stop permanently. This section exists because a migration discovered to be impossible in month three is more expensive than one never started.

If you have a hard data-residency requirement, get it in writing first

This one is typically more complicated than it gets reported. Qualtrics operates regional data centres and markets a data-isolation tier, and a European deployment is an established part of its offer.

Sprig's documentation says nothing about where data is hosted. There is no region statement, no residency option, and no hosting-location page in the documentation index.

Sprig's privacy policy is broader still, stating that information "may be transferred, processed, and stored anywhere in the world, including, but not limited to, the United States or other countries, which may have data protection laws that are different from the laws where you live."

If your programme carries a contractual or regulatory residency commitment, that documentation gap is not a detail to resolve later. Get a written answer from Sprig before you plan anything else, because the answer decides whether there is a migration at all.

If your reporting depends on defensible significance testing, plan for the gap

Qualtrics Stats iQ names its tests and its assumptions and runs a defined set of them, listed in full in the concession section later in this guide.

Sprig documents no significance testing anywhere in the product and publishes no equivalent estimation methodology.

That does not block a migration, and it does change who does the statistics. If a methodologist currently signs off your reporting on the strength of what the platform computes, they will be signing off on analysis done elsewhere after the move.

If your instruments depend on Authenticator, Web Service, or specialist question types

The section above lists them. A packaging study built on Side by Side grids, an allocation exercise built on Constant Sum, or a panel instrument that authenticates against a contact list is not a migration candidate as specified, though it is often still a redesign candidate.

That is a different conversation with a different budget, and it should happen before you commit to a date.

If you field offline, or across many languages

Qualtrics documents 97 language codes and ships an Offline App. Sprig documents AI Translations and multi-language surveys, no offline collection, and no comparable published language inventory.

Intercept research in low-connectivity environments does not move. A ten-market tracker might, and you should check the language list against your actual markets rather than against a count.

The pre-migration audit

Run this before you agree a date with anyone. The audit typically takes about a week for a mid-sized programme and it is the difference between a scoped project and an open-ended one.

Check the plan tier before anything else

A large share of what this guide describes is documented as Enterprise-only on Sprig, and discovering that in the rebuild phase is expensive. Confirm your plan tier covers the following before you scope anything.

SAML single sign-on
Quotas
Rank Order, Recorded Task and MaxDiff question types
Conjoint, which is additionally restricted to link surveys
Email delivery from Sprig
The AI File Upload Builder, the rebuild on-ramp this guide recommends
GDPR data access, erasure and opt-out functionality

If your programme uses several of these and your plan does not cover them, that is a commercial conversation to have before a migration plan, not during one.

What to inventory

Start with what is fielding, not with what exists. A long-running account accumulates dormant instruments, and the count in the interface is not the scope of your migration.

For every instrument still collecting responses, record the owner, the channel, the fielding cadence, whether it feeds a tracked metric, and who consumes the output downstream.

That last column is generally the one nobody fills in, and it is the one that produces the surprise. A survey with a dashboard nobody looks at is a different migration risk from one whose output lands in a board pack.

The audit checklist

Work in this order. Each step narrows the next.

List every instrument that has collected a response in the last twelve months
Mark which of those are still actively fielding against which are finished
For each active instrument, name a single owner who can approve a redesign
Record the delivery channel, since channel restrictions in Sprig constrain what can be rebuilt where
Flag every instrument that uses Authenticator, Web Service, or a question type with no documented equivalent
Flag every instrument that feeds a metric reported outside the research team
Identify which reported metrics have a target, a threshold, or a year-over-year comparison attached
List every downstream consumer: dashboards, warehouses, BI tools, scheduled exports, and anyone receiving a recurring email
Find the contract, and name the person who owns the termination and data-return clause
Record the contract's termination date and the export deadline it implies
Confirm who can authorise an export of the full response history
Check whether any instrument carries contact-list data that was never written into the survey flow

The item nobody checks

The two contract items near the end of that list. Someone owns your Qualtrics contract, and that contract sets your real export deadline.

Qualtrics publishes no general post-termination data retention or data return period. What it does publish is a disaster-recovery window, stating that when a user deletes data "all backups of said data for disaster recovery purposes will be deleted within 90 days," alongside the position that "customers are responsible for routine back-up of their data."

So the deadline is contractual and unknown by default. Pull your own agreement, find the clause, and treat the date it produces as the hard constraint the rest of the plan is built around.

One trap worth naming

The page published at qualtrics.com/master-services-agreement is not the customer agreement. It is Qualtrics' agreement with its own suppliers. It refers to the counterparty as "Contractor," it gives Qualtrics the termination rights, and its seven-year records clause is an obligation owed by a vendor to Qualtrics.

Anyone skim-reading that page looking for their data-retention terms will mis-cite it. Your terms are in your own signed agreement, and they generally are not public.

Exporting from Qualtrics

Qualtrics documents its exports unusually well, and the mechanics matter more than they appear to. Two toggles and one timing decision determine whether what you extract is usable in five years.

The QSF is not an interoperability format

Qualtrics exports a QSF, which it describes as a "Qualtrics Survey Format" file that "can act as a backup or as a means of transferring a copy of your survey to another Qualtrics account."

Three things about it decide your rebuild strategy. It contains "all of your survey formatting and settings." It "does not contain any of the survey responses." And, in Qualtrics' own words, "it's a special file format only Qualtrics can read."

Qualtrics publishes no schema or specification for the format, and warns readers against editing the file at all. So the QSF is a transfer format between Qualtrics accounts rather than a portable record of your instrument.

What that means in practice

The only reliable portable record of your survey logic is a rendered print or PDF of the instrument, plus a logic matrix you build by hand.

That is an unglamorous instruction and it is the true one. Export the QSF anyway, because it costs nothing and it is the only complete artifact if you ever return to Qualtrics, and do not plan any part of the rebuild around a machine reading it.

The rendered PDF is not just a fallback. It is the input to the rebuild path described later in this guide, so produce it deliberately rather than as an afterthought.

Response export formats and the one published cap

Qualtrics documents exports in CSV, TSV, Excel, XML, SPSS, Google Drive, User Submitted Files, Tableau, JSON and NDJSON, with JSON and NDJSON available through the API.

The only hard ceiling Qualtrics publishes is on width: "If your dataset contains over 100,000 columns, then you will not be able to export the dataset."

No row cap, file-size cap or truncation rule is documented. Report that as not documented rather than as unlimited, because the absence of a published limit is not a published absence of limits.

One practical ceiling binds well below the documented one. Qualtrics notes Excel's own column limits, which are far below that figure, so an XLSX export of a wide dataset typically hits a spreadsheet constraint long before it hits 100,000 columns.

Also worth knowing before you choose a format: "XLSX files cannot be imported back into Qualtrics."

The two toggles that decide whether the archive is readable

The first is values against labels. Exporting values gives you the Recode Value for each answer choice, and exporting labels gives you "full answer choice text."

Export both. A numeric archive without a codebook is generally unreadable within a few years, and the label export is your codebook. This is the single cheapest insurance in the whole migration.

The second is how multi-value fields are handled, alongside the options to recode seen-but-unanswered questions as -99 and to export viewing-order data for randomized surveys.

Qualtrics documents an incompatibility between viewing-order export and multi-value splitting when randomizer blocks share a name, so check that combination against your own instruments.

Two traps in the response export

The first is contact data. Qualtrics states that if contact list information "was not included in the contact list at the time the members took the survey, retroactively adding the Embedded Data fields to the Survey Flow will not add that information to the downloaded data later."

Contact attributes never written into the flow are not recoverable after the fact. If your analysis depends on a segment attribute that lives only in the directory, that link is already broken for historical responses.

The second is header stability. Export headers are not guaranteed to be the human-readable field names you see in the editor, particularly for long embedded-data field names and for columns inside randomized blocks.

Qualtrics' own advice applies directly here, and it is the right instruction for a migration: generate sample data and check its downloaded form before you rely on the real export.

Do that on a real instrument, not a toy one, and read the header rows rather than the data.

The directory export has a scope surprise

XM Directory exports to CSV or TSV, optionally with contact statistics and Contact ID.

The scope behaviour is worth reading twice. Qualtrics states "It doesn't matter which contacts are selected. All contacts will be included in the export," and that "Filters and searches also do not narrow down the contacts included in the following export."

What does not come out is typically harder to establish. Opt-out state as a portable field, transaction records, distribution history and segment membership do not appear in any documented export field list.

Treat those as not documented as exportable rather than as impossible to export, and ask before you assume either way.

On the API

Qualtrics acknowledges that API limits exist, referring to "your brand's API request limits," and does not publish the numbers.

Figures circulating in third-party integration documentation are not Qualtrics-published and should not be planned against as though they were.

If your export is large enough that rate limits matter, ask Qualtrics for your brand's figures in writing before you schedule the extraction window.

The historical data decision

This is the section that will change your plan. As of September 2026, Sprig documents no way to import historical survey responses from any source, and the consequence runs through the whole migration.

What the documentation shows

Sprig's documented API surface is six endpoints. Purge Visitors, Upsert a User and Retrieve a User operate on users and visitors. Retrieve Responses, Retrieve Surveys and Retrieve Themes are read-only.

There is no create, import or upsert endpoint for responses. The three retrieval endpoints get data out and nothing documented puts response data in.

CSV import exists and is scoped elsewhere. Sprig documents it for "Bulk uploading of user attributes" and "Bulk uploading of Users for creating Manual Groups," requires that "The CSV file must have a column corresponding to the User ID field," and notes that on a match "Existing attribute values will be overwritten." That is an audience-targeting mechanism rather than a data-migration one.

One naming trap is worth flagging. Sprig's API documentation contains the phrase "Data Import API," and it appears as a navigation instruction for finding an API key, not as an endpoint.

Nothing documented under that name imports responses. Anyone scanning for a migration path will commonly find that string and misread it.

Date this claim, because it may not hold

State the position with its date attached, as this guide does. Platform capabilities change often, and a negative finding about a vendor's documentation is exactly the kind of claim that goes stale without announcing itself.

If you are reading this some months after publication, check the current documentation before building a plan on the absence. Verify it yourself rather than trusting a dated page, including this one.

The asymmetry, stated honestly

Qualtrics does document response import, and a guide that skipped that would be selling and not informing.

Qualtrics accepts CSV, TSV or TXT, states that "The maximum file size is 100MB," states that "you cannot import formulas or bucketed fields," overwrites the RecordedDate on import, and advises customers to "Contact your Customer Success Representative or your Account Executive prior to importing historical responses as this may require an update to your license." It also notes that imported responses are excluded from Sensitive Data Policy redaction.

So the platform you are leaving can take historical data in and the platform you are moving to, as documented today, cannot.

That is a real asymmetry and it belongs in your planning rather than in a footnote.

Where the history should actually live

The answer is neither platform. Make the archive a named migration step with an owner and a completion date, not something that happens implicitly when someone downloads a file.

A warehouse is generally the strongest option where you have one. Loading the full response export into the same place your product and revenue data lives means the history stays queryable and joinable after both survey platforms are out of the picture.

A BI layer is the next best, where the archive lands somewhere your analysts already work and the dashboards that depended on Qualtrics get repointed at the archive instead of retired.

A frozen file archive is the floor, and it is frequently better than most programmes achieve. That means the labelled and the coded exports of every instrument, the rendered questionnaires, the codebooks, and a written index, stored somewhere with a retention policy and an owner.

The archive is a privacy object, not just a data object

This is the step most migration plans skip, and it is the one with a regulator attached. You are about to move years of response data, and possibly a full contact directory, into a system that was not designed to hold it.

Inventory the personal data before you load anything. Response files commonly carry email addresses, user IDs, free-text answers that mention names, and embedded attributes nobody remembers adding. A directory export carries more.

Decide what actually has to move. An archive kept for trend analysis usually needs the responses and the segment attributes, and rarely needs the contact identifiers.

Stripping direct identifiers before load is generally cheaper than governing them afterwards, and it has a consequence you have to plan for. An archive with no way back to a person cannot service an erasure or access request, which is either the point or a problem depending on what you promised. If you need to keep that capability, hold a pseudonymous key in a separate controlled store instead of carrying identifiers into the archive itself.

Set a retention period and write it down with an owner. A frozen archive with no retention policy is an indefinite liability, and "we kept everything in case someone asks" is not a policy.

Work out how you will honour an erasure request or a subject access request against the archive once Qualtrics is gone. That capability lived in Qualtrics, and it does not come with the CSV. Someone has to be able to find and remove one person's responses from a warehouse table, and that procedure should be written and tested before the old platform is switched off rather than discovered during a request.

One related detail from the export side. Qualtrics notes that imported responses are excluded from Sensitive Data Policy redaction, which is worth knowing if your Qualtrics data itself includes responses that were imported from somewhere earlier.

What the archive has to contain to be worth keeping

Store both export forms, values and labels, for every instrument. Store the rendered questionnaire alongside the data, because a response file without the question wording is a column of numbers.

Record the fielding dates, the sampling approach and the channel for each instrument. Those are the facts that let a future analyst judge whether a historical number is comparable to a current one, and they are never in the export.

Write the index as a document a new hire could follow. The archive's real test is not whether it exists but whether someone who was not part of the migration can find a number in it two years later.

Mapping question types

This is the working artifact of the migration. Build the table for your own instruments and keep the restriction column, because the restriction is more often the blocker than the mapping.

How to read the table

Three verdicts, used strictly. Yes means a documented equivalent exists without an availability restriction relevant to your channel. Partial means an equivalent exists with a restriction that is named in the row.

Not documented means Sprig's documentation describes no equivalent, which is different from Sprig not having one.

The rule that keeps this table honest

Never write "not supported" where "not documented" is the accurate statement. A reader will generally act on the difference, and the two claims carry different risks.

If a mapping matters enough to change your plan, ask Sprig directly and get the answer in writing. A documentation gap is a question to resolve in place of a conclusion to draw.

What to do with each verdict

A Yes row rebuilds directly. Budget the rebuild time and move on.

A Partial row needs a channel check before anything else. Confirm the instrument's delivery channel and plan tier against the restriction, because the mapping being available in principle does not make it available in your study.

A Not documented row is a decision, not a task. Someone has to decide whether to redesign the measure, drop it, or keep that one instrument running somewhere else.

That decision needs the instrument's owner in the room and it should happen during the audit rather than during the rebuild.

Rebuilding logic and survey flow

Question types are the visible part of the migration. Flow is typically where the hours go, and where the instruments that cannot move reveal themselves.

The shape of the difference

Qualtrics survey flow is a separate object. You build a graph of branches, randomizers, embedded data assignments and authenticators, and the questions hang off it.

Sprig documents logic at the question level, through Skip Logic and Display Logic, without an equivalent flow-graph object. Most instruments that use branching for routing typically rebuild fine. Instruments that use flow as a programming surface do not.

Translating a branch

A Qualtrics Branch evaluates a condition and routes the respondent. In most cases that becomes Skip Logic on the question that precedes the split, or Display Logic on the questions inside each arm.

The rebuild is mechanical and it is frequently not lossless. A branch that nests three levels deep and reconverges becomes a set of per-question conditions that no longer displays as a single readable structure, and the logic matrix you built during the export is what keeps it maintainable.

Write the matrix before you rebuild, not after. Reconstructing intended logic from a half-rebuilt instrument is typically harder than transcribing it from a rendered questionnaire.

Embedded data is the common surprise

Teams commonly use the Embedded Data element as a general-purpose variable. They set a value mid-survey, branch on it later, and pass it into the response record.

Sprig's nearest documented construct is user Attributes, set through the SDK, the API or a CSV upload. That is inbound data about the respondent, established before they reach the survey, and not a variable you assign during it.

So the two patterns divide cleanly. Embedded data used to carry information about the respondent into the survey ports to attributes. Embedded data used as in-flow state does not port, and that instrument needs a different design.

Randomization is narrower than it looks

Sprig documents randomization of page and question order, randomization of answer options in several question types, and feature-order randomization inside a Conjoint question.

Two constraints matter for a rebuild. Randomization is documented as mutually exclusive with Response Piping, so an instrument doing both in Qualtrics has to give one up.

And random assignment of a respondent to one of several conditions is not documented at all. If your Qualtrics instrument uses a Randomizer to run a monadic design, showing each respondent exactly one of N versions, there is no documented Sprig equivalent and that study needs a different approach.

The two with no path

Authenticator and Web Service. Both were named earlier and both belong here again, because this is the section where their absence becomes a work item.

An instrument that authenticates a respondent against a contact list before entry has no documented Sprig equivalent. The nearest available pattern is a link survey distributed to a known list, which is a weaker control and may not satisfy whatever requirement drove the authentication.

An instrument that calls an external service mid-flight has no documented Sprig equivalent either. The nearest pattern is to fetch the data beforehand and set it as a user attribute, which works when the value is known in advance and does not when the whole point was to look it up live.

Neither of these is a rebuild. Both are research design decisions, and the earlier they surface the cheaper they are.

Rebuilding the instrument in Sprig

There is a documented on-ramp here, and it is the most useful thing in the migration toolkit. It is generally not a converter, and knowing the difference is what makes it usable.

The AI File Upload Builder

Sprig's Design Agent documents a File Upload Builder that reads a document and drafts a study from it. It accepts a ".pdf or .docx file for upload," up to 25 MB, and it is "Available on all enterprise plans."

What it does, in Sprig's own description, is process the file, select the study type as either a Survey or an In-Product Survey with the choice changeable afterwards, generate the study questions and response options, then validate the survey, present the final draft and present a Design Agent audit log.

Sprig describes the result as "a complete survey in under 2 minutes."

That is the missing piece. The QSF is unreadable by anything except Qualtrics, and the rendered PDF of your questionnaire is a first-class input to Sprig's builder.

The artifact you were producing anyway as a fallback is the artifact the rebuild path actually consumes.

How to feed it

Format the document rather than dumping it. Sprig documents a structure the builder reads: a header carrying the study title and goals, numbered questions each ending in a question mark, the question type in brackets after each question, and prefixed directives for the rest.

The documented prefixes are REQUIRED:, SKIP LOGIC:, DISPLAY LOGIC: and RANDOMIZE:. Multi-question pages are marked with [Page 1 Start] and [Page 1 End] blocks.

This is typically where your logic matrix earns its keep a second time. The matrix you built from the Qualtrics export is close to the input format the builder wants, so the transcription step is short.

What it will not do

Two question types are excluded. Sprig states "Not yet supported via AI File Upload: MaxDiff questions and adding prototype links to questions," and both have to be added by hand afterwards.

Multi-question page blocks carry their own exclusions and cannot contain Consent and Legal, Text or URL Prompt, Video and Voice, or prototype links.

And the accepted file types are PDF and DOCX only. A CSV export of your question bank is not a documented input, so converting it is a step you own and one the documentation does not describe.

It drafts, it does not decide

The output is an editable draft presented for review before launch. Treat it as a fast first pass that still needs the rebuild checks: question wording against the original, answer options against the original, logic against your matrix, and channel availability against the restriction column of your mapping table.

The builder is quick enough that the temptation is commonly to accept what it produces. The cost of a mistranscribed answer option is a broken trend line, so review it against the source questionnaire instead of against your memory of it.

The MCP route, for teams who want it scripted

Sprig documents an MCP connector that exposes study configurations, responses and themes, and can create a draft study. It works with a documented list of eleven clients including Claude.ai, Claude Code, Claude Cowork, ChatGPT, OpenAI Codex, Google Gemini CLI, Microsoft GitHub CoPilot, Cursor, Figma, Linear and Notion.

The constraints are specific and they are worth knowing before you plan around it. "No study can be launched from the AI client. Launching studies can only be done via the Sprig UI." Bulk creation is not supported, and Sprig states "It is one by one for now." Templates are not available through it, only custom prompts.

The retrieval tools return up to 1,000 at a time. Administrators enable and can revoke the connection org-wide from a single control. Confirm the role required to use it against the current documentation, since that detail is easy to get wrong when planning who does the rebuild.

So the MCP is a drafting surface rather than a migration pipeline. For a programme rebuilding twenty instruments it is generally a reasonable way to work.

For two hundred, the constraint that studies are created one at a time is the number to plan against.

The order that works

Rebuild the instruments that feed a tracked metric first, because those are the ones that need to be running in parallel with Qualtrics before the cutover.

Rebuild the high-volume operational instruments second, since they typically generate the feedback that catches configuration errors quickly.

Leave the long tail until last, and use the rebuild as an opportunity to kill the ones nobody could name an owner for during the audit.

A migration is often the only moment a survey programme gets a free cull, and programmes that skip it carry the dead weight for another five years.

The measurement discontinuity

This is the chapter that makes the difference between a migration and a reporting incident. Changing platform changes mode, rendering and often sampling frame at once, and the tracked number moves for reasons that have nothing to do with your customers.

A reader who migrates a tracker mid-year and reports the step change to an executive team has published an artifact as a finding. The whole point of this section is to stop that happening.

Two effects, not one, and the literature only measures the smaller

A platform migration changes two things at once, and keeping them apart is what makes this section useful.

The first is mode. How the question is administered and rendered changes the answer, and this is the effect the published literature measures.

The second is sampling frame. Who is reachable changes when the channel changes, and a programme moving from an emailed list to an in-product intercept is not surveying the same population.

An in-product intercept typically reaches people who are currently active and signed in. An email list includes dormant users, churned customers and people who have not opened the product in a year.

Those are different populations, and the difference between them is not a mode effect. It is specific to your product and your channels, and no published study estimates it for you.

How large is the mode effect

Pew Research Center measured the mode component directly. In "From Telephone to the Web: The Challenge of Mode of Interview Effects in Public Opinion Polls" (2015), Pew fielded 60 questions to "3,003 respondents who were randomly assigned to either the phone or Web mode and interviewed July 7-Aug. 4, 2014."

The headline result is that mode effects were fairly common and typically not large, with "a mean difference of 5.5 percentage points and a median difference of five points across the 60 questions." The differences ranged from 0 to 18 percentage points, and eight items differed by at least 10 points.

Read that as a measurement of one component rather than as a forecast for your migration. Pew randomly assigned equivalent samples to the two modes, which equalises the frame in expectation and isolates mode.

Your migration does not hold the frame constant, so Pew tells you what the mode component looked like in one well-designed comparison and nothing about the frame component in yours. Do not carry 5.5 into a plan as an expected value.

The distribution is what matters for a survey programme. Most items moved a little and a few moved enormously, and the few were not random.

The items that move most are the ones you track

Pew's largest effects landed on satisfaction and social-desirability items. On satisfaction with family life, Pew reports that 62 percent of phone respondents said they were "very satisfied" against just 44 percent of web respondents. An 18-point gap on a single satisfaction item.

That is precisely the family your NPS, CSAT and brand tracking metrics live in. A programme whose tracked metrics are all subjective evaluations is the programme most exposed to a mode change, which is generally most programmes.

And you cannot tell which number is right

Pew is direct about this, and the full sentence is worth quoting instead of the clause everyone quotes: "there is no way to determine whether the telephone or the Web responses are more accurate, though previous research examining questions for which the true value is known have found that self-administered surveys generally elicit more accurate information than interviewer-administered surveys."

Read that carefully, because the second clause matters. The new number is not automatically the wrong one. A migration discontinuity is not a data-quality verdict on either platform, and it is uninterpretable without an overlap.

House effects say the same thing about organizations

Mode is not the only thing that changes. Schumann, D., Shamon, H. and Hake, J.-F. (2020), "The Importance of House Effects for Repeated Public Opinion Surveys," International Journal of Public Opinion Research 32(4), 769 to 779, DOI 10.1093/ijpor/edz039, document systematic differences attributable to which organization fielded a survey, persisting "even if the survey agencies use identical question wordings or target populations."

That is the precise analogue of a platform switch. Same questions, same population, different infrastructure, and typically different numbers.

Selection against measurement, and why it needs an overlap

Vannieuwenhuyze, J., Loosveldt, G. and Molenberghs, G. (2010), "A Method for Evaluating Mode Effects in Mixed-Mode Surveys," Public Opinion Quarterly 74(5), 1027 to 1045, DOI 10.1093/poq/nfq059, separate two things a migration confounds.

Selection effects are that "different types of respondents choose different modes." Measurement effects are "the influence of a survey mode on the answers respondents give."

Identifying them separately requires a comparable benchmark running alongside. That is the methodological justification for a parallel run, and it is generally the reason an overlap is not optional for a programme that reports a number anyone acts on.

The precedents disagree in shape, and both are instructive

The CPS Parallel Survey. Ahead of the 1994 redesign, the US Bureau of Labor Statistics ran a Parallel Survey from July 1992 to December 1993 alongside the Current Population Survey, on "a separate monthly sample of households approximately one-fifth the size of the regular CPS sample."

Its finding: "Our best estimate of the combined redesign effects on the annual average unemployment rate is an increase of .56 percentage point." A redesign of a national tracker moved the headline number by more than half a point, and establishing that took eighteen months of parallel collection at a fifth of the main sample.

The University of Michigan Surveys of Consumers. Michigan moved from phone to web and did it about as carefully as the method allows. Their announcement describes "over seven years of running a parallel data collection via the web alongside the official phone data collection," a graduated crossover of 75 percent phone and 25 percent web in April 2024, an even split in May, 25 percent phone and 75 percent web in June, and all web from July.

They report that "the Index of Consumer Sentiment exhibits a remarkably strong 0.97 time series correlation between the two data collection methods," and they anchored the design to the AAPOR task force recommendations on exactly this kind of transition.

And Michigan still got a structural break

Here is the part a migration guide has to carry honestly. Cummings and Tedeschi, writing in Briefing Book in October 2024, estimated that "the effect of the methodological switch from phone to online is currently resulting in sentiment being 8.9 index points, or more than 11 percent, lower," with the effect "significant at the one percent level."

Michigan's own a priori estimate had been a 6.6-point effect on the overall index. The observed shift was larger than the institution that ran a seven-year overlap expected, which is the part worth sitting with.

The break was also concentrated rather than general. Against the current conditions index the estimated effect was "a substantial -18.67 points," while against the consumer expectations index it was "only -2.55 and not significant."

Michigan responded, arguing that the index "captures the same underlying information from consumers" and that month-to-month trends are unaffected.

What that actually teaches

Both things are true at once, and the reconciliation is the lesson. A 0.97 correlation and a 9-point level shift are not in conflict, because correlation preserves shape and says nothing about level.

So a parallel run buys you the ability to detect and argue about the break. It does not prevent the break.

Which means the question to ask about your own metrics is not whether they will move. It is whether anything downstream depends on the level.

A team that reads direction month over month came through Michigan's transition fine.

A team with a numeric target, a contractual threshold, or a comparison against a historical absolute did not.

Find those before you migrate. Every metric with a target attached is a conversation with whoever set the target, and that conversation goes far better before the number moves than after.

Is there a standard for this

There is a standard that names the obligation, and no published rule for how long an overlap should run.

The US Office of Management and Budget's "Standards and Guidelines for Statistical Surveys" addresses it in Guideline 1.1.3, which advises agencies to "Develop adjustment methods, such as crosswalks and bridge studies that will be used to preserve trend analyses and inform users about the effects of changes." OMB defines a bridge study as one that "continues an existing methodology concurrent with a new methodology for the purpose of examining the relationship between the new and old estimates."

Note that this is a Guideline and not a Standard in OMB's own structure, which makes it recommended practice rather than a requirement.

It is still the clearest published statement that the obligation is to quantify the effect instead of to avoid it.

No duration appears anywhere. The honest framing is that the published precedents range from eighteen months at a fifth of sample to seven years of shadow collection, and that the right length for your programme comes from a power calculation and your seasonal cycle rather than from a number someone published.

Do not let anyone talk you into "three months in parallel" as though it were a standard. It is not one.

Designing the bridge study

What a bridge study is

A bridge study runs the same measure on both platforms, over the same period, to the same population, and compares the results.

It is the instrument that tells you whether your reported series is continuous across a platform change.

It is often the most valuable thing you will build during the migration, and the thing most likely to get cut when the timeline slips.

The comparison is the bridge, and what it produces is an estimate of the platform effect on your specific metric.

Without it, any movement in the number after cutover is uninterpretable. With it, you can say how much of the movement was the platform and report the rest as a finding.

What to hold constant

Everything except the platform. That is the whole design and it is typically harder than it sounds.

Hold the question wording identical, character for character, including the scale labels and the order of the answer options. Hold the scale length identical, because changing the number of points moves the score on its own.

Hold the fielding window identical, running both in the same calendar period in place of sequentially. Hold the invitation identical where the channel allows it.

What to vary

The platform, and only the platform. Every other difference you allow in becomes part of the estimated effect and cannot be separated from it afterwards.

The frame problem, which most migrations cannot design away

The instruction to hold the sampling frame identical is easy to write and often impossible to follow. If your Qualtrics arm is an emailed list and your Sprig arm is an in-product intercept, the two frames cannot be made the same, and a bridge that ignores this measures mode and frame together without being able to report either.

There are two honest responses and you should pick one deliberately.

The first is to restrict both arms to the intersecting population. Field both to users who are active and signed in during the window, which makes the frames comparable and isolates the platform effect properly.

The cost is that your estimate now applies only to active users, so the offset you derive does not necessarily transfer to the dormant part of your base.

The second is to accept the combined effect and report it as combined. Run each arm through its natural channel, measure the total difference, and state plainly that the result contains both a mode component and a frame component that this design cannot separate.

The first answer is better science. The second is sometimes the only one available, and it is still far better than no bridge, provided you label what it measures.

What you must not do is run mismatched frames and report the result as a mode effect.

The bridge study specification

Write this down before you field anything. A bridge study you cannot describe on one page is one you will not be able to defend when the number moves.

| Element | What to specify | |:---------------------:|:------------------------------------------------------------------------------------------------------------------------------------------------------:| | Metric | The single tracked number this bridge is protecting, named exactly as it is reported | | Instrument | The frozen question wording, scale and answer options, identical on both platforms | | Population | The eligibility rule, identical where the channels allow it, with the frame named. Where the frames cannot be matched, both named as a stated confound | | Sample per arm | Derived from the smallest platform effect you need to detect, not from convenience | | Fielding window | The same calendar period on both platforms, long enough to cover one seasonal cycle if the metric is seasonal | | Channel | Named per arm, with any unavoidable difference recorded as a confound | | Primary comparison | The difference in the reported statistic between arms, with a confidence interval | | Secondary comparisons | The full response distribution, not only the summary score, since level shifts often hide in the distribution | | Decision rule | The result that would license declaring the series continuous, written before you see the data | | Adjustment plan | What you do if the result shows a shift: restate history, publish an offset, or break the series and say so |

Sizing it

The sample comes from a power calculation on the difference you need to detect, and the effect sizes in the mode-effects literature are the place to start.

A programme whose decisions turn on a 2-point move needs to detect a 2-point platform effect, and that is a much larger study than one whose decisions turn on a 10-point move. Work backwards from the smallest difference that would change something.

The decision rule is the part people skip

Write down in advance what result would let you say the series is continuous, and what result would force you to break it.

Deciding that after seeing the data is how a programme talks itself into continuity it did not earn. The Michigan case is instructive here too, because a 0.97 correlation is genuinely reassuring about shape and tells you nothing about the level shift that turned out to matter.

What to do when the bridge says the series broke

Three honest options. Restate the history by applying the estimated offset to prior periods, which generally works when the effect is a clean level shift and is indefensible when it is not.

Publish the offset alongside the new series and let readers do the arithmetic, which is the most transparent option and the one that generates the most questions.

Or break the series, state the date, and start again, which is the cleanest and the least popular. It is also what a national statistical agency does, and it is frequently the right answer when the effect varies across the distribution instead of shifting it uniformly.

Users, roles, SSO and provisioning

This is the administrative half of the cutover, and it contains one real operational regression that belongs in your plan and not in a surprise.

What Sprig documents

Sprig documents SAML 2.0 single sign-on, available on Enterprise plans, with setup pages for six identity providers: Auth0, Google Workspace, KeyCloak, Microsoft Entra ID, Okta and OneLogin.

Roles are five: Admin, Developer, Editor, Editor Lite and Viewer. Provisioning is documented three ways, manually, through domain-based team discovery, and through single sign-on.

What is not documented

SCIM does not appear anywhere in Sprig's documentation. For a Qualtrics customer running SCIM lifecycle management, that is a genuine operational regression, and it means deprovisioning becomes a manual process owned by somebody rather than an automatic consequence of a change in your directory.

Put that in the runbook with a named owner. The failure mode is typically not dramatic, it is a departed employee retaining access for months because nobody owned the removal.

OIDC is not documented, so a SAML-only assumption is the safe one. Just-in-time provisioning is not documented. SSO enforcement, meaning the ability to disable password login once single sign-on is active, is not documented either, which is worth confirming directly if your security posture requires it.

Compliance, as documented

Sprig documents SOC 2 Type 2, HIPAA, the Data Privacy Framework, GDPR data access, erasure and opt-out functionality for Enterprise customers, regular third-party penetration testing, encryption in transit and at rest, and a minimum TLS version.

It states PCI DSS is inapplicable because it does not handle card data.

Two absences are relevant to an enterprise migration. ISO 27001 is not documented. FedRAMP is not documented at any level, which was covered earlier as a reason not to migrate at all for some readers.

One naming trap deserves a flag. Sprig's documentation uses the phrase "audit log" for the Design Agent's reasoning trail, which is a per-study explanation of the choices an AI made while drafting.

It is not a security audit log, and no security audit log or retention period is documented. Do not carry the phrase into a security review without checking what it refers to.

Integrations and downstream data

The instruments are the visible migration. The pipes underneath them are commonly the one that breaks quietly, weeks later, when a dashboard stops updating and nobody notices for a fortnight.

Inventory the consumers, not the integrations

Start from who receives data instead of from what is connected. An integration nobody uses can generally be dropped, and a scheduled CSV that lands in someone's inbox is a consumer even though it appears in no integration list.

For each consumer record what they receive, how often, in what format, and what happens if it stops. That last column decides your sequencing.

Check the documentation rather than the marketing page

Sprig's integrations marketing page and its documentation index do not perfectly agree. Some integrations named on the site have no corresponding documentation page.

For a migration plan that someone will act on, use the documented list. A named logo is not an implementation guide, and the gap between the two is exactly the kind of thing that surfaces in week three.

Delivery channels have their own restrictions

Email delivery from Sprig is documented as Enterprise-only and available on link surveys only, with an Admin-configured custom sending domain requiring DNS verification, a team-wide Do Not Contact list, and a 24-hour per-recipient cooldown.

Each of those is a plan item. The DNS verification in particular involves a team that is typically not in your migration standup, and it has a lead time.

SMS appears in Sprig's marketing and in passing mentions in the documentation, without a dedicated documentation page describing setup or providers.

If your Qualtrics programme uses SMS distribution, verify the current state directly before you plan around it.

Getting data out, continuously

Sprig documents CSV export, an API with read endpoints for responses, surveys and themes, and states an Enterprise API rate limit of 1,000 queries per second.

The MCP connector is the other route, retrieving up to 1,000 responses at a time.

Design the ongoing extraction before cutover, not after. Whatever populates your warehouse today has a Qualtrics-shaped connector on one end, and rebuilding that is a work item with an engineering owner and a lead time of its own.

The parallel run

The methodologically correct answer is to run both platforms concurrently for a period. The reader is migrating partly to stop paying for two platforms. That tension is real and a guide that pretends otherwise will be ignored.

What the overlap actually costs

Two licences for the duration. Two sets of instruments to maintain, which means every wording change has to be made twice and kept identical or the bridge is worthless.

Two sets of results arriving, which needs somebody to reconcile them rather than quietly preferring whichever looks better.

And a team doing the migration while still running the old programme, which is generally the cost that gets underestimated most reliably.

How to make it affordable

Do not run everything in parallel. Run the bridge, which is a small number of instruments protecting the metrics that carry targets or historical comparisons.

Everything else can cut over directly. An operational survey with no trend obligation, no target and no executive audience does not need an overlap, and treating it as though it does is what makes the parallel run look impossible.

That commonly reduces the overlap to two or three instruments out of dozens. It is a very different conversation with a finance owner than running the whole programme twice.

Sequencing against the contract

The overlap has to finish before the Qualtrics contract does, and the export has to finish before that. Work backwards from the termination date the audit produced.

If the arithmetic does not fit, the options are to extend the contract for the overlap period, to shorten the overlap and accept a weaker bridge, or to cut over without a bridge and break the series deliberately.

All three are legitimate. Choosing by accident, because the dates were never laid out, is not.

Cutover and decommissioning

Cutover is a sequence and not a date. The programmes that do it well typically treat the Qualtrics shutdown as the last step rather than the first.

The cutover sequence

Stop new fielding on Qualtrics for the instruments that have been rebuilt. Keep the account live and keep the data accessible.

Complete the export, including the directory, and verify the export before anything is deleted. Verification means opening the files and checking the row counts and the header structure against expectations, not confirming that a download finished.

Load the archive into its final home, and have somebody who was not involved in the migration find three specific historical numbers in it. That test typically catches more archive problems than any checklist.

Repoint the downstream consumers, one at a time, with the old pipe still running until the new one is confirmed.

Then decommission, and only then.

What to keep

Keep the QSF files even though nothing else can read them. They cost nothing to store and they are the only complete record of the original configuration if a question arises later.

Keep the rendered questionnaires with the data. Keep the export option settings you used, since a future partial re-export needs to match.

Keep a copy of the account's user list and role assignments, because reconstructing who had access to what is a question that frequently arrives from a compliance team six months later.

The deletion decision

Deleting your Qualtrics data is irreversible on a published clock. Qualtrics states that when a user deletes data, "all backups of said data for disaster recovery purposes will be deleted within 90 days."

So a deletion made in error has a recovery window measured in weeks, not years. Do not delete anything until the archive has passed its verification test, and consider letting the contract lapse without an explicit deletion instead.

Validating the migration

A migration is finished when somebody can demonstrate that it worked. These are the checks that produce that demonstration.

Instrument fidelity

For every rebuilt instrument, compare the live Sprig version against the rendered Qualtrics questionnaire, item by item. Question wording, answer options, answer order, scale labels, required flags, and logic conditions.

Do this as a second person rather than as the person who built it. The rebuilder's eye generally reads what they intended, and a mistranscribed answer option is invisible to them and obvious to somebody else.

Data integrity

Field a small number of test responses through every channel the instrument will use, then export them and read the export. Confirm that every question appears as a column, that the values and the labels both come through, and that attributes land where you expect.

Check the export against a downstream consumer rather than against the interface. The interface can render something correctly that arrives malformed in a warehouse.

The bridge result

Report the bridge comparison formally, with the estimated platform effect and its confidence interval, against the decision rule you wrote before fielding.

State the conclusion in the words the decision rule used. Either the series is continuous by the rule you set, or it is not and here is the offset, or the result is inconclusive and here is what that means for the next reporting cycle.

The access and consumer check

Confirm that every person who needs access has it, at the right role, and that everyone who left during the migration does not. Without SCIM, that check is necessarily manual and should be scheduled rather than assumed.

Confirm every downstream consumer is receiving data from Sprig and that the Qualtrics pipe can be switched off without anything going dark.

The way to confirm that is to switch it off for a day with everyone warned, not to reason about it.

Sign-off

Name the person who declares the migration complete and write down what they are certifying. In practice that is typically instrument fidelity, archive verification, bridge reporting, access correctness and consumer continuity.

A migration without a named sign-off does not end. It just gradually stops being discussed, and the unfinished parts typically surface individually over the following year.

Where Qualtrics wins

This section is held deliberately. The reader has already chosen to move, they used Qualtrics for years, and they will catch the first thing this page gets wrong about it.

More practically, a capability discovered to be missing mid-migration with a contract expiring is a genuine problem, and it is cheaper to find here.

Statistical analysis you can defend to a methodologist

Stats iQ names its tests and its assumptions, running a defined set that includes Welch's F Test, Games-Howell post hoc, Ranked ANOVA, Fisher's Exact Test, Pearson's Chi-Squared, Pearson's r, Spearman's Rho, Welch's T-Test, Ranked T-Test, Linear Regression and Logistic Regression, with published assumptions and automatic fallback when they are violated.

Sprig publishes no equivalent estimation methodology and documents no significance testing anywhere. Any programme where a methodologist currently signs off on platform-computed statistics should plan for that work to move elsewhere, and should decide who will own it before the migration rather than after.

FedRAMP

Qualtrics holds FedRAMP High authorization, and FedRAMP Moderate for conversational analytics. Sprig documents no FedRAMP of any level. For public-sector and public-sector-adjacent buyers this is decisive rather than comparative.

Data residency and isolation

Qualtrics operates regional data centres and markets a data-isolation tier. Sprig's documentation contains no hosting-location or residency statement at all, and its privacy policy contemplates worldwide processing.

An EU-data-resident programme cannot proceed on documentation alone here. That is a stronger concession than a feature comparison, because the gap is in what is published rather than in what is offered.

Question-type breadth for specialist instruments

The list earlier in this guide is the substance of it. Packaging work built on Side by Side grids, allocation exercises built on Constant Sum, and image-based tasks built on Hot Spot cannot be rebuilt in Sprig as specified.

Survey-flow programmability

Authenticator and mid-survey Web Service calls are the two that matter, and neither has a documented Sprig equivalent. A team that treats survey flow as a programming surface will find Sprig's question-level logic a real reduction in what they can express.

Translation and offline collection

Qualtrics documents 97 language codes, manual and machine translation with published character limits and right-to-left handling, and an Offline App with its own published incompatibility list.

Sprig documents AI Translations and multi-language surveys, no offline collection, and no comparable published language inventory. Field research in low-connectivity environments does not move.

The evidence base behind the two products is not comparable

Qualtrics carries far more third-party reviews than Sprig does, across several separate listings rather than one. Any comparison of headline review scores between the two is comparing a small review base against a much larger one.

If ratings form part of your decision, read the counts alongside the scores and check them yourself on the day, because review counts move continuously and any figure printed in a guide is out of date by the time you read it.

Qualtrics is not standing still

A migration guide that frames the incumbent as legacy dates quickly. At its March 2026 conference Qualtrics announced synthetic panels for US consumers as generally available, described further markets as launching in the first half of 2026, and announced a research hub with AI summaries and recommendations.

Those were the statements made at the time, and whether the later markets shipped on that schedule is worth checking rather than assuming in either direction.

It also made the largest acquisition this category has seen in years. Qualtrics acquired Press Ganey Forsta in a deal announced in October 2025 and closed in May 2026, valued at 6.75 billion dollars.

What that means for any individual product is not public, and this guide does not speculate. What it means for your decision is that the comparison you made twelve months ago is not the comparison in front of you now.

How to use this list

Check each item against your own programme before you commit to a date. Every one of them is cheap to discover now and expensive to discover in month three, and the ones that apply to you should be resolved or accepted in writing before the migration starts.

Common mistakes

Seven that recur, in rough order of how much damage they do.

Treating the migration as an export and import. It is a rebuild. Every hour budgeted on the assumption that instruments convert is an hour that has to come from somewhere else once the QSF turns out to be unreadable by anything but Qualtrics.

Discovering the contract deadline late. The termination clause sets the real export date and it is frequently owned by somebody outside the research team. Programmes that find it in month one plan around it.

Programmes that find it in month four compress the archive step, which is the step where compression causes permanent loss.

Cutting over a tracker without a bridge. The number moves, somebody asks why, and there is no way to answer. Pew measured a mean mode difference of 5.5 points with the largest single satisfaction item reaching 18, so this is not a hypothetical risk on exactly the metrics most programmes track.

Migrating everything. The instrument count in the interface is rarely the number that still matters. A migration is the only moment a programme gets a free cull, and skipping it means carrying the dead weight into the new platform and paying to rebuild it.

Accepting the AI-drafted rebuild without checking it against the source. The File Upload Builder is fast enough to be trusted more than it should be.

A mistranscribed answer option produces a broken trend line that typically surfaces a quarter later.

Exporting values without labels. A numeric archive with no codebook is unreadable within a couple of years. Both exports cost the same download and one of them is the key to the other.

Assuming not documented means not possible. Sprig's documentation has gaps, and some of them are often documentation gaps rather than capability gaps.

Where a mapping decides your plan, ask and get the answer in writing instead of concluding from silence in either direction.

How Sprig supports the migration

Three documented capabilities do real work here, and each has a constraint worth knowing before you plan around it.

The AI File Upload Builder turns a rendered questionnaire into a draft study, accepting PDF or DOCX up to 25 MB on Enterprise plans.

It is generally the closest thing to a questionnaire on-ramp and it pairs exactly with the rendered PDF the Qualtrics export produces.

Constraint: MaxDiff questions and prototype links are not yet supported through it and must be added by hand, and CSV is not a documented input.

The MCP connector creates draft studies from a documented list of AI clients, which suits a team that wants the rebuild scripted rather than clicked.

Constraint: studies are created one at a time, templates are not available through it, and "No study can be launched from the AI client."

CSV attribute upload reconstructs your targeting layer, bulk-loading user attributes and users for manual groups against a User ID column.

Constraint: this is targeting data about users, not response history, and existing attribute values are overwritten on a match.

Three absences belong in the same list, because a migration plan needs both halves. No documented response import, so the history stays outside the platform.

No documented SCIM, so deprovisioning is manual. And no documented survey-definition import, so the rebuild is a rebuild.

Frequently asked questions

Can I import my Qualtrics survey responses into Sprig?

As of September 2026, Sprig documents no way to import historical survey responses from any source, so Qualtrics response history cannot be moved into Sprig as documented. Sprig's documented API surface is six endpoints, and none of them creates or imports responses.

CSV import exists but is scoped to user attributes and manual group membership rather than to response data.

Plan for your Qualtrics history to live in a warehouse, a BI layer or a frozen archive rather than in Sprig, and verify the current documentation before you build a plan on the absence.

Can Sprig read a QSF file?

Sprig cannot read a QSF file, and no documented import path exists for one. A QSF is what Qualtrics calls a "Qualtrics Survey Format" file, and Qualtrics describes it as "a special file format only Qualtrics can read." It contains the survey configuration but "does not contain any of the survey responses," and Qualtrics publishes no schema for it.

Export it as a record, and rebuild the instrument from a rendered PDF of the questionnaire instead.

What is the fastest way to rebuild a Qualtrics survey in Sprig?

The fastest documented route to rebuilding a Qualtrics survey in Sprig runs through Sprig's AI File Upload Builder. Render the Qualtrics survey to PDF or DOCX, format it with the structure Sprig's AI File Upload Builder reads, and upload it. The builder generates questions and response options and presents an editable draft, which Sprig describes as producing a complete survey in under two minutes.

It is available on Enterprise plans, accepts files up to 25 MB, and does not yet support MaxDiff questions or prototype links. Review the draft against the source questionnaire before launching.

What does not transfer from Qualtrics to Sprig?

Three things do not transfer from Qualtrics to Sprig: historical responses, the survey definition itself, and roughly fifteen question types with no documented Sprig equivalent, including Side by Side, Constant Sum, Hot Spot, Highlight, Drill Down, Pick Group and Rank, Signature, Sliders and File Upload.

In survey flow, Authenticator, Web Service calls, Table of Contents, Reference Surveys and Groups have no documented equivalent, and the Embedded Data element maps only partially onto user Attributes. Quotas port partially, with documented restrictions on criteria and volume.

How long does a Qualtrics migration take?

There is no defensible general answer for how long a Qualtrics migration takes, and the variable that typically dominates is not the instrument count. It is whether you are protecting a tracked metric, because that requires an overlap period whose length comes from a power calculation rather than a calendar.

The published precedents for platform transitions in national statistics range from eighteen months of parallel collection to seven years. A programme with no trend obligation can often cut over in weeks.

Will my NPS or CSAT score change when I migrate?

Your NPS or CSAT score will probably change when you move survey platforms, and generally not because your customers changed. Pew Research Center measured mode effects across 60 questions and found a mean difference of 5.5 percentage points, with satisfaction items among the largest and one reaching 18 points.

Satisfaction and social-desirability items are the most affected family, which is the family most tracked metrics belong to. Run a bridge study to estimate the effect for your own measure rather than assuming it is small.

How long should I run both platforms in parallel?

No statistical authority publishes a required duration for running two survey platforms concurrently. The US Office of Management and Budget recommends developing "crosswalks and bridge studies that will be used to preserve trend analyses," without specifying a length.

Size the overlap from a power calculation on the smallest platform effect you need to detect, and extend it to cover a full seasonal cycle if your metric is seasonal.

Run the overlap only for the instruments that carry a trend obligation rather than for the whole programme.

When does my Qualtrics data actually have to be out?

Your own Qualtrics contract sets the deadline for getting your data out, and it is specific to your agreement. Qualtrics publishes no general post-termination data retention or data return period. It does publish a disaster-recovery position, stating that when a user deletes data "all backups of said data for disaster recovery purposes will be deleted within 90 days," alongside the position that customers are responsible for their own backups.

Find the termination and data-return clause in your own signed agreement, and note that the master services agreement published on qualtrics.com is Qualtrics' supplier agreement rather than its customer terms.

Does Sprig support SSO and SCIM?

Sprig documents SAML 2.0 single sign-on and does not document SCIM. Single sign-on is available on Enterprise plans, with setup pages for Auth0, Google Workspace, KeyCloak, Microsoft Entra ID, Okta and OneLogin.

SCIM is not documented, and neither is OIDC, just-in-time provisioning, or the ability to enforce SSO by disabling password login.

For a team running SCIM lifecycle management on Qualtrics, deprovisioning commonly becomes a manual process that needs a named owner.

Should we migrate at all?

Four conditions should stop a Qualtrics migration before it starts. Do not migrate if you require FedRAMP, since Sprig documents none at any level. Not without a written answer first if you carry a hard data-residency commitment, since Sprig's documentation contains no hosting-location or residency statement.

Not as specified if your core instruments depend on Authenticator, mid-survey Web Service calls, or specialist question types with no documented equivalent.

And not without planning the statistics elsewhere if a methodologist currently signs off on platform-computed significance testing.

The bottom line

Sequence the work rather than scheduling it. Durations depend on your instrument count, your contract date and whether you are protecting a trend, and no published source supports a general calendar.

The decision nobody plans for

Phase 6a is the one most plans leave out. If the bridge comes back uninterpretable and your contract expires in six weeks, you need an answer that was decided in advance rather than improvised.

Three options exist and all three are legitimate. Extend the Qualtrics contract to finish the overlap, which costs money and buys a defensible series. Cut over anyway and break the series deliberately, publishing the break date and starting fresh, which costs continuity and is what a statistical agency would do.

Or proceed with a weaker bridge and report the offset with its uncertainty stated.

What is not legitimate is cutting over, watching the number move, and deciding afterwards what it meant. Write the three options into the plan at phase 3 so that phase 6a is a decision rather than a scramble.

Three things generally decide whether this goes well. Whether you found the contract clause early, whether you protected the trends that carry targets, and whether the archive is something a new hire could actually use.

If your goal is to leave Qualtrics with your programme intact, the work is real but it is typically bounded, and the bounds come from the audit rather than from the platform.

If your goal is to leave without losing the ability to say what your numbers mean over time, the bridge study is the part that buys that, and it is the part most likely to be cut when the timeline tightens.

Your next step is the pre-migration audit in this guide. It takes about a week, it requires nothing from Sprig, and it turns an open-ended project into a scoped one.