Crossref's Rebuild Is a Continuity Test for Journals

Most journal teams notice infrastructure only when it misbehaves. A DOI deposit stalls on publication day. An API field changes and a dashboard goes quiet. A vendor account belongs to someone who left two years ago. A reporting screen that used to answer a simple question now has a replacement, but nobody knows whether the replacement exports the same evidence.

That is why Crossref's August 12, 2026 announcement deserves attention well beyond technical teams. Crossref said its board approved a three-year project using surplus funds to accelerate a redesign of the Crossref system, with USD 1.6 million a year for three years, about USD 4.9 million in total: https://www.crossref.org/blog/investing-4.9-million-of-our-surplus-in-rebuilding-the-crossref-system/. The organization described two large, tightly coupled monoliths, the Content System and REST API, that now do considerably more than they were originally built to do.

For editors, publishers, societies, and university presses, the announcement is not a warning that Crossref services are about to disappear. Crossref was explicit that services will continue while the rebuild proceeds, with transition plans and documentation where workflows need to change. The useful lesson is different: if a piece of shared infrastructure has to rebuild its center while serving more than 25,000 members and thousands of downstream services, journals should know exactly how their own publishing operation depends on it.

The Rebuild Is Not One Product Change

A journal may experience Crossref as a few familiar tasks: register a DOI, update metadata, check reports, fix a failed submission, use the REST API, or ask a vendor to handle all of it. Crossref described a much wider set of services that will be separated or redesigned over time, including internal APIs for user interfaces, member self-service, a new admin tool, ORCID auto-update, reports, funder matching, preprint matching, reference matching, XML API delivery, metadata enrichment, authentication and authorization, billing, notifications, Handle system interactions, and the deposit system itself.

That list matters because journals do not consume infrastructure as a neat org chart. A single accepted article may touch submission metadata, author identifiers, references, funder names, ORCID update permissions, production XML, DOI registration, title reports, billing evidence, discovery APIs, and downstream analytics. A platform rebuild at the infrastructure layer can therefore expose weak assumptions inside the publisher workflow.

The most common weak assumption is that a vendor or a long-serving staff member knows what happens. That may be true until a migration, staffing change, account review, deprecation notice, or failed deposit asks the journal to prove it.

Start With The Dependency Map

A useful Crossref continuity review does not start with a policy paragraph. It starts with a map. Pick one recent article and write down every point where Crossref data is created, changed, read, displayed, reconciled, or billed. Include the submission system, production tools, XML generator, hosting layer, DOI deposit route, vendor portal, Crossref reports, public article pages, citation widgets, indexing feeds, analytics tools, and staff spreadsheets.

• Who can submit or update DOI metadata, and is that access tied to a named role rather than a former employee?
• Which system is the source of truth for title, author, affiliation, reference, funding, license, and update metadata?
• Which workflows depend on Crossref REST API responses, reports, XML queries, or admin exports?
• Where are failed deposits and partial updates recorded, and who reviews them before publication is considered complete?
• What does the journal do if a tool is deprecated, an API integration changes, or a vendor handoff fails during issue close?

This exercise often reveals that Crossref is treated as both infrastructure and archive, but governed like an errand. Someone registers the DOI. Someone else checks the landing page. A third person handles a correction later. Nobody owns the continuity of the metadata record from first deposit through post-publication change.

Deprecation Notices Are Operational Evidence

Crossref's redesign announcement sits alongside a visible pattern of retirement and replacement. Its deprecated tools page lists the Event Data public API sunset on April 23, 2026, the removal of the legacy Metadata Manager interface on January 1, 2026, and earlier retirements such as the XML journal list: https://www.crossref.org/deprecated/. None of that is unusual. Serious infrastructure has to retire pieces that are obsolete, underused, expensive to maintain, or superseded by better services.

For journal managers, the point is not to complain about deprecation. The point is to treat deprecation as evidence that local workflows must be inspectable. If your article-status dashboard depends on an old report, name it. If your production vendor depends on an XML query route, document it. If your editorial office has no idea whether a service provider is using current or legacy tools, ask before the transition forces the question.

