The Research Data Alliance’s DMP Common Standard, originally published as v1 in 2019, has been the canonical machine-readable schema for machine-actionable data management plans. The v2 revision, released early in 2026 after a two-year community consultation, reorganises the schema, tightens validation, and adds explicit support for software, samples, and instruments alongside data. This post is a field-by-field walkthrough for integrators.
Why v2 was needed
v1 was designed in the FAIR-data heyday and is fit for that purpose. Three forces produced the v2 revision. First, the scope of “things to be managed” expanded: software is increasingly part of the planning conversation, samples are increasingly recognised as research outputs that need governance, instruments have their own management lifecycle. v1 could be coaxed into representing these but the structure was uncomfortable. Second, validation: v1 was permissive in the ways that mature standards usually tighten over time. Optional fields proliferated, the meaning of several fields was under-specified, and tools produced incompatible serialisations within nominal compliance. Third, FAIR-implementation maturity: v2 needed to carry the metadata that the FAIR data-assessment frameworks (FAIRsharing, F-UJI, FAIR Implementation Profiles) had converged on requiring.
Structural changes
The top-level structure of v2 is reorganised. v1 had dmp as the root with sub-resources for dataset, contact, contributor, project, cost. v2 keeps dmp as the root but moves to a managed_resources array that contains heterogeneous resource types: dataset, software, sample, instrument, other. Each resource type has its own schema with shared common fields (identifier, title, description, distribution, license, contributors with CRediT roles) and type-specific fields.
This is the biggest structural change and the one that will require migration effort. v1 DMPs with only datasets can be projected into v2 cleanly; v1 DMPs that used the dataset structure to represent software or samples (the common workaround) will need restructuring on migration.
Identifier requirements
v2 tightens identifier requirements. Every managed resource must declare its identifier with a type (DOI, Handle, URL, ARK, IGSN for samples, RAiD for projects); the identifier validation runs against the type. The contributor structure requires ORCID iDs for individuals; the affiliation structure requires ROR IDs for organisations. The project structure requires either a RAiD or a Funder Registry grant identifier or both.
The validation tightening is the integration-relevant change. v1 tools that accepted strings in identifier fields will produce DMPs that fail v2 validation. Integrators should review their PID-handling logic before migrating.
The CRediT integration
v2 carries CRediT roles natively in the contributor structure. Each contributor on a DMP can be assigned one or more CRediT roles with the degree-of-contribution qualifier. The expected pattern is that DMP contributors (the people who will manage the data) get roles like Data curation, Resources, Project administration, Supervision, with the actual research contributors getting their roles assigned later via the publication or dataset metadata. The DMP captures the data-management contributorship, not the research contributorship.
FAIR alignment
v2 includes a fair_assessment structure that aligns with the FAIR Implementation Profile framework. Each managed resource can carry an FIP reference, and the DMP-level fair_assessment can declare which FAIRsharing-registered standards, identifiers, and policies the resources conform to. This is the bridge between DMP-as-planning-document and DMP-as-FAIR-compliance-record.
The cost structure
v2 reworks the cost structure. v1 had a flat cost array with title, description, value, currency. v2 categorises costs by phase (acquisition, processing, storage-active, storage-preservation, dissemination, decommissioning) and by recurrence (one-off versus annual), which lets a DMP integrate with funder budget structures and institutional cost-recovery models. The cost structure is optional but recommended.
Lifecycle status
v2 introduces an explicit lifecycle field on each managed resource, with controlled values covering planning, acquisition, processing, analysis, dissemination, preservation, decommissioning. A DMP can describe resources at different lifecycle stages, which lets the same DMP serve as both a project-launch plan and a project-completion record. This addresses a v1 friction where DMPs were either pre-project plans or post-project records and the same document could not serve both purposes cleanly.
Migration path
RDA’s recommendation is that v1 DMPs remain valid through 2027 and that v2 DMPs become the preferred format from 2026. Tools producing or consuming DMPs should support both formats during the transition window. The official RDA migration guide covers the field mappings; the CASRAI maDMP domain tracks tool-vendor support as it rolls out.
Specific migration considerations: v1 datasets representing software should be re-categorised as v2 software resources; v1 datasets representing samples should be re-categorised as v2 sample resources; v1 contributors without ORCID iDs need ORCID iDs added before v2 validation will pass; v1 organisational affiliations need ROR IDs.
Tool support
By the v2 release, the major DMP tools (DMPonline, DMPTool, easyDMP, ARGOS) had announced support timelines. DMPonline and DMPTool committed to v2 export support in mid-2026 with import support later in the year. easyDMP shipped v2 support at the v2 release. ARGOS has v2 support in beta. Institutional and funder DMP services built on these tools inherit their support timelines.
The funder side of the integration is also moving. Several major funders had been ingesting v1 DMPs in machine-readable form for compliance tracking; the v2 transition gives them an opportunity to tighten ingestion validation and to use the richer FAIR-assessment structure. The CASRAI funder maDMP guide walks through the funder-side migration.
What this enables
The longer-term value of v2 is in the queries it enables across machine-readable DMPs at scale. A funder can ask: across all funded projects starting in 2026, which fraction declared FAIR-compliant deposit plans for their datasets, software, and samples? — and get a structured answer. An institution can ask: which projects on our books have DMPs that declare preservation costs, and what is our aggregate preservation-cost commitment? — and get a structured answer. v1 made these queries notionally possible; v2 makes them reliable.
For research administration, the practical posture in 2026 is to follow the funder migration. Where funders require v2, migrate; where they still accept v1, produce both. The migration is one-way (a v2 DMP cannot be cleanly downgraded to v1 if the new resource types are used) but the v1-to-v2 path is well-supported.
