A PDF form’s appearance does not reveal how its fields, data, and layout are stored. Identify the form technology before choosing a viewer or migration route. Keep the original form, its data, and its source template as separate assets whenever they are available.
Identify the form you have
| Type | Working model | What to establish |
|---|---|---|
| AcroForm | PDF page layout with interactive fields | Field names, supported actions, export format. |
| Static XFA | XML-based form with a fixed runtime layout | Data binding and supported interaction in the target viewer. |
| Dynamic XFA | XML-based form whose layout can change | Support for scripts, repeated sections, and pagination. |
| Flattened document | Rendered appearance with interactive fields removed | Whether original data and template survive elsewhere. |
Adobe’s PDF forms overview explains AcroForms and static/dynamic XFA. It describes dynamic layout and warns that modern browsers’ built-in PDF viewers cannot render dynamic forms. Use the document’s authoring history and supported inspection tools to establish its type; a screenshot or filename is insufficient.
XDP is an XML Data Package used in Adobe form workflows. XFDF is a different XML representation used for PDF-related data such as field values and annotations. Treat these names as distinct formats with distinct consumers, not interchangeable XML exports.
Check the whole compatibility path
Record the exact desktop, browser, mobile, or server product and version; identify which actions the recipient must perform. Viewing, filling, saving, exporting, signing, and submitting are separate capabilities.
As checked in September 2026, Adobe’s Acrobat web Fill & Sign format guidance lists dynamic XFA PDFs as unsupported. Its PDF Services export documentation specifies filled AcroForm/static XFA inputs. These are product-specific limits; recheck the relevant documentation for the service you intend to use.
Before distribution, fill representative fields in the actual recipient environment, save, close, reopen, and inspect the result. Test repeatable sections and calculations where they exist. A form opening successfully establishes less than an end-to-end submission test.
Separate data extraction from appearance
Suppose a fictional dispatch form displays recipient Studio Team and quantity 2. A successful migration needs the field values, their names and types, and the rules assigning them to the destination. A flat page showing “2” may no longer identify which logical field held that value.
Build a mapping record: source field path → destination field → type → transformation rule → test value. Include repeated rows, dates, checkboxes, absent values, non-ASCII text, and field names that differ only in case. Compare exported values before and after reimporting into a test copy.
Adobe’s AEM Forms import/export documentation describes service-specific data operations. Select the API appropriate to the form type. Keep signing and certification requirements with the document owner; conversions may alter the properties those workflows rely on.
Run a controlled migration pilot
Preserve original bytes and record a hash. Gather the authoring template, schema, scripts, images, and a synthetic data sample. Define whether the deliverable must remain interactive or only preserve readable content.
Choose a small pilot covering simple, repeated, and exceptional fields. Export data through a supported route, map it to the destination model, render or populate a new test form, and compare every significant value. Then perform the recipient’s save/reopen/submit workflow and review accessibility needs.
Adobe’s XFA editing guidance describes conversion workarounds. Treat printing or flattening as an appearance-oriented derivative: verify what happened to fields, scripts, and signatures, and retain the original. Use a separate destination filename and an explicit acceptance record. Deploy after the actual receiving workflow passes, not merely after a new PDF is created.