You're about to sign a contract for a digital preservation platform that meets every requirement on your checklist. The vendor demos well. The pricing fits your budget. But here's the question no one wants to ask: what happens when this vendor gets acquired, pivots to a different market, or simply stops supporting the format you've standardized on?
If you don't have a clear answer, you're building a preservation system on quicksand.
The Problem: Procurement Treats Exit as an Afterthought
Most digital preservation procurement processes focus on what a system can do today. You build a requirements matrix, score vendor responses, and run pilots. But the hard truth is that every system you deploy will eventually be replaced. Every vendor relationship has a shelf life.
The Digital Preservation Coalition panel with preservation vendors highlighted a critical insight: digital preservation isn't about building an archive that lasts forever. It's a relay. Your job is to ensure the baton passes cleanly from system to system, team to team, decade to decade. That means your procurement criteria must prioritize portability, not just capability.
When exit strategy becomes a footnote in your RFP instead of a core design principle, you're setting up your successor for a painful migration project with data locked in proprietary structures and no documented export pathway.
What You Need Before Starting
Before you write a single line of your RFP, get these elements in place:
Internal alignment on strategic goals
Convene stakeholders from IT, legal, compliance, and business units. Clarify what outcomes you need: regulatory compliance, long-term research access, litigation readiness. Define who owns digital preservation after implementation. If you can't answer "who will run this in five years?", you're not ready to buy.
Honest assessment of your expertise
Determine your team's appetite for hands-on preservation work versus automated workflows. A platform that requires deep technical knowledge of PREMIS metadata won't work if you have one archivist managing preservation alongside three other responsibilities.
Data growth projections
Model both realistic and worst-case scenarios. Panel participants emphasized that data growth almost always exceeds initial estimates. If you're planning for 10TB and you hit 50TB in year two, can your architecture and budget handle it?
Cost model clarity
Understand the difference between storage tiers. Not all content needs "hot" access. Map your access patterns to storage costs. Ask vendors to explain egress fees, per-seat licensing, and any charges that scale with use. Request pricing for a full migration scenario, not just steady-state operation.
Step-by-Step Implementation
Step 1: Start vendor conversations early
Reach out to vendors six to twelve months before you plan to issue an RFP. These aren't sales pitches. Frame them as collaborative learning sessions. Share your preservation challenges. Ask vendors to walk through how their systems handle format migration, metadata extraction, and data export. Use these conversations to refine your requirements and avoid "blind RFPs" that limit vendor insight.
Step 2: Define outcome-based requirements, not feature checklists
Instead of "System must support 47 file formats," write "System must enable us to preserve and provide access to research datasets for 30 years, complying with NIH data-sharing requirements." Outcome-based requirements invite vendors to propose creative solutions instead of checking boxes.
Step 3: Require open standards at every layer
Your RFP must mandate:
- Open preservation formats: Look for support of BagIt, METS, PREMIS, e-ARK SIP/AIP/DIP structures, and OCFL (Oxford Common File Layout).
- Standardized metadata: Require PREMIS for preservation metadata. Specify how the system exports metadata in documented, non-proprietary schemas.
- Full-function APIs: Demand APIs that mirror the complete functionality of the platform's UI. If you can't script a full export via API, you don't have a real exit path.
Step 4: Evaluate exit strategy as a primary criterion
Score vendor responses on exit readiness:
- Can the vendor demonstrate a complete data export, including all metadata, in an Open Archival Information System (OAIS)-compliant Archival Information Package structure?
- Is the export format documented in publicly available specifications?
- Can you retrieve your data without vendor assistance if the relationship ends?
- What happens to your data if the vendor's business fails?
Request a live demonstration of the export process during vendor evaluations. Don't accept promises. See the data.
Step 5: Negotiate transparency into your contract
Include contractual language that requires:
- Annual export tests to a documented AIP structure
- Notification if the vendor changes ownership or shifts product strategy
- Data return procedures with defined timelines if the contract terminates
- Escrow arrangements for source code or export tools if the vendor ceases operations
Step 6: Plan for process change
Your new system will require workflow adjustments. Don't force the platform to replicate broken legacy processes. Document your current state, but stay open to re-engineering ingest, description, and access workflows. Involve end users early so they understand why changes are happening.
Validation: How to Verify It Works
Test 1: Full export within 30 days of go-live
Export a representative sample of your holdings to an external location. Verify that you receive:
- All content files with original filenames and directory structures
- Complete preservation metadata in PREMIS XML or equivalent
- Submission Information Package and Archival Information Package manifests
- Checksums (fixity information) for every file
Test 2: Metadata round-trip
Export metadata, modify it in an external tool, and re-import. Confirm that your changes persist and that the system doesn't overwrite or corrupt metadata during the round-trip.
Test 3: API completeness
Attempt to perform every critical preservation action via API: ingest a new SIP, update metadata, generate a Dissemination Information Package, export an AIP. If any function requires manual UI intervention, document it and push the vendor to close the gap.
Test 4: Storage tier verification
Confirm that content is landing in the correct storage tier based on access frequency. Validate that retrieval times match vendor SLAs.
Maintenance and Ongoing Tasks
Quarterly: Run fixity checks
Verify checksums across your entire repository. Most platforms automate this, but confirm that fixity failures trigger alerts and that you have a documented response process.
Annually: Execute a full export test
Don't wait for a crisis. Export a full collection to a separate storage location. Validate the export against OAIS reference model requirements. Document the time and cost required. This exercise keeps your team trained and surfaces problems before they become emergencies.
Annually: Review vendor roadmap
Schedule a roadmap review with your vendor. Ask about upcoming format support, API enhancements, and any changes to pricing or service models. If the vendor is moving away from open standards or adding proprietary lock-in features, escalate internally.
Every three years: Re-evaluate your architecture
Technology shifts. Your organization's preservation needs evolve. Revisit your original outcome goals and assess whether your current platform still serves them. If not, your open standards foundation makes migration feasible instead of catastrophic.
Digital preservation is a relay, not a monument. Plan for the handoff from day one.
