Elsevier Pure CRIS: Implementation and Data-Migration Checklist for Research Offices

Elsevier Pure is a widely used current research information system (CRIS), and by the time a research office signs the contract, the harder work is usually still ahead: mapping legacy data, sequencing integrations, and getting faculty, the library, and IT to actually adopt a new system of record. This guide is written for the research office, not the vendor sales cycle — it assumes Pure has already been selected (see our Symplectic Elements vs. Pure vs. Converis procurement scorecard if you’re still deciding) and walks through what an implementation and data-migration project actually involves.

Elsevier does not publish a single public step-by-step migration manual with fixed timelines or pricing, and durations vary considerably by institution size, data quality, and how many legacy systems feed into the project — so this guide describes the phases and decisions qualitatively rather than inventing week counts or costs that would not hold up institution to institution. Where a figure is stated (for example, the number of institutions using Pure), it is sourced directly from Elsevier’s own product documentation, cited below.

What Pure implementation actually involves

Pure is Elsevier’s research information management system, used by over 500 universities and research institutes across more than 50 countries, according to Elsevier’s own product page. It centralizes publications, funding, people, projects, and impact data into a single record, and synchronizes with external sources such as Scopus, ORCID, national CRIS registers, and institutional HR and finance systems. Implementing it is not a single software install — it is a data-integration and organizational-change project that typically runs in parallel workstreams: technical (data mapping, integrations, deduplication rules), administrative (workflow and policy decisions), and human (training, communication, and researcher buy-in).

Data mapping: what actually moves from legacy systems

Before any records are loaded into Pure, the research office needs an inventory of every system currently holding data that Pure is meant to replace or absorb, and a decision for each field about whether it maps cleanly, needs transformation, or should be retired rather than migrated. Typical sources include:

• Legacy CRIS or repository data — publication records, if migrating from a prior CRIS (such as Converis or an earlier Symplectic Elements deployment) or an institutional repository. Field-level mapping matters here: a legacy system’s “output type” taxonomy rarely maps one-to-one onto Pure’s content model, and someone needs to decide the crosswalk rather than let it default.
• HR/personnel data — the person records (appointments, departments, start/end dates) that populate person records in Pure and drive who is currently “active” for reporting purposes. This is usually the single most disruptive integration to get wrong, because it determines who shows up correctly in dashboards and REF/ERA-style submissions.
• Publications and outputs — historical publication lists, often reconciled against Scopus and other bibliographic sources during import rather than hand-entered, to reduce duplicate and mismatched author records.
• Awards and funding data — grant and award records that may currently live in a separate grants management system, which is a distinct category of software from a CRIS even though the two need to exchange data.
• Activities and profile content — narrative CV content, editorial/committee activities, and other researcher-entered material that doesn’t have a clean system-of-record source and often needs a manual or self-service re-entry step rather than automated migration.

A practical checklist item here: decide, field by field, whether the migration goal is completeness (bring everything over) or currency (bring over what’s still accurate and let researchers self-correct the rest during a verification period). Institutions that try to achieve perfect historical completeness before go-live tend to see the project timeline expand the most, because legacy data quality is rarely as clean as it looks in the source system.

Integration points to plan for

Per Elsevier’s own data-sources documentation, Pure supports a defined set of inbound and outbound integrations, and a research office should scope which of these it actually needs rather than enabling everything by default:

• ORCID — Pure participates in ORCID’s Certified Service Provider program; researcher profiles in Pure can be linked to an ORCID iD and updates can flow in both directions, so researchers see their Pure-verified outputs reflected on their public ORCID record rather than re-entering them. Decide early whether ORCID connection will be mandatory, opt-in, or encouraged-but-not-enforced for faculty — this is a policy decision, not just a technical toggle.
• Scopus — a native, deep integration used for both authoritative publication metadata and author disambiguation via Scopus Author ID matching. Many institutions use the Scopus feed as the primary source for publication import during migration rather than manual entry.
• Other metadata sources — Elsevier lists integrations with CrossRef, Embase, IEEE Xplore, Web of Science, and Mendeley among others, useful where an institution’s disciplinary mix means Scopus alone doesn’t capture the full output record (common in fields with heavy conference-proceedings or humanities monograph output).
• Funder and repository systems — inbound integration with Elsevier’s own Funding Institutional product, and connections to repository platforms including DSpace, Digital Commons, and EPrints for outbound deposit workflows.
• HR/CRM feeds and authentication — Pure connects to institutional Active Directory, Shibboleth, or WAYF for single sign-on, and typically needs a scheduled or real-time feed from the HR/payroll system to keep person records current — this integration is usually the most institution-specific piece of the whole project, since every university’s HR system and org-hierarchy conventions differ.
• National and evaluation reporting — outbound integrations exist for research-assessment frameworks such as the UK’s REF, Australia’s ERA, and various national CRIS registers, relevant mainly to institutions in jurisdictions with a formal research-assessment exercise.

Stakeholders and change management

A Pure implementation touches more offices than the research office alone, and under-scoping stakeholder involvement is one of the more common causes of delay:

