NDE Migration Timing & Scoping
See Best Practices for Decision Pages and Tags for groups
Legend: not started IN PROGRESS STALLED decided
Status | decided |
|---|---|
Description | In order to shape the NDE migration project and timeline, decisions relating to golive timing and scoping effort must be made. |
Decision summary | Discovery OST recommends that all 10 campuses golive during Summer 2027 with a simultaneous golive date and with the effort scoped for meeting high priority needs. |
Owning group | Discovery OST SILS-DISCOVERY-L [@] LISTSERV.UCOP.EDU |
Approver | Discovery |
Consulted |
|
Informed | SILS Cohort |
Decision-making process | discussion and vote during May 15, 2026 meeting |
Priority | high |
Target decision date | May 15, 2026 |
Date decided | May 15, 2026 |
Recommendation
Discovery OST recommends that all 10 campuses golive during summer 2027 with a simultaneous golive date and with the effort scoped for meeting high priority needs. The scope will exclude these non-discovery aspects:
Exclude: Alma configuration changes
Exclude: metadata cleanup
Exclude: collection activation projects
Exclude: CDI troubleshooting unrelated to discovery
Exclude: Alma fulfillment redesign
Impact
Stakeholder group | Impact |
|---|---|
Discovery OST | Primary owner of NDE configuration (views, scopes, facets, display) Responsible for translating Primo VE behavior into NDE Must identify where configurations differ across IZs and decide what to preserve vs change Heavy involvement in testing (search behavior, facets, UI) Likely to receive the majority of cross-institution questions and change requests Pressure point for scope creep (standardization vs replication decisions) |
Operations Team | Configure and implement NDE across all IZs (views, integrations, settings) Act as the cross-system bridge (Alma, NDE, authentication, proxy, CDI) Manage customizations and integrations (JS/CSS, analytics, third-party tools) Absorb pressure from configuration differences and standardization requests Experience peak workload pre-testing and pre-go-live Carry high operational risk—issues in their work directly affect user access and functionality |
Resource Management OST | Ensures bibliographic and holdings data display correctly in NDE Validates indexing and record representation (titles, authors, subjects, formats) Identifies metadata inconsistencies exposed by new discovery behavior May be pulled into issues that are not actually metadata problems (misattribution risk) Limited direct configuration control, but high validation responsibility |
E-Resources OST | Responsible for electronic access behavior (CDI, linking, proxy) Must validate full-text availability and linking accuracy in NDE Likely to encounter pre-existing issues surfaced during migration High volume of testing scenarios (articles, journals, databases) Risk of scope expansion into broader e-resource cleanup work Critical to user-facing success; failures are highly visible |
Fulfillment OST | Ensures request workflows function correctly (holds, digitization, resource sharing) Validates integration between NDE and Alma fulfillment rules Tests logged-in vs logged-out behavior and request permissions Must confirm user account features (loans, requests, fines) work as expected Typically reactive—issues emerge during testing rather than configuration Failures directly affect user transactions, not just discovery |
Operations Center | Overall project management Responsible for timeline, dependencies, and decision tracking Must enforce scope boundaries (especially around “minimum needs”) Manages escalation and readiness tracking Balances uneven institutional readiness |
Reasoning
A golive date in summer is desirable for several reasons:
We expect that testing the new interface will be the most significant task at each campus. Using time during the summer for testing will allow for more participation by library staff who have heavier workloads during the regular academic year.
Patrons will have a consistent experience with Primo throughout an academic year.
Differing academic calendars (semesters vs. quarters) make alignment between campuses difficult during other parts of the year.
Ex Libris has given all institutions a deadline of January 2028 to migrate to NDE. Migrating in summer 2027 will give us the most possible time to thoroughly complete our configuration and testing.
Background
Discovery OST has decided that all ten campuses will migration to NDE from VE under the same project: Coordinated Ten Campus + CDL Migration to Primo Next Discovery Experience (NDE) . Each IZ has independently configured and customized their own discovery experience and UC does not use a shared discovery via the NZ.
Three decisions are tightly coupled:
When to go live (Summer 2027 vs. Winter 2027)
How tightly to couple the timing of golive (all at once or within a set amount of time)
How much effort to invest in configuration and customization(scope level)
These decisions affect:
project duration and complexity
coordination overhead across institutions
quality and stability at launch
ability to meet functional needs at go-live
Delaying the timing decision affects scheduling; delaying the scope decision affects what the project actually becomes.
Options Considered
Timing for golive
| Summer 2027 | Winter 2027 |
|---|---|---|
Description | An NDE golive date sometime after Spring 2027 classes end and before Fall 2027 classes being | An NDE golive date after Fall 2027 classes (or towards the end of Fall 2027) |
Pros | Delivery in between academic years more staff time available for testing more time available for documentation updates if golive timings loosely coupled, more timing options | more time overall for testing, configuration, etc. more time for advocacy with vendor more time for configuration & customizations |
Cons | less time overall for testing, configuration, etc. less time for advocacy with vendor less time for configuration & customizations | golive very close to winter curtailment project interruptions due to late fall holiday clusters typically busy time with patrons; may curtail testing availability if golive timings loosely couples, fewer timing options |
Coupling the NDE golive dates
| Simultaneous | Tightly Coupled | Loosely coupled |
|---|---|---|---|
| All 10 campuses golive with NDE on the same date | All 10 campuses golive within a short period (eg. one week) | All 10 campuses golive within a longer period (eg. a few weeks) |
Pros | Single, clean cutover; no mixed environments Simplest external communication (one message, one date) Consistent user experience across all institutions immediately Easier to manage shared services (docs, help, training) No need to maintain dual support (Primo VE + NDE) across sites Strong alignment with a “consortium as one system” model | Slightly reduces risk vs. simultaneous (minor sequencing) Maintains near-consistent user experience across institutions Allows small adjustments after first go-live(s) Still relatively simple communication (short rollout window) Less dependency on exact readiness of every single IZ on one day | Lowest risk concentration; issues isolated to early institutions Real opportunity to learn and fix issues between go-lives Reduced pressure on testing perfection before first launch More flexible scheduling for institutions with different readiness levels Central team workload distributed over time Easier rollback for individual institutions |
Cons | Highest risk concentration; failures affect all institutions No opportunity to learn from early adopters Requires all IZs to be equally ready (dependent on site needing the longest timeline) Peak load on central and local teams at the same time Testing must be near-perfect; little margin for error | Still high coordination overhead across all institutions Limited learning window; issues may still propagate Central team workload remains very high in a short period Some temporary inconsistency between early and late sites Requires most institutions to be ready at nearly the same time | Inconsistent user experience across the consortium during rollout More complex communication (multiple go-live dates/messages) Requires maintaining support for both Primo VE and NDE simultaneously Training and documentation may need to be repeated or versioned Longer overall rollout timeline Potential for configuration drift between early and late adopters if not controlled |
Scoping the project effort
Regardless of scoping effort, the following aspects are not part of a discovery migration and will be excluded from this project:
Exclude: Alma configuration changes
Exclude: metadata cleanup
Exclude: collection activation projects
Exclude: CDI troubleshooting unrelated to discovery
Exclude: Alma fulfillment redesign
| Minimum effort | Highest needs met | All needs met | Best product possible |
|---|---|---|---|---|
Description | Delay effort until late in the timeline Take whatever NDE version is available at time of golive Minimal configuration work beyond what is required to function | Explicitly define UC’s needs with clear prioritization & impact Address high impact needs but not needs with medium or low impact/priority | Explicitly define UC’s needs with clear prioritization & impact Address all high and medium impact/priority needs Address most/all low impact/priority needs | Explicitly define UC’s needs with clear prioritization & impact Explicitly define UC’s wants / “nice to haves” with clear prioritization & impact Address all needs Address as many wants / “nice to haves” as possible |
Pros | lowest upfront effort minimal customization | Balance of effort vs outcome Moderate configuration effort focus on high impact areas moderate/low advocacy effort | potential balance of effort vs outcome more stable & usable at launch | most usable and stable at launch no or little post launch efforts |
Cons | risk of instability risk of unmet needs | known inconsistencies issues deferred post-launch requires strict prioritization discipline | higher configuration effort higher testing effort higher advocacy effort | highest configuration effort highest testing effort highest advocacy effort |
Dependencies
These decisions are not isolated. Key dependencies include:
NDE product maturity at different points in 2027
Availability of Ex Libris updates and fixes
Institutional capacity for:
testing
configuration
coordination
Decisions on:
analytics model (independent vs centralized)
customization policy (JS/CSS)
Ability to enforce:
configuration freeze
testing deadlines
Cross-institution alignment on:
what constitutes “minimum needs”
Questions to consider
Timing
What are hard external drivers for Summer vs Winter (contracts, staffing cycles, academic calendar impacts)?
How much risk at go-live is acceptable?
Do institutions have sufficient staff availability during summer/winter for testing and launch support?
Scope
Can we agree collectively on needs and impacts of UC?
Is the consortium willing to enforce limits on scope expansion during testing?
How much inconsistency across institutions is acceptable at go-live?
References
Coordinated Ten Campus + CDL Migration to Primo Next Discovery Experience (NDE)
https://knowledge.exlibrisgroup.com/Primo/Product_Documentation/020Primo_VE/Primo_VE_(English)/Go_NDE - links to documentation about the NDE and transition steps
https://knowledge.exlibrisgroup.com/Primo/Product_Materials/001_Next_Discovery_Experience_(NDE)/Next_Discovery_Experience_User_Interface - Basic overview of the NDE and timelines
https://knowledge.exlibrisgroup.com/Primo/Product_Documentation/020Primo_VE/Primo_VE_(English)/Go_NDE/Go_NDE_-_Steps_to_Transition_to_NDE_UI#.E2.9C.85_Step_5:_Go_Live - step-by-step instructions to transition to the NDE
Action Log
Action/Point Person | Expected Completion Date | Notes | Status |
|---|---|---|---|
|
|
|
|
|
|
|
|