Digital Repository RFP Best Practices: How to Write Requirements for Institutional Repository Software (with template!)

Quick Guide: Repository RFP Essentials

• Purpose: Procure institutional repository or digital collections platform

• Common Systems: Hyku, Hyrax, DSpace, Islandora, Digital Commons

• Budget Range: $50K-$500K implementation, $20K-$100K annual

• Timeline: 3-12 months from RFP to contract

• Download: Free RFP template below

  
  

Understanding Repository RFPs

Here's the thing about repository RFPs: Most of them are not great. This isn't due to a lack of knowledge from librarians. Instead, it's because they attempt to fit fundamentally different solutions—hosted SaaS, open source, proprietary systems—into the same procurement framework. This approach is flawed. It's akin to asking for quotes for a pickup truck and a school bus using the same form. While both vehicles transport you from point A to point B, their manufacturers, features, and underlying mechanics differ significantly. A single set of questions won't effectively evaluate which option is right for your specific needs.

Whether you're replacing DSpace, migrating from ContentDM, or transitioning from Elsevier Digital Commons, writing an effective institutional repository RFP requires a clear understanding of how digital repository software differs from other enterprise systems.

After navigating numerous repository migrations, modernizations, upgrades, and new implementations, let's delve into what truly matters when structuring your RFP. We'll also identify what's merely procurement theater that wastes everyone's time.

The structure of your RFP directly impacts the quality of proposals you receive. More importantly, it determines whether you'll be able to compare those proposals meaningfully.

An effective repository procurement process

Why Traditional RFPs Fail for Digital Repository Projects

Many RFP templates weren't designed for the complexity of academic digital infrastructure. They often assume you're purchasing a commodity—something with fixed features and predictable costs. However, digital repositories are not commodities. They are strategic platforms that must evolve with your institution's research output, adapt to changing preservation standards, and integrate with an ecosystem of academic technologies.

When institutions attempt to force repository procurement into generic RFP frameworks, three significant problems arise:

1. Vendors can't differentiate meaningfully because the requirements are either too broad or too specific to legacy architectures.

2. True costs remain hidden because hosting, migration, customization, and long-term support are bundled differently by each vendor.

3. Innovation gets penalized because newer solutions that solve problems differently struggle to demonstrate their value within rigid requirement matrices.

4. A lack of a full understanding of user needs and pain points leads to opinions around functional requirements that aren't grounded in practical reality.

   
   

Digital Repository RFP Best Practices: The MoSCoW Method

MoSCoW Framework Visualized - helping vendors understand prioritization and budget allocation.

A fantastic repository RFP we recently reviewed utilized the MoSCoW prioritization framework. Here’s why it works:

Must Have (Non-negotiable)

These are your deal-breakers. For most institutions, this includes:

• Digital preservation capabilities (checksums, versioning, OAIS compliance indicators)

• Authentication integration (SAML, Shibboleth, CAS)

• Accessibility compliance (WCAG 2.2 AA)

• OAI-PMH harvesting

• Bulk import capabilities

• Clear performance benchmarks

  
  

Should Have (Important but flexible)

These features significantly enhance value, but you're open to different approaches:

• IIIF support for collections

• Authority-controlled vocabularies

• Flexible metadata schemas (coming in Hyku 6.2, for example)

• Google Analytics 4 or Matomo integration

• DOI minting

  
  

Could Have (Nice to have)

These enhancements would be valuable but aren't critical for launch. They allow vendors to price value-add features or indicate if they can't provide them:

• Advanced data visualization

• Integrated streaming media support

• Social media integration

• Custom work type creation through UI

  
  

Won't Have (Out of scope)

Being explicit about what you don't need prevents scope creep and helps vendors focus their proposals.

The Discovery Sprint Alternative: When You Need Clarity Before the RFP

Sometimes, the best RFP strategy is to delay writing it. This is especially true if you have many stakeholders at various levels of your organization who want to provide input.

If you're struggling to articulate requirements or compare fundamentally different approaches (hosted vs. self-hosted, open source vs. proprietary, preservation-first vs. access-first), consider a discovery sprint first. For $10-20K, you can engage a partner to:

• Map your actual workflows and pain points

• Identify which features truly matter for your use cases

• Understand the total cost implications of different architectures

• Create an RFP that will actually yield comparable proposals

  
  

Discovery sprints cost $10-20K. Yes, that's a significant investment. However, you'll waste more than that if your RFP compares incomparable solutions or if you end up with the wrong solution. One client mentioned that the discovery sprint paid for itself during the first vendor negotiation. They knew precisely what to push for and what didn't matter.

Essential Institutional Repository RFP Sections Most Templates Miss

1. Migration Complexity Acknowledgment

Don't just ask, "Can you migrate our data?" Specify:

• Current system (ContentDM, DSpace, Fedora, Islandora, Digital Commons/BePress, CONTENTdm, Omeka, or homegrown)

• Number of objects and total storage

• Metadata remediation expectations

• Acceptable downtime windows

• Parent-child relationship handling

  
  

2. Preservation vs. Access Philosophy

Be explicit about your priorities:

• Are you primarily preserving content for long-term access?

• Do you need robust presentation layers for public engagement?

• Would you consider separate systems for preservation and discovery?

  
  

The truth nobody wants to hear: You probably need two systems. Preservation systems (Preservica, Archivematica) are not effective for discovery. Conversely, discovery systems (Hyku, Hyrax, DSpace) do not provide true digital preservation. Choose your primary need and accept compromises on the other, or budget for both.

3. Sustainability and Exit Strategy

Ask vendors to address:

