DMPTool, the free data management plan (DMP) authoring service operated by the University of California Curation Center (UC3) at the California Digital Library (CDL), is in the middle of a full technical rebuild. The project was originally aimed at a summer 2026 release; as of the CDL’s own DMP Tool Rebuild Information Hub, that target has slipped to late 2026, after the team paused mid-project to reassess in response to the NIH’s and NSF’s 2026 data management and sharing plan (DMSP) format changes. This piece covers what’s actually changing, why the timeline moved, and what it means for institutions currently running plans through DMPTool.
Why DMPTool is being rebuilt
Per CDL’s own account, the rebuild has three stated goals: extend machine-actionable functionality across the entire DMP rather than treating it as a bolt-on feature, modernize a technology stack that has become harder to maintain, and improve the interface institutions use to build and manage best-practice templates. DMPTool’s current production system is a monolithic Ruby on Rails application, built on the same open-source DMPRoadmap codebase it shares with the Digital Curation Centre’s DMPonline. The rebuild moves DMPTool to a service-based TypeScript architecture: an Apollo Server (GraphQL) engine, a Next.js front end, and a Fastify REST API, replacing the monolith rather than patching it.
The machine-actionable DMP angle
The rebuild’s headline goal — machine-actionable functionality across the whole plan — connects directly to the broader push toward machine-actionable DMPs (maDMPs): DMPs structured as queryable data rather than static narrative documents, so systems (funders, repositories, institutional research information systems) can read and act on plan content programmatically instead of a human re-keying it from a PDF. CDL states it is building the new API to the common API standard under development with the Research Data Alliance (RDA), specifically so integrations built against DMPTool’s API have a reasonable chance of also working against other DMP service providers using the same standard — a deliberate interoperability choice, not a DMPTool-only API.
CDL is inviting institutions and developers interested in early access to the new API to build integrations ahead of general release; details are tracked on the rebuild hub page linked above. This is worth tracking for any institution that already integrates DMPTool data into an institutional repository, RIMS, or grants system, since a stable, RDA-aligned API is a materially different integration surface than the current one.
Why the timeline moved from summer to late 2026
The original public framing was a summer 2026 release, with the team’s own stated rationale for that specific window being to land before the fall teaching term, when many institutions use DMPTool in DMP-writing instruction and a mid-semester changeover would be more disruptive. CDL has since said, via the rebuild hub, that the team paused and reassessed the rebuild’s scope after NIH and NSF rolled out their own 2026 DMSP format changes — NSF’s move to a Research.gov web form (effective April 27, 2026) and NIH’s shift to a largely structured, mostly yes/no question format (effective May 25, 2026) — reasoning that folding those requirements into the rebuild properly was worth prioritizing over holding the original date. CDL frames this explicitly as choosing quality and reduced disruption over speed, and is continuing to test and refine how the new NIH and NSF formats are handled inside DMPTool as 2026 progresses. As of this writing, CDL has not published a firmer date within “late 2026” than that.
For background on the NIH/NSF format changes themselves, independent of the DMPTool rebuild, see CASRAI’s guide to using DMPTool for NSF and NIH data management plans and the NIH vs. NSF data management plan comparison.
What changes for existing users
- Account and plan migration: CDL states all accounts, plans, templates, and guidance content will transfer to the new system automatically — institutions and individual researchers are not expected to manually re-create their plan library. Users may need to reset their password on first login to the new tool.
- Possible formatting changes on migrated content: because the rebuild changes the underlying data structure (not just the interface), CDL has flagged that some legacy plans may show formatting differences after migration. Institutions with a large existing plan library may want to spot-check a sample of migrated plans once the new tool is live, rather than assume a 1:1 visual match.
- No parallel run of old and new: CDL has said the current DMPTool will not be kept running alongside the rebuilt version once it launches, citing resource constraints — this is a cutover, not a gradual dual-track rollout. Institutions relying on DMPTool in coursework or active grant cycles should plan around a single transition date once CDL announces one, rather than assuming an extended overlap window.
- Same URL: DMPTool will remain accessible at dmptool.org through the transition; this is a backend and interface rebuild, not a migration to a new domain or product name.
- User testing has been ongoing: CDL reports it had completed four rounds of user testing as of its most recent rebuild-hub update, and is continuing to solicit feedback from institutions and researchers ahead of release.
Funding and stewardship
CDL identifies the Institute of Museum and Library Services (IMLS), the National Science Foundation (NSF), and the Chan Zuckerberg Initiative as supporters of the rebuild. DMPTool itself continues to be operated by UC3/CDL and remains built on the shared open-source DMPRoadmap codebase used by DMPonline, so this is a rebuild of DMPTool’s own deployment and interface rather than a fork away from that shared codebase.
How to stay current, and what CASRAI will track
Because CDL has not committed to a specific date within “late 2026,” and because the rebuild already slipped once from its original window, institutions with DMPTool-dependent workflows — course syllabi built around it, grant-cycle timing, integrations with institutional systems — should treat any specific release date as provisional until CDL confirms it directly, and should watch the DMP Tool Rebuild Information Hub itself rather than secondary summaries, since that page is where CDL is posting incremental updates. This page will be revisited if CDL sets a firmer date or the rebuild ships.
For the underlying tool as it exists today, see CASRAI’s DMPTool dictionary entry, the step-by-step usage guide, the ROR and Funder Registry auto-fill guide, and the DMPTool vs. DMPonline comparison — none of those pages describe the rebuild itself; this page is specifically about the rebuild and its timeline.
Frequently asked questions
Is DMPTool shutting down during the rebuild?
No. CDL has said the existing DMPTool will keep running at dmptool.org until the rebuilt version is ready to replace it; there is no announced gap in service. The two versions will not run in parallel once the new one launches, but that is a cutover point, not a downtime period.
Will my existing DMPs and templates carry over?
CDL states accounts, plans, templates, and guidance content will migrate automatically, though some formatting differences are possible on older plans because of underlying data-structure changes. A password reset on first login to the new system is expected.
Does the rebuild change how NIH or NSF plans work in DMPTool today?
Not directly — the 2026 NIH and NSF format changes are a separate policy shift from funders themselves, and DMPTool has already been updating its templates to reflect them ahead of and independent of the rebuild. The rebuild’s connection to those changes is that CDL paused to fold the new formats into the rebuilt architecture properly rather than layering them onto the old system and then rebuilding again.
Will the new DMPTool API only work with DMPTool?
CDL says it is building the new API to the common standard under development with the Research Data Alliance specifically so that integrations should also work with other DMP service providers using the same standard, though this depends on other providers implementing that same standard.
