Plan the move before you move the data.
A migration is safer when the source, target, cut-over sequence and fallback are explicit. This checklist is platform-neutral enough to use while evaluating a move from an incumbent mystery-shopping, audit or fieldwork platform.
Know what is moving and what can stay.
Inventory
- List programmes, clients, locations, users, questionnaires, historical results and evidence.
- Identify integrations, exports, scheduled jobs and external questionnaire providers.
- Record retention obligations and data that should not be carried forward.
Ownership
- Name the business owner for each dataset and workflow.
- Identify the source of truth for IDs, statuses and historical dates.
- Agree who can approve mapping, reconciliation and cut-over.
Resolve meaning before format.
Data mapping
- Map source fields to target fields and document transformations.
- Separate required, optional, derived and retired fields.
- Preserve stable identifiers where they are needed for reconciliation.
Data quality
- Identify duplicate users, locations and programme records.
- Resolve invalid statuses, orphaned records and incomplete references.
- Define what will be archived rather than migrated.
Not every connected system has to move on day one.
Questionnaires
Decide whether questionnaires move into the target platform, remain with a configured external provider, or transition programme by programme. Define how completion is evidenced.
Integrations
For each adjacent system, document the event or data flow, authentication, identifiers, retry behaviour, data owner and fallback. Do not assume an incumbent integration translates directly.
Prove the mapping before using production records.
Synthetic data set
- Create representative but non-customer test records for each important programme shape.
- Exercise roles, assignment, questionnaire, evidence, QA and reporting paths.
- Test edge cases such as returned work, withdrawn work and incomplete evidence.
Reconciliation
- Count records at source, transformed stage and target.
- Spot-check dates, identifiers, statuses and ownership.
- Record discrepancies and rerun until acceptance thresholds are met.
Test the sequence and the fallback.
Parallel run
Where appropriate, run a bounded programme or sample in parallel so operational teams can compare workflow and output before the final switch.
Cut-over plan
Document the final source freeze, export, transform, import, reconciliation, user communication and go-live order with named owners.
Rollback / contingency
Define the condition that stops the cut-over, the latest safe decision point, how source access is preserved and how users are told which system remains authoritative.
Decision log
Record who approved go/no-go, the evidence they reviewed and any accepted exceptions. A migration plan reduces risk; it does not make migration risk-free.
Verify the operating system, not just the import.
Operational checks
- Confirm login and role access for representative users.
- Run one end-to-end assignment, submission, review and release path.
- Confirm reports/exports and any agreed integrations behave as expected.
Data checks
- Reconcile migrated record counts and exceptions.
- Verify representative historical records and attachments/evidence.
- Confirm retention/archive decisions were applied as approved.
Stabilisation
- Track defects and migration exceptions separately from training questions.
- Keep the source/archive available for the agreed contingency period.
- Schedule a review after the first live programme cycle.
Download, review, assign owners, then test the plan.
The checklist is intentionally not a promise of an easy or risk-free migration. It gives buyers and delivery teams a structure for making scope, evidence and contingency explicit.