• What happens to your data if the vendor disappears?

• How do you export everything if you need to switch platforms?

• Who owns customizations, and can they be maintained independently?

• What's the upgrade path, and who bears the cost?

  
  

4. Performance Under Real Conditions

Instead of asking for "system requirements," specify your actual load:

• Expected concurrent users

• Bot traffic mitigation (this is currently a significant issue for academic repositories)

• Largest files you need to support

• Full-text search requirements for PDF collections

  
  

5. What Actually Requires Custom Development

Be honest about these common requests that vendors might undersell:

• Avalon does streaming beautifully—it's built for it. The custom work arises when you want a separate Avalon instance's streaming interface embedded seamlessly into your Hyku repository with single sign-on and unified search. This is a technically complex integration that shouldn't be underestimated.

P.S. - Clover IIIF viewer can do streaming beautifully right within Hyku.

• Integration with your homegrown faculty profile system? Custom.

• Replicating your 10-year-old repository's exact workflows? Definitely custom.

• Making it look exactly like your main library website? You guessed it.

  
  

If a vendor says "yes" to everything without discussing hours and complexity, run.

Your RFP Should Enable Partnership, Not Just Procurement

The best repository implementations I've seen treat vendors as partners, not merely service providers. Your RFP should invite that partnership by:

• Sharing context: Why are you making this change? What has failed about your current approach?

• Being flexible on solutions: Describe problems, not just prescribed solutions. The fewer solutions you prescribe, the more pressure is placed on the vendor to solve the problems and meet your needs.

• Acknowledging uncertainties: It's okay to say, "We need help figuring this out."

• Providing realistic budgets: A range is fine, but vendors need to know if you're thinking $50K or $500K.

  
  

A Template That Actually Works

Based on digital repository RFPs at peer institutions and the best practices above, here's a structure that generates quality proposals:

Section 1: Institutional Context (1 page)

• Your collections' scope and significance

• Current pain points and trigger for change

• Success metrics for this project

  
  

Section 2: Functional Priorities (MoSCoW framework)

• Must have (showstoppers)

• Should have (high value)

• Could have (nice to have)

• Won't have (explicitly out of scope)

  
  

Section 3: Technical Environment

• Current repository details

• Authentication infrastructure

• Storage preferences (cloud, on-premise, hybrid)

• Integration requirements

  
  

Section 4: Project Approach

• Timeline drivers (grant deadlines, leadership changes, collection acquisitions)

• Available resources for testing and feedback

• Preference for phased vs. big-bang implementation

  
  

Section 5: Evaluation Criteria

• How you'll score proposals (not just cost)

• How and when vendors may ask questions about the RFP and gain insight necessary to guide their approach

• Who's on the evaluation committee

• Proof-of-concept expectations

  
  

Section 6: Budget and Sustainability

• One-time implementation budget range

• Annual operating budget expectations

• How you'll evaluate TCO over 5 years

  
  

The Conversation You Should Have Before Writing Your RFP

Before you spend weeks crafting the perfect requirements matrix, ask yourself:

1. Do we really understand what's possible with modern repository platforms?

2. Are we optimizing for our current workflows or willing to adopt best practices?

3. Would our users be better served by a single system or purposefully separated concerns?

4. Do we have internal expertise to evaluate technical proposals accurately?

   
   

If you answered "no" or "unsure" to any of these questions, you might benefit from a consultation or a more focused internal discovery process before launching your RFP.

Scrappy ≠ Crappy!

Furthermore, if you lack quantitative and qualitative data on what your users need, you'll be guided largely by stakeholder opinions. It's worth conducting some scrappy research upfront to ensure you don't have any blind spots.

Scrappy Research Definition

Scrappy ≠ Crappy. Scrappy research brings you closer to your users, but it's orderly and focused. Here's how you should approach:

1. Spend a little time organizing your thoughts around your users, both internal (AULs, Archivists, general repository admins and IT), and external (patrons, students, researchers, instructors).

2. Generate a list of questions you'd like to ask each, or a process/goal with your current solution you'd like them to walk through/achieve.

3. Time-box it, and make it achievable in a short amount of time. The goal here isn't statistical significance. It's generating user insights and understanding. This will help you focus on the value your next solution needs to deliver, and the problems it really needs to solve.

Making scrappy research part of your organization's DNA will drastically transform your library's or department's culture to be user-focused, and one that is always on the forefront of delivering real value to your institution or organization.

Let's Make Your RFP Work Harder for You

At Notch8, we've responded to enough RFPs to know which ones attract quality proposals and which ones lead to confusion and misaligned expectations. We've also assisted institutions in designing RFPs that deliver exactly what they need—sometimes solutions they didn't even know were possible.

Repository RFP FAQs

• Q: How long should an institutional repository RFP be? A: 10-15 pages maximum. Focus on outcomes, not prescriptive requirements.

• Q: Should we require DPLA compliance in our repository RFP? A: Only if you're actively contributing. Most modern repository platforms support DPLA harvesting via OAI-PMH.

• Q: How do we evaluate open source (Samvera / DSpace) vs proprietary repository vendors? A: Compare total cost of ownership over 5 years, including hosting, support, and development needs.

  
  

Want help with your RFP? Let's talk.

30-minute call.

No sales pitch.

We'll tell you what works for some of the country’s premier research institutions, as well as smaller universities and colleges.

If your RFP is solid already, I'll tell you that too.

Schedule Your RFP Strategy Session by reaching out to sales@notch8.com

Download RFP Template Here

Related:

Hyku vs Hyrax: Frequently Asked Questions for Academic Institutions