Migration & Modernization. This guide covers InfoPath Conversion to PDF for your organisation’s digital transformation.
Can InfoPath forms be converted to PDF?
Yes. InfoPath forms can be converted to PDF individually or in bulk. The process requires matching each filled XML form to the exact .xsn template that produced it, identifying every view that template defines, and rendering the form the way the template defines it — not just dumping field names and values.
For a handful of forms, this can be done by hand. For an archive — thousands or millions of forms across hundreds of template versions — it requires an automated solution: software that matches forms to templates, renders every required view, records the result, and can resume safely if interrupted.
This is not theoretical. An automated solution built specifically for InfoPath-to-PDF migration has converted more than 6 million InfoPath forms across 500 InfoPath templates — every form in scope successfully converted, with the rare failure resolved by fixing the solution or ruled out as not a real filled form. Below is a fully instrumented, independently reproducible benchmark showing exactly how it performs: 11,446 PDFs generated from 4,811 forms, sustained at roughly 36 PDFs per second, with every single conversion individually logged as a pass or fail.
The proof: what has actually been converted
| Metric | Result |
|---|---|
| Template inventory converted | 500 InfoPath templates, all versions in scope |
| Total forms converted | 6,000,000+ |
| Outcome | Every form in scope was successfully converted — any failures were resolved by fixes to the automated solution or excluded as non-form artifacts, not left unconverted |
| Fully instrumented reference benchmark | 4,811 forms → 11,446 (form, view) PDFs, every one logged as successful |
| Benchmark success rate | 100% (11,446 / 11,446), individually logged |
| Benchmark throughput | ~36 PDFs/second sustained, on modest, non-lab-grade hardware |
| Benchmark hardware | 2 vCPU / 7 GB reference machine — not a best-case lab environment |
Why both a large production figure and a smaller benchmark appear: the 6-million figure reflects what the automated solution has delivered in production, at real archive scale. The 11,446-conversion benchmark is a fully reproducible, independently checkable measurement — evidence that can be walked through line by line, conversion by conversion, rather than taken on faith. Throughput (PDFs/second) is a useful, apples-to-apples measure of the platform’s capacity; total time for any given migration still depends on archive size, template count, and complexity, so it is not something to back into from this benchmark alone.
Why organizations are migrating away from InfoPath
Microsoft discontinued active development of InfoPath in 2014; InfoPath 2013 was the final release. The retirement is now complete:
- May 18, 2026 — Microsoft blocked publishing of new InfoPath forms (and updates to existing forms) across all SharePoint Online tenants, including GCC and GCC High.
- July 14, 2026 — InfoPath 2013 reached the end of extended support (no further security patches), and InfoPath Forms Services was removed from SharePoint Online for all tenants, with no option to extend. Extended support for InfoPath Forms Services on SharePoint Server 2016, 2019, and Subscription Edition ended the same day.
The practical effect differs depending on where the archive lives. In SharePoint Online, InfoPath forms no longer open, submit, or render — the only remaining path to the data is downloading the .xml forms and .xsn templates and opening them with the InfoPath 2013 client, if a workstation still has it installed. On-premises, existing forms may still render, but the entire stack is unsupported: no security patches, no fixes, no compatibility guarantees as Windows, browsers, and SharePoint updates continue to ship.
Either way, the underlying problem is the same: the filled XML alone does not contain the rendering logic — that logic lives separately, in the .xsn template package. Converting the archive to PDF now, while the templates and any remaining InfoPath installations are still available, is how organizations keep those records readable for the next decade.
Organizations retiring InfoPath are typically holding years of forms that fall into exactly the categories that carry retention or audit obligations — tax withholding forms, employment eligibility forms, signed policy acknowledgements, compliance assessments. Losing the ability to open them is not just an inconvenience; it is a records-retention risk.
Why bulk InfoPath conversion is difficult
Converting one form is straightforward if you still have InfoPath. Converting an archive is a different problem, for four specific reasons:
| Challenge | Why it matters |
|---|---|
| Data and rendering logic are separate files | The filled data (.xml) and the layout/logic that renders it (.xsn) are different artifacts. Converting XML without its matching template produces garbage or nothing. |
| Template versioning | Organizations commonly have a dozen-plus .xsn versions of the “same” form accumulated over years of revisions (a state withholding form updated annually is a typical example). Each filled form has to be matched to the exact version that produced it — the wrong version renders a plausible-looking but factually wrong PDF. |
| Multiple views per template | A single InfoPath template can define several views of the same underlying data — for example a fillable view and a read-only/printable view. A complete conversion produces a PDF for every view the template defines, not just one. |
| Template packaging | .xsn files are Microsoft CAB archives, which most general-purpose tooling does not open natively. |
At archive scale, these four issues compound: hundreds of template versions, millions of forms, and no reliable way to know — without an automated, logged process — whether the whole archive actually converted, or just most of it.
How InfoPath-to-PDF conversion works
This is the shape of the automated solution built for InfoPath-to-PDF migration — not a one-off script written per engagement, but a reusable platform that already understands template matching, versioning, and view rendering before a single form in your archive is processed. It runs in three stages:
Match every filled XML form to the exact template that produced it.
Enumerate every view that template defines.
↓
2. Schedule
Determine which (form, view) combinations still need a PDF.
Skip anything already converted successfully.
↓
3. Render
Convert each queued (form, view) pair to a PDF using that
template’s own view definition — not a generic field dump.
Record success or failure for every single conversion.
Why it is structured this way:
- Indexing first means template-matching errors surface before you spend time rendering — an unmatched form is a data problem to flag, not a PDF to guess at.
- Scheduling as its own step makes the whole process resumable. Interrupting a run of millions of forms and restarting does not reprocess what already succeeded — it only queues what is still outstanding.
- Recording every attempt, success or failure, means “is this archive fully converted?” is answered by a query, not by re-checking a folder of PDFs by hand.
What should an InfoPath migration preserve?
Prospective customers are not really buying “PDF conversion” — they are buying confidence that their historical records survive the move intact. A migration should preserve:
- Form data — every field value from the original submission.
- Form layout — the visual structure the form had when it was filled out, not just raw field/value pairs.
- Template version — the correct historical version of the form, not the current one.
- Every view the template defines, not just the default one.
- Original filenames/identifiers, so converted PDFs can be traced back to source records.
- A complete audit trail of what was converted, when, and with what result.
- Searchable metadata, where the destination supports it — for example, if you are migrating into SharePoint, key field values pulled from the form can be written into library columns alongside the converted PDF, not just left embedded inside it.
Depending on the archive, organizations should also ask specifically about attachments embedded in forms and any signature or custom-control fields — these are the details most likely to be handled inconsistently by a generic, non-template-aware conversion approach.
Can you convert InfoPath forms manually?
Sometimes. It depends on the shape of the archive, not just its size.
Manual conversion can work when
- There is a small number of forms.
- A workstation still has the InfoPath 2013 client installed and functional.
- There are only one or two template versions in play.
- Historical fidelity (matching the exact template version) is not critical.
Automated conversion becomes necessary when
- You have thousands (or millions) of forms.
- There are dozens or hundreds of template versions.
- Templates define multiple views.
- Historical versions must be preserved accurately.
- You need an audit trail proving what was converted and what was not.
- The process needs to be repeatable — because new forms keep arriving until InfoPath is fully decommissioned.
- You need to verify, not assume, that every form was processed.
The failure mode of DIY migration at scale usually is not “it does not work at all” — it is partial, unverifiable completion: some forms rendered with the wrong template version, some views silently skipped, no record of which forms were never processed. That is a worse outcome than not starting, because it looks finished.
The underlying challenge is not generating one PDF — it is reliably converting an entire archive while preserving the relationship between forms, templates, views, and historical versions, and being able to prove it afterward.
InfoPath-to-PDF migration checklist
Before starting a migration, it helps to inventory:
- Number of InfoPath forms
- Number of
.xsntemplates, and how many versions of each - Number of views per template
- Forms with attachments
- Forms subject to legal/compliance retention requirements
- Forms with signature fields
- Forms with custom controls or conditional formatting
- Required retention period
- Required output structure (how PDFs should be organized/named)
- Audit/verification requirements
If you are unsure how your InfoPath archive is structured, an inventory of the XML forms and .xsn templates is usually the right starting point — before committing to a conversion approach.
How do you verify a successful migration?
A completed migration should be able to answer, with evidence rather than assurance:
- How many forms were in the archive, and how many views did their templates define?
- How many (form, view) pairs were converted successfully?
- Which ones failed, and why — a missing template match, a malformed template, corrupted XML?
- Can the job be re-run to retry only the failures, without re-converting everything that already succeeded?
Across production migrations totaling more than 6 million forms and 500 InfoPath templates, every form in scope was ultimately converted successfully — failures along the way were resolved either by fixing the automated solution to handle a case it initially missed, or by confirming the “failure” was not a real filled form to begin with. In a fully instrumented 11,446-conversion reference benchmark, the result is checkable directly: 4,811 source forms mapped to their templates with zero unmatched forms, and every one of the 11,446 queued (form, view) pairs logged as successful.
Every InfoPath environment is different — template versions, views, attachments, and retention requirements all affect the right migration approach. We can assess your InfoPath archive, identify exactly what needs to convert, and scope the approach before any work starts.
FAQ
When did InfoPath reach end of life?
InfoPath 2013 — the final version — reached the end of extended support on July 14, 2026. InfoPath Forms Services was removed from SharePoint Online for all tenants on the same date, and extended support for InfoPath Forms Services on SharePoint Server 2016, 2019, and Subscription Edition ended then as well. Microsoft had already blocked publishing of new or updated InfoPath forms in SharePoint Online as of May 18, 2026.
Do InfoPath forms still work in SharePoint Online?
No. Since the July 14, 2026 retirement, InfoPath forms no longer open, submit, or render in SharePoint Online, and there is no option to extend the service. The remaining way to access the data is to download the .xml forms and .xsn templates and open them with the InfoPath 2013 desktop client, where it is still installed — or convert the archive to a durable format like PDF.
Can I convert InfoPath XML files directly to PDF, without the template?
No, not reliably. The XML contains the filled data, but the layout and rendering logic live in the .xsn template. Converting XML without its matching template produces incomplete or meaningless output.
Do I need the original .xsn templates to migrate my forms?
Yes. Each filled form needs to be matched to the exact template — and often the exact template version — that produced it in order to render correctly.
What happens if I have multiple versions of the same InfoPath template?
Each filled form needs to be matched to the specific template version it was created with. Using the wrong version can produce a PDF that looks plausible but does not accurately reflect the original form.
Can InfoPath forms with multiple views be converted?
Yes. A template can define more than one view (for example, a fillable view and a read-only view). A complete migration converts every view the template defines, not just one.
Can millions of InfoPath forms be converted automatically, in bulk?
Yes. More than 6 million forms have been converted across 500 InfoPath templates using an automated solution built for exactly this problem. A fully measured reference benchmark produced 11,446 form-view PDFs from 4,811 source forms, sustained at roughly 36 PDFs per second, with every conversion individually logged as successful.
Can attachments and signature fields be preserved during conversion?
This depends on how the source form embeds them. It is one of the first things to check during an archive inventory, since not all conversion approaches handle embedded attachments or custom signature controls the same way.
Can InfoPath form data be captured as metadata during conversion?
Yes, where the destination supports it. If forms are migrating into SharePoint, key values from each form can be extracted and written into SharePoint library columns alongside the converted PDF — so the archive is filterable and searchable by that metadata, not just readable as a PDF.
How do I verify that every InfoPath form was actually converted?
A properly built automated migration solution logs a result for every single (form, view) conversion attempt, so completeness can be checked with a query rather than assumed from a folder listing.
How long does an InfoPath migration take?
It depends on archive size, number of templates and views, and complexity (attachments, custom controls, retention requirements). As a capacity reference, the automated solution has sustained roughly 36 PDFs/second in benchmark testing on modest hardware, so conversion speed itself is rarely the bottleneck — but total timeline for any given archive still depends on volume and complexity, so an archive assessment is the fastest way to get an accurate schedule.
Can InfoPath forms be migrated from SharePoint / InfoPath Forms Services?
Yes — the same core problem applies (matching filled data to its template and view definitions), regardless of whether the forms were originally hosted through InfoPath Forms Services in SharePoint. Note that in SharePoint Online, the .xml forms and .xsn templates must now be downloaded before conversion, since InfoPath Forms Services itself was retired on July 14, 2026.
How much does InfoPath-to-PDF conversion cost?
It depends on archive size, number of templates, and complexity (attachments, custom controls, retention requirements). An archive assessment is the fastest way to get an accurate scope.
