A tracker migration means moving a tracking study—the survey you run wave after wave with the same questions—from one survey platform to another.
The questions are the easy part. They’re like the sofa when you move house: big, obvious, and everyone’s watching.
But there’s always a box labelled “Misc.” Codes, routing quirks, export formats, weighting rules. Small things nobody thinks to list until you’re in the new flat and can’t find the kettle.
Why Trackers Break in the Small Stuff
Two platforms can show the same question and store it differently. EEach platform assigns codes differently, handles “None of these” differently, and exports multi-select answers differently. When you rebuild a tracker by retyping it, all those defaults sneak in.
None of them looks like a mistake on screen. The survey runs. The links work. The difference shows up three weeks later, in a trend line with a step in it.
That’s why we treat a migration as a QA job first and a programming job second. Building the new survey is the visible part. Proving it matches the old one is the part that protects the client’s data.
The Tracker Migration Checklist
Work through these before Wave 15 goes anywhere near field. Each item needs a named owner and a clear yes. “Should be fine” doesn’t count.
1. Variable Names and Question IDs
Your tables, dashboards and processing scripts look for variables by name. If Q7_r3 becomes Q7_3, everything downstream breaks. Or worse, it reads the wrong column without complaining.
Check: names match last wave, or there’s a written mapping your DP team has signed off.
2. Answer Codes and Code Frames
Codes are where trend data lives. Brand H at code 8 must still be code 8. “Don’t know” at 99 must still be 99. Watch for platforms that number answer lists 1, 2, 3 by default.
For open ends, carry over the current code frame, including every code added in past waves.
Check: compare codes value by value against last wave’s data map.
3. Routing, Filters and Piping
Logic gets rebuilt in a new system, and small differences creep in. How does the new build treat “Don’t know” in a filter? Does piped text still show the respondent’s own answer?
Check: send test respondents down every route and compare who sees what with the last wave.
4. Exclusive Answers and Validation
“None of these” should clear the other ticks. A numeric question should still reject 999 hours of TV a week. These rules are often settings, and settings don’t copy over.
Check: try to break every exclusive answer and every validation rule.
5. Randomisation and Rotation
Answer order affects answers. If brands rotated before, they rotate now, with “Other” and “None of these” still anchored at the bottom.
Check: rotation rules, anchored items and block randomisation, one by one.
6. Screener and Quotas
Who gets in, who gets screened out, and when a quota closes. A different screen-out point can change your sample without anyone noticing.
Check: quota definitions, screen-out points and overquota handling match the last wave.
7. How Questions Look
A question that looks different can get answered differently. Grids may turn into a stack of single questions on mobile. Scales may flip direction. Look hardest at the mobile view, because that’s where many respondents take the survey.
Check: screenshots of old and new, side by side, on desktop and mobile.
8. Data Export and Data Map
Multi-select answers can export as one 0/1 column per option, or as a single list of codes. Dates, labels and variable types can change too. Your processing scripts expect last wave’s format.
Check: export test data from both builds and run last wave’s processing script on the new file.
9. Weighting
Weighting targets, and the variables they use, need to exist in the new data with the same codes.
Check: run last wave’s weighting on the new test data and compare the weights.
10. Translations
A multi-country tracker moves every language version, not only the master. Each one has its own wording history.
Check: every language version against last wave’s approved text.
11. Trend History and the Change Log
The move has to bring the story too: past data files, the change log, known trend breaks and the footnotes that explain them. Without it, the next programmer starts from a script with no memory. We wrote about why that hurts in We Fixed That Last Wave. Didn’t We?
Check: the change log is up to date and lives with the project, not with one person.
How to Check the Box Labelled “Misc”
Don’t eyeball it. Two surveys that look identical on screen can still store answers differently.
The reliable check compares data, not screens:
- Run the same set of test respondents through the old and new builds.
- Export both data files.
- Compare them variable by variable and code by code.
- Explain every difference, or fix it.
If you can, follow with a soft launch and compare early results with last wave before full field. A step in the trend that early is cheap to fix. A step in the debrief is not.
Most of what goes wrong in a migration is a copy-over problem in a new place.
Where to Go Next
Want to see where automated QA and testing sit in a full project? Our Platform Workflow shows all six steps, from specs to clean data.
And for one email a month on trackers, QA and the work behind clean data, sign up for the CodexMR newsletter.
