Do WPSs have an expiration date?

No. AWS D1.1 WPSs don't have a code-mandated expiration. They remain valid as long as the cited code edition is still acceptable for the project, the essential variables stay within range, and the supporting PQR remains on file.

What forces a WPS update?

Three things: (1) a new code edition is invoked by contract or AHJ, (2) an essential variable on the WPS drifts outside the supporting PQR's qualified range, or (3) the procedure itself needs a parameter change.

Can I keep using a D1.1:2020-cited WPS in 2026?

Yes, as long as the contract or AHJ accepts the 2020 edition. Many projects let fabricators cite a prior edition during transition periods. Always check the contract and the AHJ requirements before assuming the prior edition is acceptable.

How long is a WPS valid? Edition transitions and procedure lifetime

WPSs don't expire — but they can become non-compliant when their cited code edition is superseded. Here's how to manage edition transitions in your library.

A WPS is a controlled document, not a perishable one. There is no AWS D1.1 rule that says "WPSs expire after N years." As long as the cited code edition is acceptable for the project, the essential variables stay within range, and the supporting PQR remains on file, a WPS keeps authorizing production.

But "acceptable for the project" is where things get interesting. Code editions update. Edition transitions create a window where multiple editions are in use simultaneously. Managing the transition is what separates a stable WPS library from one that triggers audit findings.

The 5-year cadence

AWS D1.1 updates roughly every 5 years:

AWS D1.1:2010
AWS D1.1:2015
AWS D1.1:2020
AWS D1.1:2025 (ANSI-approved 2025-03-19)

The 2025 edition is current as of this writing. The next edition (likely 2030) is in committee development.

During each transition, the prior edition remains acceptable for some period — typically 1-2 years — depending on contract and AHJ requirements.

What an edition transition requires

Migrating from D1.1:2020 to D1.1:2025 requires:

Header citation update — every WPS header changes from "AWS D1.1/D1.1M:2020" to "AWS D1.1/D1.1M:2025"
Table number update — references to Table 6.5 → 6.6, 6.6 → 6.7, 6.7 → 6.8 inside the WPS body
Table 5.4 filler matching re-check — generally unchanged but worth verifying
Table 5.8 preheat re-check — generally unchanged but worth verifying
Table 6.9 base-metal group re-check — was Table 3.1 in 2020
Annex B joint detail re-check — generally unchanged
Specific row content changes in Table 6.6 (row 4 A5.36 change, row 7 ratio tightening, row 8 -G designator)
CVN supplementary changes in Table 6.8 (thickness floor 5/8 in → 1/2 in, preheat dropped from row 8 scope)
Re-sign each touched WPS with current credentials

For a 30-WPS library, this is roughly 30-60 engineering hours of careful work. A rule engine can automate items 1-7 and flag items 8 for manual review.

When NOT to migrate immediately

Three valid reasons to keep an existing edition:

Active project under contract that cites the prior edition. Don't migrate mid-project; finish the work, then migrate.
AHJ permission for prior edition. Some jurisdictions explicitly allow continued use of the prior edition for a defined period.
PQR data tied to specific row content. If your supporting PQR was qualified under a row that changed materially in the new edition, verify the PQR still supports the production range in the new edition before migrating.

Edition-transition strategies that work

Phased migration. New WPSs in the new edition; existing WPSs frozen in the old edition. Migrate the old library as each WPS comes up for revision anyway. Takes 2-3 years to complete the library but spreads the engineering effort.

Full migration at code-publication date. Migrate everything to the new edition immediately. Higher upfront effort, cleaner library state. Most large shops do this with software-assisted bulk updates.

Dual-edition citation during transition. Some shops temporarily cite both editions ("AWS D1.1/D1.1M:2020 and 2025") on WPSs during the transition window. Acceptable but not preferred — clean single-edition citation is cleaner.

When the WPS does need to be replaced (not just updated)

Three triggers for actual replacement:

Production parameter range changes substantially. A new SAW procedure with different ratios, a new GMAW transfer mode — these are new WPSs.
Joint geometry changes. Different Annex B detail, different angles, different backing — new WPS.
Base metal Group changes. A36 → A572-50 is a Group I → Group II change, essentially a new procedure.

In each case, the old WPS is archived (revision history preserved) and a new WPS issued with new number.

The audit perspective

Auditors expect to see one of:

Current code edition cited and all table numbers internally consistent
Prior code edition cited with explicit justification (contract, AHJ permission, in-progress project)
Library mid-migration with documented migration plan and visible progress

What auditors find as a deficiency:

WPS header cites 2025 but body references 2020 table numbers
Library claims to be on 2025 but some WPSs are unsigned/unmigrated drafts
No documented migration plan when the WPS library spans multiple editions
WPSs citing editions older than 2 prior (so in 2026, anything pre-2020)

What this means for software-based libraries

WPS software that encodes code-table values can perform an edition migration largely automatically:

Bulk-update headers and table references
Flag specific rows that changed materially (row 4, row 7, row 8 in Table 6.6)
Highlight WPSs where the change affects qualified production ranges
Generate a migration report for QC review

Software-based migrations take a fraction of the time of hand-edited ones, and they catch the small drifts (row 7 ratio tightening, Table 6.8 thickness floor change) that hand migrations frequently miss.