Aem Form XDP to Adaptive form Conversion Approach

Hi ​@subhamsri,

Thanks for the detail on what you've tried so far with AFCS and AI-assisted conversion. What you're running into is expected behavior, not a gap in your approach — it's worth knowing that Adobe's own documentation confirms AFCS does not automatically convert XFA scripts (FormCalc/JavaScript) into Adaptive Form rules, and its Review and Correct editor does not support repeatable panels for XFA-based forms. So AFCS was really only ever designed to solve the layout, field, and basic-validation portion of the conversion — scripts, calculation logic, and repeatable/add-remove sections were always intended to be handled separately.

Given the scale (~2000 forms), we'd recommend treating this as a structured pipeline rather than 2000 individual conversions:

1. Rationalize before converting: Most large XFA estates aren't 2000 unique forms — they're a much smaller number of master templates with copies/variants. Fingerprinting each XDP's structure (field names, bindings, script content, subform occurrence rules) and clustering similar forms typically reduces 2000 forms down to a manageable set of logic patterns (often 50-150). This tells us where to focus automation and manual effort.

2. Automate the AFCS step: AFCS has a hard batch limit (max 15 forms / 50 pages / 10MB per folder), so this needs to be scripted — auto-chunking forms into compliant batches, submitting, and retrieving results — rather than run manually through the UI.

3. Build a custom script-to-rule transpiler: This is the core gap. XDP script blocks (calculate, validate, initialize events) are plain XML and fully machine-readable. We can parse these, map them against the clustered patterns from step 1 (since the same logic often repeats across hundreds of forms), and translate them into Adaptive Forms rules or a shared custom-function library. The key difference from the AI approach you tried: the translation itself needs to be pushed directly into the AEM instance via its APIs (Sling POST / CRX package / server-side script) rather than only generated as text with no way to apply it. Once the tool has actual write access to the target instance, this becomes far more automatable.

4. Handle repeatable sections and add/remove as a property mapping, not a script rewrite: XFA's subform occurrence settings (min/max/initial) map directly to the Adaptive Forms Panel's repeatability properties, which auto-generate the add/remove buttons. Since AFCS skips this entirely, this is a highly mechanical and automatable transform on its own.

5. Risk-tier QA instead of manually reviewing all 2000: Using the clusters from step 1, we'd manually verify one or two representative forms per pattern, then run automated functional checks (headless browser tests exercising show/hide/calculation rules and add/remove behavior) across the rest, reserving manual review for genuinely unique, one-off forms.

We'd also suggest raising this with your Adobe account team — for migrations at this scale, Adobe Consulting sometimes runs dedicated "migration factory" style engagements with additional tooling for exactly this scripts/repeatable-panel gap, which may not be reflected in the public AFCS documentation.

Happy to work through the technical design of the transpiler and the repeatable-panel mapping in more detail if that would help move this forward.

Thanks
Pranay