Write a preservation action plan when a format in your collection carries real obsolescence or integrity risk AND you have the capacity to execute the action it prescribes. The plan is the bridge between a risk assessment ("this DOC file may not open in 15 years") and a repeatable action ("normalise to PDF/A-2u on ingest, validate with veraPDF, log a PREMIS event"). If either half is missing — no genuine risk, or no resource to act — a formal plan is the wrong tool, and a lighter "monitor only" note serves you better.

What exactly is a preservation action plan?

A preservation action plan is a short, structured document that ties one format (or one cluster of significant properties) to a decided action and the conditions under which it fires. At minimum it records: the format and its current risk score, the chosen strategy (migrate, normalise, emulate, retain), the trigger that activates it, the tool and settings used, the acceptance tests, and who owns the decision. It is operational, not aspirational — every field should be something an ingest workflow or a future curator can execute without guessing.

# action-plan: legacy-word-processor.yaml
format: "Microsoft Word 97-2003 (.doc)"
puid: "fmt/40"
risk: high            # narrow tool support, proprietary, undocumented
strategy: normalise
target: "PDF/A-2u + retain original .doc"
trigger: "on-ingest, OR scheduled review every 24 months"
tool: "LibreOffice 7.6 headless --convert-to pdf:writer_pdf_Export"
acceptance:
  - "veraPDF passes PDF/A-2u profile"
  - "page count of source == page count of target"
  - "embedded fonts present"
owner: "digital archivist"
review: 2027-01

When does writing a plan actually pay off?

The plan earns its keep when the action is non-trivial, repeated and auditable. Migrating 40,000 legacy spreadsheets, normalising every born-digital deposit, or committing to emulate a 1990s multimedia CD-ROM are all cases where a written, tested recipe prevents drift and inconsistency. The clearest "yes" signals:

• The format scores medium-to-high on a format-risk assessment.
• The action will run more than once (on every future deposit, or on a schedule).
• You need an audit trail for funders, depositors or accreditation (PREMIS events, fixity before/after).
• More than one person will execute it, so tacit knowledge must be written down.

When should you deliberately skip the plan?

Not every format needs one, and over-planning is a real failure mode. Skip a formal action plan when:

• The format is stable and open (plain UTF-8 text, well-formed TIFF, PDF/A already): record "retain, monitor" and move on.
• The collection is tiny or ephemeral — the overhead of authoring and reviewing the plan exceeds the value at stake.
• You have no capacity to act. A plan that says "migrate" but is never run is dishonest documentation; an explicit "monitor only — no resource" is more truthful and audit-safe.

The cost is not the writing; it is the maintenance. Every plan you create is something you must review on its cycle, re-test when tools change, and defend in an audit.

Migrate, normalise, or emulate — which action goes in the plan?

The chosen action determines the whole plan, so decide it deliberately rather than defaulting to migration.

Action	Best when	Cost / risk	Test
Normalise on ingest	Many varied inputs, one stable target	Loses some original quirks	Validate target + compare properties
Migrate later	Format stable now, risk is future	Deferred work can be forgotten	Re-validate at migration time
Emulate	Interactive or executable objects	Heavy infra, rights questions	Functional/behaviour test in emulator
Retain (bit-level)	Open, low-risk, or no clear target	No access guarantee	Fixity only

A plan can combine strategies — most commonly normalise-and-retain, keeping the original alongside a derivative so no information is destroyed.

How do you keep a plan from rotting?

A plan is only as good as its trigger and its review date. Hard-code both. Tie the activating trigger to something observable — a DROID identification result, a JHOVE validation failure, a calendar review — so the action is not left to memory. Set a review date in the plan itself, and check tool versions on that date: a LibreOffice headless conversion that worked in 7.6 may behave differently in a future release, which is exactly why acceptance tests live in the plan.

# Re-validate a normalised batch against its plan's acceptance test
verapdf --format text --flavour 2u ./derivatives/*.pdf \
  | grep -c "PASS"        # must equal the source file count

Key Takeaways

• Write an action plan only when there is genuine risk AND capacity to execute — both halves matter.
• The plan binds one format/property set to one decided action, with trigger, tool, settings and acceptance tests.
• An honest "monitor only" note beats a plan you cannot run; over-planning carries real maintenance cost.
• Decide migrate vs normalise vs emulate vs retain deliberately; normalise-and-retain is a safe default for office formats.
• Bake the trigger into an observable signal (DROID, JHOVE, schedule) so the action fires automatically.
• Always define acceptance tests up front and log a PREMIS event recording agent, tool version and outcome.
• Group plans by format family and significant properties — one per family, not one per file.

Frequently Asked Questions

What is a preservation action plan?

It is a documented decision that links a specific file format (or set of significant properties) to a concrete action — migrate, normalise, emulate or retain — along with the trigger, tools and acceptance tests. It turns a risk assessment into a repeatable, auditable workflow.

When should I NOT write a preservation action plan?

Skip a formal plan when the format is stable and widely supported, the collection is tiny or short-lived, or you have no resource to execute it. A plan you cannot action is worse than an honest "monitor only" note, because it implies a level of care you are not delivering.

How is a preservation action plan different from a preservation policy?

A policy states the principles and commitments at the organisation level; an action plan is the operational, format-specific recipe that implements those principles. One policy typically governs many action plans.

What triggers a preservation action?

Common triggers are obsolescence signals (a format dropping out of support), a failed validation or fixity check, a designated-community access need, or a scheduled review cycle. The trigger should be written into the plan so the action fires automatically, not on a whim.

How do I test that a preservation action worked?

Define acceptance tests before you run the action: validate the output (for example with JHOVE or veraPDF), compare significant properties of source and target, and record a PREMIS event with the agent, outcome and tool version. If the test fails, the migration is not done.

How many action plans does a repository need?

Usually one per format family at risk, not one per file. A small archive might maintain three to six plans (office documents, raster images, audio, email); a large one may have dozens, but should still group by format and significant properties rather than proliferating.

Related reading

• When to Assess file format obsolescence risk
• Define significant properties: A Practical Guide
• Troubleshooting: Write a digital preservation policy
• Beginner's Guide to Emulation vs migration
• Migrate obsolete formats