Digital Repository RFPs: 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

Here's the thing about repository RFPs:

Most of them are not great. Not because librarians don't know what they need. But because they're trying to force fundamentally different solutions—hosted SaaS, open source, proprietary systems—into the same procurement framework. That's like asking for quotes for a pickup truck and a school bus using the same form. They both get you from point A to point B and carry stuff, but the manufacturers, features, and underlying mechanics are fundamentally different, and a single set of questions won't effectively evaluate which one is right for your specific needs.

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

After working through tons of repository migrations, modernizations and upgrades, and net-new implementations, let’s examine what actually matters when structuring your RFP, and what's just 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 actually 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 assume you're buying a commodity—something with fixed features and predictable costs. But digital repositories aren't commodities. They're 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 try to force repository procurement into generic RFP frameworks, three problems emerge:

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

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

3. Innovation gets penalized because newer solutions that solve problems differently can't 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 Requirements: The MoSCoW Method

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

A fantastic repository RFP we recently reviewed used 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)

Features that significantly improve value but where 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)

Enhancements that would be valuable but aren't critical for launch - these give vendors the option to price things that are value-add, or otherwise say "we can't do that".

• 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, especially if you have a lot of stakeholders at a lot of different levels of your organization that would want to be involved, and provide inputs.

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 get you comparable proposals

Discovery sprints cost $10-20K.

Yeah, that's real money. But you'll waste more than that if your RFP compares incomparable solutions, or you land on the wrong solution.

One client told me the discovery sprint paid for itself in the first vendor negotiation. They knew exactly 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 terrible at discovery. Discovery systems (Hyku, Hyrax, DSpace) aren't true digital preservation. Pick 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 killing academic repositories right now)

• 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 comes when you want a separate Avalon instance's streaming interface embedded seamlessly into your Hyku repository with single sign-on and unified search. That's 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 talking hours and complexity, run.

Your RFP Should Enable Partnership, Not Just Procurement

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

• Sharing context: Why are you making this change? What's 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: Range is fine, but vendors need to know if you're thinking $50K or $500K

A Template That Actually Works

Based on successful procurements at peer institutions, 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, you might benefit from a consultation or a more focused internal discovery process before launching your RFP.

Scrappy ≠ Crappy!

Further, if you don't have quantitative and qualitative data on what your users need, you're going to be guided largely by opinions of stakeholders. It's worth doing some scrappy research up-front 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 result in confusion and misaligned expectations. We've also helped institutions design RFPs that get them 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, and smaller universities and colleges as well.

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