• Research office / research information management team — usually the project owner, responsible for data-mapping decisions, workflow design (what counts as a “verified” publication, who approves records for external reporting), and ongoing governance after go-live.
• Library — often holds bibliographic expertise and, where the institution runs an institutional repository, owns the deposit and open-access-compliance workflows that need to connect to Pure rather than run as a separate parallel process.
• IT / systems integration — owns the HR feed, single sign-on configuration, and any custom API work; needs to be resourced as a real project workstream, not an afterthought once the “content” side is designed.
• Faculty and researchers — the end users who will be asked to review imported records, correct mismatches, and (in many rollouts) participate in claiming/deduplication of author records. Researcher trust is easiest to lose in the first weeks after go-live if imported data looks visibly wrong — this is where communication planning pays off most directly.
• Institutional leadership — the audience for the dashboards and reporting Pure is often purchased to support (research strategy, REF/ERA-style assessment, grant-portfolio visibility). Leadership sponsorship matters for enforcing data-quality expectations across departments that might otherwise treat profile maintenance as optional.

Change management for a CRIS migration is less about training people to click through a new interface and more about resetting expectations for who is now responsible for keeping a shared record accurate — a genuine shift for institutions moving from a library-curated repository model to a researcher-self-service CRIS model, or vice versa.

Typical implementation sequencing

Elsevier doesn’t publish a fixed public timeline, and actual duration depends heavily on data volume, number of source systems, and institutional decision-making speed, so treat the following as a description of the usual sequence of work rather than a schedule:

1. Discovery and scoping — inventory legacy systems, agree which data domains (people, publications, awards, activities) are in scope for migration versus fresh entry, and confirm which integrations (ORCID, Scopus, HR, repository) are needed at launch versus a later phase.
2. Data mapping and cleansing — build the field-level crosswalk from legacy systems into Pure’s content model, and clean the worst data-quality issues (duplicate person records, inconsistent department names) before import rather than migrating them as-is.
3. Configuration — set up organizational hierarchy, workflow rules (who validates a record before it’s “reportable”), user roles and permissions, and integration credentials.
4. Test migration and validation — load a representative subset of data, check it against source systems, and have research-office staff (not just IT) sign off on accuracy before a full load.
5. Full data load and integration go-live — the full historical migration plus activation of ORCID, Scopus, HR, and any other configured integrations.
6. Researcher verification period — a window, common across CRIS rollouts generally, where faculty are asked to review and correct their own imported profile before the system is treated as authoritative for reporting.
7. Go-live for reporting/compliance use — the point at which the institution formally relies on Pure data for dashboards, funder reporting, or assessment submissions, and legacy systems are retired or archived.

Because Elsevier positions Support Services and consultation as part of an implementation engagement rather than a self-serve process, institutions evaluating the project should request a scoped timeline directly from Elsevier or their implementation partner for their own data volume and integration list, rather than relying on a generic industry figure.

Practical checklist

• Inventory every legacy system holding data Pure will absorb (CRIS/repository, HR, grants system, self-maintained CVs).
• Build a field-level data-mapping document before migration begins, with an explicit decision (migrate, transform, retire) for every field.
• Decide ORCID connection policy (mandatory / opt-in / encouraged) before go-live, not after.
• Confirm which bibliographic sources (Scopus and others) will drive publication import, given your institution’s disciplinary mix.
• Scope the HR feed early — it is typically the most institution-specific integration and the one most likely to affect the timeline.
• Name owners in the research office, library, and IT for each workstream, not just a single project manager.
• Plan a researcher verification period before treating Pure as the system of record for external reporting.
• Confirm what happens to legacy systems (retirement, archival, read-only access) after go-live.

Frequently asked questions

Does Pure replace a grants management system?

No. Pure is a research information system focused on publications, people, projects, and impact reporting; it is a distinct category of software from a grants management system, which handles proposal submission, budgeting, and award administration, even though the two commonly need to exchange award data.

Do we need Scopus access to use Pure?

Scopus is one of several bibliographic sources Pure integrates with, and it is the source most institutions use as their primary publication feed, but Elsevier’s documentation lists other metadata sources (CrossRef, Embase, IEEE Xplore, Web of Science, Mendeley) as well — the right mix depends on your institution’s disciplinary coverage.

How is Pure different from Symplectic Elements or Converis?

All three are commercial CRIS platforms serving a similar function; they differ in data model implementation, interface, and integration specifics. See our Pure vs. Symplectic Elements vs. Converis comparison for a feature-by-feature procurement view, and our four-way CRIS vendor comparison for how open-source options fit alongside the commercial ones.

What data model does Pure use?

Pure implements the CERIF (Common European Research Information Format) data model, maintained by euroCRIS, which is why it can interoperate with other CERIF-compliant systems and national research registers.

Can we migrate away from Pure later if we change vendors?

Data portability and export format should be a specific question during procurement, since it affects negotiating leverage and exit cost — this is covered in more detail in our CRIS procurement scorecard.

For the underlying concepts referenced throughout this guide, see our entries on CRIS, CRIS interoperability, research output (CRIS), and person record (CRIS), or the Persistent Identifiers & Research Information Systems pillar page for the full cluster.