How to assess an XFA estate you did not build
Most teams inherit their form estate. This is the sequence we run before any migration is scoped: what to count, what to measure, and which four answers decide whether a form can move.
1. Count assets, not files
Separate rendered forms from the fragments, schemas and images they pull in. A repository with 4,000 files is often 900 forms and 3,100 shared parts, and the migration cost tracks the second number far more than the first. Counting files gives you an estimate that is wrong in a direction you will not discover until month four.
2. Resolve the dependency graph before you trust the inventory
Unresolved edges are where estates hide their real size. A fragment referenced by a path from a folder that was reorganised in 2019 still renders in production because a cached copy exists somewhere. Find those first: they are the forms that will fail at the worst moment.
3. Measure what each form actually uses
The blocker is rarely the layout — it is scripting, submit behaviour and dynamic subform logic. Classify every form by the runtime features it depends on and the migration waves organise themselves. In a typical estate, static layout and light calculation account for roughly three quarters of forms; the work concentrates in the remainder.
4. Decide what "the same" means before you convert anything
Pixel equality is the wrong bar and will stall the programme. Agree the comparison up front — field values, page count, text runs, tagged reading order — and make it a test that runs on every revision from then on, not a one-off sign-off.
What you should have at the end
An asset count separated by type, a resolved dependency graph with the unresolved edges listed, a feature distribution across the estate, and a written definition of equivalence. If a vendor scopes a migration without those four, the number is a guess.