For ITHAKA, JSTOR Digital Stewardship Services is not just a platform but an engineering practice. In this blog post, we’ll describe how hundreds of participating institutions were able to continue doing their work without meaningful interruption while our engineers progressively rebuilt the infrastructure underneath it.
Systems become outdated when they fall behind on security protections or fail to meet modern accessibility standards. New features can’t be built because the underlying infrastructure is outdated, and can’t be readily updated without meaningful investment.
If the underlying infrastructure does not provide a durable foundation, it’s more difficult and costly, if not actually impossible, to build new features. And without new features, systems first become stale, and then become strategic impediments. As that happens, it becomes harder to justify meaningful investment in updating the underlying infrastructure.
Over the past few years, we confronted this dilemma here at JSTOR. Forum, our platform for managing and sharing collections, continued to support hundreds of participating institutions—many of which had built collections, workflows, and expertise around it over many years. At the same time, our work with libraries and archives was revealing stewardship needs that were becoming harder to support within a platform shaped by an earlier set of assumptions.
Strong infrastructure enables strategic innovation. Bearing this in mind, over the past several years, we reinvested to provide the modern foundation for JSTOR Stewardship. This work to maintain infrastructure, combining routine and ongoing tasks with innovation and careful architectural change, does not always receive the recognition that it deserves. If we’re successful, we will have maintained what participants valued, created substantially more room for the platform to evolve in support of our participants, and in turn, minimized disruption to their work along the way. Here is the approach our engineers took.
Reinvesting
The platform we were building from had a long and important history. Its origins reached back to Shared Shelf, which was developed by Artstor in partnership with colleges and universities to help institutions manage, organize, and share their local digital media collections on the Artstor platform. Its development was closely informed by the needs and practices of the visual resources and art history communities.
As Artstor became part of JSTOR, Shared Shelf evolved in scope and purpose. Renamed JSTOR Forum, it enabled libraries to manage and share a broader range of materials on JSTOR, extending their discoverability and reach. Hundreds of institutions ultimately built collections and workflows around the platform, bringing with them years of professional practice and institutional knowledge.
At the same time, our research was suggesting that the work around those collections was becoming broader and more demanding.
The research included Bridging Capacity and Care, a field report based on research with more than 280 library and archival professionals across 24 institutions. The report documented consistent pressures shaping day-to-day stewardship work: backlogs in digitization and description, growing volumes of born-digital material, metadata bottlenecks, and expanding expectations for preservation, accessibility, and discovery—all amid limited staff and resources.
The result was a widening gap between what institutions wanted to do with their collections and what existing systems and workflows could readily support.
Forum had evolved considerably alongside changing stewardship work, but some aspects of its architecture reflected assumptions established much earlier in its history. Addressing emerging needs sometimes required more than adding another feature or improving an interface; it required reconsidering parts of the foundation itself.
Supporting a fuller range of stewardship work therefore required more than continuing to add functionality to the existing foundation. Our engineers recognized that we needed to rebuild the foundation while carrying forward the workflows, expertise, and practices that participants valued.
Rebuilding
We started building Stewardship in connection with our decision to begin building JSTOR Seeklight, our AI-assisted collections processing technology designed to help libraries and archives process, describe, and understand digital collections at scale. Our engineers had concluded that Forum would not be an adequate platform to support our expanding ambitions, not just for JSTOR Seeklight but a variety of other participant needs. So we started to build the Stewardship infrastructure to ensure we had the foundation for Seeklight, recognizing that over time we would need to build it up further.
As we began building Stewardship to take on the core capabilities of Forum, we incorporated modern software engineering practices that would make the platform easier to evolve over time. Much of this work happens behind the scenes, but these engineering decisions shape how quickly the platform can evolve, how reliably it operates, and how confidently new capabilities can be introduced over time. These decisions are the foundation on which the participant experience is built. For example, Forum was built as a fairly monolithic application, with different features interconnected with one another. A change that we wanted to make often looked small from a participant’s perspective, but it was far more complicated—unnecessarily so—for our engineering team. This slowed the pace of development, frustrated our team, and resulted in occasional instability.
With JSTOR Stewardship, our engineers wanted to create clearer boundaries between parts of the platform so we could make changes in smaller pieces. Rather than treating the interface as one tightly connected application, we adopted a microfrontend architecture that allows individual areas of the experience to be developed, tested, and released more independently. Participants continue to experience Stewardship as a single platform, but behind the scenes this approach allows our engineering teams to improve individual workflows without unnecessarily impacting the rest of the application. We made a similar shift beneath the interface by separating major responsibilities such as metadata, relationships, and search. Participants still experience these as one environment, but the clearer boundaries make it easier to improve one part of the platform without affecting another.
Accessibility became another opportunity to rethink the platform rather than simply update it. As we rebuilt Stewardship, we incorporated accessibility into our design and engineering process from the beginning instead of treating it as a separate remediation effort after features were completed. Modern accessibility testing and design-review practices helped us identify issues earlier, improve consistency across the interface, and establish patterns that make future improvements easier to implement. The result is not simply a more accessible platform for today, but a foundation that makes accessibility an ongoing part of how the platform will evolve. This made it possible to test more selectively, improve areas such as accessibility more systematically, and allow different parts of the experience to evolve more independently.
The new infrastructure is also more maintainable, in part because of added observability built in throughout. When something goes wrong, engineers can now trace a user problem by using modern monitoring and diagnostic tools, so bug hunting that once could take hours can sometimes now take minutes.
Along the way, we examined many different participant practices, looking for where we should carry over experiences and where we could improve them in the course of the rebuild. Metadata management provides a good example. Many Forum participants relied heavily on spreadsheets to manage metadata across large collections and fit the platform into established local workflows. Rather than replace that familiar practice, we carried Excel import and export into JSTOR Stewardship while rebuilding the underlying capability to support much larger jobs.
Bulk editing illustrated the other side of the same principle. Participant research showed that what appeared to be a single function actually supported different kinds of work. Some practitioners wanted to make a quick change across many records. Others were doing more substantial cataloging and needed to see the context of the full record. We redesigned the experience accordingly, expanding the workspace and making more record context visible.
Transitioning
The same concern for continuity shaped how we moved participants from Forum to Stewardship. Our goal for the infrastructure transition was institutional continuity.
Moving hundreds of institutions to a new environment involved more than learning a new interface. Libraries had established workflows around Forum, wrote their own documentation, trained staff and student workers, and incorporated the platform into local processes. We wanted institutions to have time to adapt while continuing the work they needed to do.
Following initial research and user acceptance testing, all Forum participants received access to Stewardship in November 2025 while Forum remained available. Because Stewardship was built to work with the digital assets participants were already managing in Forum, institutions didn’t have to migrate their collections into a separate system. This meant that during the dual-access period, institutions could focus on becoming familiar with JSTOR Stewardship and adapting local workflows while continuing to manage their collections on either platform without creating and maintaining a second copy of their content.
The parallel access period was also part of the product development process. Formal research and testing can reveal a great deal, but there is no substitute for seeing a much larger number of institutions use a system with their own collections and established workflows. Participants surfaced bugs, edge cases, and areas of friction that earlier testing had not revealed. That gave us time to address those issues while Forum remained available.
Forum access ended in June 2026. Participants’ collections, projects, data, and credentials continued into JSTOR Stewardship; there was no single event in which hundreds of institutions had to migrate their content from one system to another.
The transition reinforced a principle that continues to guide the work: significant technological change benefits from room to learn. Introducing JSTOR Stewardship gradually gave participants time to adapt and gave us time to observe, listen, and improve before asking them to rely on it fully.
Retiring the Forum infrastructure will also allow our engineers to move away from systems that had become increasingly difficult to maintain. For participants, the more important benefit is what the new foundation enables next.
Flexibility
An early set of substantial new features are going to involve what we call “flexible organization,” which we have long wanted to provide for our participants.
Forum’s project-centered model worked well for many established workflows, but became limiting when institutions wanted to represent deeper archival hierarchies, or use the same item in multiple contexts. Doing so could require duplicated records or other workarounds, creating additional metadata work.
Archival collections rarely fit neatly into a single organizational path. They are hierarchical and overlapping at the same time. A single item may belong to a collection, a series, and a folder, while also being relevant to multiple thematic groupings, exhibitions, or institutional contexts. We also envision being able to take on incredibly powerful features across institutional boundaries as a result of the same underlying foundation.
To create more institutional flexibility and support archival practices, our engineers are implementing and validating a new relationship layer within JSTOR Stewardship. Instead of treating a project as an item’s permanent home, Stewardship is separating the item from the structures used to organize it, so the platform can eventually represent richer relationships without duplicating the item or redesigning the entire system. This layer works alongside existing systems: metadata continues to support description and management, and search continues to support discovery and retrieval. The new layer is focused specifically on how materials connect to one another, and how those connections can be used across different contexts. Participating institutions will remain in control of how their collections are represented, with a far wider set of options available to them.
To make this possible, our engineering team has implemented a new relationship layer, a substantial modernization of our database infrastructure that required significant planning and real care. Building this new relationship layer required more than introducing a new database. It required designing, validating, and carefully integrating an entirely new database while participants continued relying on the existing platform every day.
Rather than replacing the existing database all at once, our engineering team introduced the new layer alongside it. Every significant interaction could be processed by both systems while observability tools compared the results behind the scenes. The existing database continued to serve participants while engineers verified that the new relationship layer produced the same outcomes, handled relationships correctly, and performed reliably with real collections and workflows.
We also prepared for the possibility that something might not work as expected. Before participants depended on the new system, the team repeatedly tested deployment and rollback procedures so changes could be reversed safely, if necessary. Only after validating the new relationship layer over time did we begin moving institutions onto it incrementally rather than through a single large migration.
Throughout this work, our engineers approached the infrastructure with the same care our participants bring to their collections. The goal was not simply to modernize the platform, but to do so while protecting the continuity of the work that depends upon it.
The architectural constraints have now been addressed. With the new enabling infrastructure in place, we will begin building an array of flexible organizational features that we are designing in partnership with participating institutions.
A modern foundation
While there have been bumps in the road, we are incredibly proud of the care that our teams have taken throughout this stage of work. We took numerous steps designed to minimize disruption for our participants and protect the continuity of the stewardship work the platform exists to support.
Of course, modernization is not a destination. Today, the modern foundation that our engineers have laid down enables us to build more sustainably, more durably, and at greater velocity. We can’t predict every capability an institution will need five or ten years from now. That uncertainty is precisely why the modern foundation, with so much more flexibility, matters. It will enable us to evolve as new needs emerge: to improve one part without destabilizing another, and to represent collections in ways that better reflect their relationships and context.
This modern foundation has required real investment, which we are proud to have made on behalf of our participant community. With a platform that can keep changing responsibly as collections, practices, technologies, and participant needs change, we are confident that the returns to our community, and our shared purpose, are well worthwhile.
