How to migrate XLSForms from KoboToolbox to ODK, SurveyCTO or Zoho
Moving off Kobo takes four jobs: export your data, convert or rebuild your forms, carry your record IDs across, and run both tools side by side for one cycle. If the new tool reads XLSForm (ODK, SurveyCTO, Ona, Survey123), form conversion is usually a day’s work per complex form. If it doesn’t (Zoho, CommCare, Avni), you are rebuilding, and that is a project.
This guide is the practical companion to our comparison of KoboToolbox alternatives. Read that first if you haven’t decided whether to switch.
Step 1: Export everything before you change anything
Do this even if you think you’ll keep the Kobo account.
- For each project, download the XLSForm (in Kobo: project → More actions → Download XLS).
- Export data as XLSX or CSV with “include media URLs” and download the media as a ZIP. Media links stop working once the project is gone.
- Keep the system columns: _uuid, _submission_time, _id, _validation_status. The _uuid is your only permanent link back to the original record.
- Save the form version history if you changed the form mid-collection. Old submissions may have questions that no longer exist.
- Note every linked project (dynamic data attachments) and every choice list loaded from a CSV.
Step 2: Convert the XLSForm (ODK, SurveyCTO, Ona, Survey123)
ODK and Kobo share the XLSForm standard and Kobo uses ODK’s tools, so most Kobo forms upload to ODK Central with no changes or only small ones. Upload the file and read Central’s warnings line by line.
SurveyCTO needs more edits. Its conversion guide for Kobo forms is the source for the mapping below.
| In your Kobo XLSForm | In SurveyCTO |
|---|---|
| settings sheet optional | settings sheet required, with form_title, form_id, version |
| relevant | relevance |
| guidance_hint | hint |
| label::Hindi (hi) | label:hindi |
| image, audio, video columns | media:image, media:audio, media:video |
| range question | select_one with likert appearance |
| acknowledge | select_one yesno |
| hidden | calculate |
| today, username | calculate with today() or username() |
| jr:choice-name() | choice-label() |
| position(..) | index() |
| xml-external and instance(...) lookups | Server datasets and pulldata() |
| instance::, bind::, body:: columns | Not supported, remove or rework |
| style, namespaces in settings | Not supported |
Test on a real phone, offline. Fill the form in airplane mode on the cheapest device your team uses, with the language your enumerators use. Most migration bugs show up in skip logic and translated labels, not in the desktop preview.
Step 3: Rebuild when the target isn’t XLSForm (Zoho, CommCare, Avni)
When a partner moves to a Zoho Creator system, we don’t convert the XLSForm. We use it as the specification:
- The survey sheet becomes the field list. Each select_one list becomes a lookup or dropdown.
- Repeat groups become their own forms. A “household members” repeat in Kobo becomes a Members form linked to a Household record. That one change is what lets you track people over time.
- relevant logic becomes field rules or workflow conditions.
- Calculations that only existed to tidy exports often disappear, because the system stores clean data in the first place.
Zoho Forms has its own builder too, and is fine for simple intake. If you need records that persist across visits, the data should land in Creator (or another database), not in form responses alone. Licensing for these tools often runs through a bundle; our guide to Zoho One for nonprofits explains when the bundle is worth it.
Step 4: Carry IDs and history across
Import historical data so that each old submission keeps its Kobo _uuid in a dedicated field. If your forms recorded a household or beneficiary ID, check it for duplicates before import:
- Same name and village, different ID? Merge or flag.
- Same ID, different people? Usually a reused paper slip. Fix at source.
- Missing IDs? Generate them in the new system and keep the Kobo _uuid as a secondary key.
If you are moving personal data across borders or to a new processor, update your consent notice and data processing agreement. India’s DPDP Rules apply to this kind of move; our DPDP compliance checklist covers notices, retention and processor contracts.
Step 5: Run both for one cycle, then switch off
Pick one district, cohort or round. Collect in the new tool, keep Kobo read-only, and compare counts and key indicators at the end. Then train everyone else and archive the Kobo project, keeping the final export somewhere your organisation, not one staff member, owns.
If your migration is really a move from survey tool to programme system, read when to graduate from KoboToolbox to an MIS before you start rebuilding forms.
Not sure whether you need a new tool or a new system? Take EdZola’s free 10-minute technology assessment. It tells you whether to tune Kobo, switch tools, or move to a programme system, and what to fix first.