Good infrastructure stewardship includes a public roadmap, open notices, and community feedback channels. Good journal stewardship includes reading those notices before they become emergencies.

APIs Need Owners, Not Folklore

The Crossref REST API is not just a convenience for developers. It is a dependency for discovery tools, institutional dashboards, metadata audits, library services, recommender systems, citation analysis, and internal publisher reports. Crossref said its REST API is one of the major monoliths whose current architecture makes change harder than it should be. That should prompt publishers to inventory API use with more seriousness than a casual developer note.

Start with the queries that matter most. Which public pages call Crossref data at runtime? Which scheduled jobs reconcile references, funders, citations, or DOIs? Which internal reports assume a specific field, relationship, or response shape? Which spreadsheets or notebooks have become unofficial production checks? Which integrations cache metadata, and for how long?

Then assign owners. An API integration without an owner is a future outage with a nicer name. Ownership does not mean one person has to maintain every script. It means the publisher knows who monitors notices, tests changes, updates credentials, reviews errors, and can explain the fallback if a dependency becomes temporarily unavailable.

Vendor Governance Has To Get Specific

Many journals do not deposit directly. A platform vendor, production house, DOI agent, hosting provider, or society-services partner may handle registration and updates. That can work well, but it can also hide risk. The publisher still owns the published record, even when a supplier pushes the button.

The next vendor review should include dull, precise questions. Which Crossref tools and APIs do you use today? How do you monitor Crossref roadmap and deprecation notices? How quickly can you update an article DOI record after a correction, retraction, title change, license change, or URL migration? Do you preserve submission receipts and error logs? Can the publisher export its Crossref-facing metadata and deposit history if the relationship ends? Who controls user access and credentials?

Those questions may feel more like procurement than editorial work. They are editorial work. If a journal cannot correct its metadata, recover deposit evidence, or prove who changed a DOI record, the integrity of the public article record is weaker than the editorial decision behind it.

Continuity Is Part Of Research Integrity

Crossref connects the system redesign to the Research Nexus, its term for a richer open network of relationships among research organizations, people, objects, and actions. It also points to the Principles of Open Scholarly Infrastructure, which emphasize governance, sustainability, and protection of community interests: https://openscholarlyinfrastructure.org/. These ideas can sound abstract until a reader follows a DOI to the wrong landing page, a funder identifier fails to travel, a correction relationship is missing, or an article's publication status differs across systems.

Continuity is not only uptime. It is the ability to keep the scholarly record coherent while systems change around it. A journal that can publish on Friday but cannot reconstruct what it deposited on Monday has a continuity problem. A publisher that can register new DOIs but cannot reliably update old ones has a continuity problem. A society that depends on one staff member and one vendor login for all Crossref work has a continuity problem.

This is where infrastructure news becomes a leadership agenda. The board does not need to debate API schemas. It does need to ask whether the journal has a tested path for DOI registration, metadata updates, credentials, vendor transition, and post-publication record repair.

A Practical Takeaway For Journal Leaders

Run a half-day Crossref continuity drill before the end of the quarter. Choose one article published in the last month, one corrected article, and one older article from a migrated platform. For each, compare the journal page, DOI resolution target, Crossref metadata, production XML if available, internal manuscript record, vendor deposit evidence, and any dashboard or report that leadership uses. Record every mismatch and every place where ownership is unclear.

Then write a two-page continuity note. It should name the systems that create or consume Crossref data, the people or vendors responsible for them, the credentials and access model, the monitoring cadence, the escalation path for failed deposits, and the fallback if a service changes. Keep it close to the publication workflow, not buried in a general IT policy.

Crossref's rebuild is a healthy sign that shared scholarly infrastructure is being maintained rather than patched indefinitely. Journals should respond in the same spirit. The right question is not whether anything will break tomorrow. The right question is whether your own operation knows where the record depends on Crossref, who owns each dependency, and how the journal will keep publishing cleanly while the infrastructure underneath it gets better.