The University of California and the City University of New York offer two of the largest multi-campus human capital management consolidations in American higher education. CUNYfirst began its rollout in 2010 on an Oracle PeopleSoft base, eventually replacing separate payroll, benefits, HR, and timekeeping systems across 25 colleges. UCPath used the same platform approach on a different scale: ten campuses, five medical centers, and a wave-by-wave payroll cutover that took years, not a summer. At both systems, the software choice was less consequential than the administrative rulebook beneath it.
The promise was the same: one employee record, one payroll cycle, one benefits eligibility file, one audit trail. The California State University system formalised that idea in its Common Human Resources System, known as CHRS, which is moving 23 campuses toward shared HR and payroll processing. Projects in this category rarely fail because a platform lacks a feature. They stall when a campus-specific leave rule, a union side letter, or a nine-month faculty appointment has to be expressed in software that assumes a 12-month employee.
Why one payroll calendar is harder than one platform
University payroll differs from private-sector payroll because a substantial share of academic staff do not receive a uniform monthly salary. Tenure-track faculty may be paid over nine or twelve months, adjunct appointments renew at variable workload percentages, and graduate student appointments include fee remission, stipend timing, and treaty-based tax logic. A consolidation project has to decide whether those rules remain in departments or move into the central system.
That decision is visible in UCPath's design. The system centralised payroll and benefits administration while leaving certain timekeeping and academic-appointment details at the campus level. The boundary is never obvious. Put too much logic at the centre and campuses lose flexibility; put too little and the central office merely operates an expensive copy of the old local systems.
What actually changes for employees
Self-service portals are the visible part. A faculty member who once submitted a travel reimbursement on paper now opens a portal, attaches a receipt, and waits for workflow approval. The useful change is not the interface; it is that the approval path, the fund string, the payroll deposit, and the employee reimbursement record sit in one transaction with an audit log.
Digital onboarding follows the same logic. A new hire's offer letter, tax withholding, employment eligibility check, benefits election, parking permit, and campus network account can be sequenced into one workflow rather than seven separate email threads. At a multi-campus institution, a shared services team can process hires regardless of which campus is posting.
For administrators, the trade-off is that a central workflow produces more standard data and less local discretion. A departmental manager who used to approve a one-time payment with a note now faces a system that says the employee is not eligible under the configured rule. Whether that is a bug or a governance decision is the question consolidation forces people to answer.
Photo by engin akyurt on Unsplash
The main platforms and how they differ in practice
The vendor conversation in higher education generally lines up around three systems: Oracle PeopleSoft, Workday, and SAP SuccessFactors. Each has enough university customers to have accumulated known integrations with student systems, research administration, and legacy finance ledgers.
| Platform | Typical footprint | Relative strength in higher ed | Common friction point |
|---|---|---|---|
| Oracle PeopleSoft | Existing HR, payroll, benefits; often already running finance or student records | Deep configuration for multi-appointment, union-heavy payrolls; long installed base | Aging customisations that no current staff fully understand |
| Workday | Cloud HCM, payroll, and sometimes finance and student modules | Consumer-style self-service, frequent releases, object-based data model | Migration from PeopleSoft-style custom rules requires rethinking local practices |
| SAP SuccessFactors | Talent, learning, core HR; often connected to separate payroll through SAP or a third party | Workforce analytics and learning management | Payroll integration complexity in multi-employer, multi-state academic settings |
At the campus level, practical differences show up during payroll parallel testing. A platform that handles 26 biweekly pay periods may still fail an odd academic calendar if a fall term's first pay date lands before the system's effective-dated hire row is open. That is the kind of detail the vendor demonstration does not mention.
Workday's higher education materials emphasise rapid configuration. Oracle's higher education practice emphasises the installed base of PeopleSoft customers moving toward hybrid cloud. Both statements are true enough as marketing, but neither substitutes for a migration plan.
Implementation sequences that hold up
Systemwide HCM projects succeed when they sequence by calendar rather than by campus prestige. The University of California's UCPath ran campus cutovers in planned waves so the central service centre could absorb payroll questions from one group of campuses before the next went live. That sequencing matters because payroll go-live is not a rehearsal you can pause.
Governance documents from these projects show a recurring pattern: a design authority that includes HR, payroll, benefits, internal audit, and a representative from academic affairs. The academic affairs seat matters because faculty rank, tenure status, sabbatical pay, and teaching load interact with payroll in ways IT alone cannot specify.
Testing is where methodology decides the outcome. Parallel payroll runs compare the legacy system and the new HCM for every employee category and every pay cycle, including adjuncts, graduate researchers, partial-year staff, and terminated employees with outstanding leave payouts. Projects that skip a pay cycle to stay on schedule usually find the missing error in the first live payroll instead.
The cloud does not remove the collective bargaining agreement
One assumption of cloud HCM consolidation is that standardising data removes exception handling. In practice, exceptions are written into contracts. A CSU chancellor's office payroll rule about extra pay can be overridden by a campus-specific union side letter. A University of California policy on summer salary can differ by discipline, by funding source, and by who signed the grant. The software has to model those exceptions as configuration, not as afterthoughts.
That explains why multi-campus projects often run long. The delay is not because the cloud platform is hard to install; it is because each bargaining unit has to review how leave balances, holiday premiums, shift differentials, and the off-cycle payments that follow late appointment paperwork are represented in the system. Mapping union contracts to HCM configuration is an underappreciated academic specialty.
Photo by Billy Huynh on Unsplash
What system consolidation means for hiring and onboarding
At a consolidated institution, a job requisition in the HCM can carry the position number, salary grade, benefit group, and funding source from approval to offer letter. The offer letter template can then pull those fields without a human retyping them. For applicants, the first visible sign is often a self-service portal that asks for documents once, after which the system routes the hire to payroll, benefits, IT access, and a campus network account.
Higher education still runs on several hiring calendars that a generic applicant tracking system does not understand. A tenure-track search may take nine months; a grant-funded postdoc hire may need to start in three weeks; an adjunct hire may close and reopen each term. A consolidated HCM has to handle all three without forcing them into the same recruitment workflow. The systems that do this well treat recruitment as a lifecycle with stage gates, not a linear checklist.
A question missing from the board deck
The value case for cloud HCM in higher education usually starts with cost savings and ends with compliance. The deeper question is who gets to author the rules the system enforces. A shared platform can make legitimate variation visible, or it can hard-code one campus's interpretation of a policy and export it to the rest. The project's methods section should say which of those two things the design review is actually doing.
The press release rarely answers that. By the time the system goes live, the payroll calendars, bargaining unit mappings, and onboarding workflows are fixed enough to be hard to change. The question worth asking at the first steering committee meeting is whether the HCM platform will serve the faculty appointment, or whether the faculty appointment will be reshaped to fit the platform. Most plans do not decide; they simply discover the answer after the first fall payroll.