Common replacement patterns
Child SharePoint list
Best when repeated rows need filtering, reporting, permissions, or independent lifecycle.
Power Apps collection
Useful for temporary in-form editing before save, often paired with a child list.
JSON column
A lightweight option for simple repeated data, but weaker for reporting and governance.
Questions to answer before export
- Do users need to report on individual repeated rows?
- Do rows need attachments, comments, approvals, or separate ownership?
- Should old XML data be migrated into the new child model?
- How will deletes, edits, and validation work for child rows?
How Form Migrator helps
The analyzer flags repeating regions and includes builder notes so the team can choose a replacement strategy before package generation or manual rebuild work starts.
Common questions
Can repeating sections be fully automatic?
Some simple patterns can be scaffolded, but production-ready repeating data usually needs data-model review.
What is the safest pattern?
A child SharePoint list is often safest when the repeated rows are real business records that need reporting or separate management.
Can I keep the old InfoPath XML?
Yes for historical access, but the new Power Apps experience may still need a more modern data model.