1. Inventory the source estate
Start with the available source content. Record the platform, export method, package format, content counts, item types, media, scoring, metadata, accessibility data, and extensions.
- Keep representative packages from simple, complex, old, and recently edited content.
- Include packages that previously failed an import or required manual repair.
- Record expected counts before conversion so missing resources are visible later.
2. Preserve the original package
Store the source file unchanged with a stable identifier and checksum. The original package is evidence when a reviewer later asks whether a transformation altered the item. Never make the converted model the only source record.
3. Inspect package structure before conversion
Parse the manifest and resource graph first. Confirm that referenced item XML, assessment-test XML, media, stylesheets, and shared resources exist and remain inside the package boundary. Report missing files, duplicate identifiers, unsafe paths, unsupported resource types, and external dependencies explicitly.
4. Classify every transformation
A migration report should distinguish preserved, normalized, transformed, omitted, and blocked content. That vocabulary makes review work predictable. It also keeps an unsupported behavior out of a general success count.
| Classification | Meaning | Required evidence |
|---|---|---|
| Preserved | Meaning and resources carry across without a semantic change. | Source and target identifiers plus validation result. |
| Normalized | Representation changes while intended behavior remains equivalent. | Named normalization rule and reviewer-visible target. |
| Transformed | Content needs an intentional model change. | Before and after preview with approval. |
| Blocked | The target cannot preserve required behavior safely. | Actionable reason and remediation owner. |
5. Review fidelity in the authoring system
Automated validation cannot confirm content meaning, image alignment, or rubric intent. Review representative items in a renderer. Compare source and target behavior.
- Check prompt text, choices, ordering, matching, gaps, coordinates, and media.
- Verify response declarations, correct responses, mapping, and response processing.
- Review standards metadata, source information, language, and accessibility fields.
- Resolve warnings before approval or record an explicit hold.
6. Validate the exported target package
Build the final package through the same production export path used after authoring. Validate XML, manifest relationships, identifiers, asset references, package boundaries, and supported interaction behavior. Then import a sample of the exported package into a second environment to verify that portability is real.
7. Approve in waves
Run a pilot wave before bulk approval. Choose content that spans the item-type and metadata surface, then compare counts, warnings, review time, and remediation patterns. The migration report should make the next wave more predictable, not merely larger.
What QFlowLearn provides
QFlowLearn detects supported formats and keeps source material. It records conversion warnings and requires a fidelity review before QTI 3 export. See the migration overview and evidence library for the public claim and artifact structure.