Microsoft's published retirement date for InfoPath was 14 July 2026. Stated as context for why records teams are looking at this now — not as a countdown to anything.

Expense claims, incident reports, HR onboarding, supplier declarations, inspection checklists. A lot of InfoPath estates are exactly the kind of content that sits inside a retention schedule for six, seven, ten years or longer. The software retiring does not shorten that. The only thing that changes is that the tool which made those records legible is no longer part of your estate.

Start by writing down what "archived" has to mean for you

Different obligations want different things, and it is worth being specific before you pick a tool.

  • Retention. The record must still exist and still be readable at the end of its period, without the original application.
  • Audit. Somebody who was not there needs to open a record, understand it, and see that it has not been altered since it was captured.
  • Subject access. You need to find every record relating to one person and produce them in a commonly used, readable format — which means the archive has to be searchable, not just present.
  • Legal hold. Specific records must be preserved unchanged, which puts a premium on being able to show that nothing you did to build the archive touched the originals.
  • Handover or disposal. If the entity, department or system is being wound up, the archive has to be self-contained enough to survive without you.

Why PDF alone usually is not the answer. A PDF is what a person reads. It is poor at answering "find every claim by this person over four years", and it throws away the field structure that makes such a question answerable at all. Most records teams land on three layers rather than one: the originals (.xml and .xsn, untouched, as the evidence), structured data (CSV or JSON, for search and reporting), and a document per record (PDF or HTML, for a human). Each layer answers a question the others cannot.

The free routes to PDF, and exactly where they stop

1. InfoPath's own export (free, while you have it)

In InfoPath, File → Export To produces a PDF or XPS of the open form. It is faithful, it costs nothing, and it is the right answer for a small number of records — a specific case, a single claim, a form somebody has asked about. Do the important ones today if you still have a working install.

Where it stops: one form at a time, by hand, on a machine with InfoPath on it. For a few thousand records that is not a workflow.

2. Print to PDF (free)

Any application that can display the form can print it to a PDF printer. Same strengths, same ceiling, and slightly worse fidelity than the built-in export.

3. Server-side or flow-based conversion (paid, and a real option)

There are document-conversion products that plug into SharePoint or Power Automate and convert InfoPath forms to PDF in bulk. If you already own one, or you are already building flows, this is a sensible route and we are not going to pretend otherwise. Two things to check before you commit: whether it needs a running InfoPath or Forms Services to render, since that is the dependency you are trying to shed; and whether your records may leave your own infrastructure during conversion, which matters if the content is personal data.

4. Script the structured data, then render it (free, technical)

Since each record is plain XML, a script can pull the values and a template can render each one to HTML, which then prints to PDF. This works and costs nothing but time. Budget for the fiddly parts: repeating sections, attachments stored as base64 inside the record, and producing an index so the resulting pile of files is navigable. See the CSV and Excel guide for the structured-data half of that job.

The six things that make an archive actually hold up

Whatever route you take, these are what separate an archive from a folder.

  1. A complete inventory first. Every .xsn and every .xml across every share, library and old server. You cannot preserve what you have not found, and "we think that was all of it" is not an answer to an auditor.
  2. Originals kept, and demonstrably untouched. The .xml records are your evidence. Everything else is derived. Keep them, and be able to show that building the archive did not modify them.
  3. A per-record document. One readable file per record, self-contained, that opens with nothing but a PDF reader or a browser.
  4. Structured data alongside it. CSV or JSON so the archive can be searched, filtered and reported on. This is the layer that answers a subject-access request in an afternoon rather than a fortnight.
  5. An index. A browsable list tying record to document to original file. Without it, ten thousand PDFs is a haystack.
  6. A record of what happened. Which files were processed, which were not, and why. A gap you have documented is a manageable finding. A gap nobody noticed is the thing that goes badly.

What our tool does for this specific job

XSN Rescue was built around that list. Point it at a folder and, from a single pass, it produces:

  • A self-contained archival PDF for every recovered record — the per-record document, openable with no InfoPath, no viewer and no account.
  • CSV and JSON of the field data, with the field catalogue and the solution name and version, and repeating or nested sections disambiguated by indexed field paths.
  • An HTML rendering that preserves the template's original XSL views, so the archived record looks like the form it was.
  • Attachments decoded back into real files — a document attached inside a form comes out as a working .docx or .xlsx saved beside the record, rather than staying locked in base64.
  • An estate-inventory report over every form in the folder: distinct templates, record counts, and a schema census giving each field's name, type and fill rate — every figure computed from your parsed data, nothing estimated.
  • A recovery report on every run naming each file and its outcome, including files that did not parse and why. Nothing is skipped quietly.

Two details that matter to records people specifically. It opens your files read-only and records source_modified: false for each one, so the trail showing the originals were untouched is produced automatically rather than asserted. And recovery runs entirely on your own machine — nothing is uploaded, there is no account, and the recovery engine contains no networking code; the app itself goes online only to check your licence key — which is a materially easier conversation with a data-protection lead than uploading HR records to somebody's website. It is bought once, per organisation, rather than rented for the privilege of reading your own records. For estates under real scrutiny there are higher tiers adding search and eDiscovery, continuity re-checks, custody packs and multi-location consolidation.

What it does not do, because you will be asked. It recovers the data and the static layout. Code-behind (managed code or script), external data connections and user-role logic are not executed or recovered. Digital signatures are surfaced as fields but not cryptographically verified — if the legal weight of a signature is the point, say so early and take advice, because no export of ours substitutes for that. The archival PDF uses a standard Latin font with no font embedding, so characters outside that set are marked [U+XXXX] and counted, while the JSON export preserves the exact text. And it is a recovery and archival tool, not a records-management system or a retention-schedule engine.

Platform. XSN Rescue runs on macOS (10.15 or later, Intel and Apple silicon, one universal download) and on Windows 10 and 11 (64-bit). Both are the same version and the same price — one purchase covers both. There is no Linux build, and we are not giving a date for one; on Linux, the free routes above are your path, and they work.

A plan you could start this week

  1. Inventory. Sweep every share and library for .xsn and form-data .xml. Record counts and locations.
  2. Classify. Which of these are live processes needing migration, and which are historical records needing archival? They are different jobs and conflating them is the most common way this goes wrong.
  3. Check the schedule. Get the retention period for each category from whoever owns it, in writing.
  4. Protect. Copy the originals to somewhere safe and work only from copies.
  5. Pilot on one form type before committing to a route across the estate. Reconcile the counts by hand on that pilot.
  6. Produce all three layers — originals, structured data, per-record documents — plus an index and a report of what was processed.
  7. Write the memo. One page: what was found, what was archived, by what method, on what date, with what gaps. That memo is the archive's provenance and it takes twenty minutes now instead of a week of reconstruction later.

None of the above requires buying anything from us. If your estate is small enough that InfoPath's own export and a good spreadsheet gets you there, do that — the records surviving is the outcome that matters.