PeopleSoft Campus Solutions to Salesforce Education Data Architecture Migration

How we'd take this from discovery to a production-safe cutover — the phases, the canonical mapping, and the edge cases that bite.

This implementation pathway guides the technical migration of student and applicant records from Oracle PeopleSoft Campus Solutions to Salesforce Education Data Architecture (EDA), maintaining referential integrity across identifiers while preserving academic history, enrollment status, and affiliation data essential for institutional operations.

Implementation Phases

1. Source System Assessment & Discovery — Extract PeopleSoft metadata: table structures (STDNT_CAR_DEGR, STDNT_ACAD_PROG, APPLICANT, PERSONAL_DATA, ACAD_PLAN, ENROLLMENT), key relationships, and data volume counts per entity. Validate record counts against source system reports to establish baseline.
2. Target Schema Configuration in EDA — Configure EDA Account Model (Administrative or Household naming), enable Affiliation Settings for institutional program types, configure Academic Terms in EDA System Tools, and define Program Plans that mirror PeopleSoft academic plan types.
4. Mapping Design & Identifier Strategy
5. Extract-Transform-Load (ETL) Build
6. Data Validation & Reconciliation
7. User Acceptance Testing
8. Parallel Run & Delta Sync
9. Production Cutover

Mapping Design & Identifier Strategy

Establish the primary key mapping between EMPLID (PeopleSoft) and ContactId (EDA). Create a lookup cross-reference table that persists both identifiers throughout migration phases. Configure External ID fields on EDA objects to enable upsert operations rather than insert, preventing duplicate record creation during iterative loads.

Extract-Transform-Load (ETL) Build

Configure ETL jobs using Salesforce Data Loader, MuleSoft, or equivalent tool. Sequence loads by dependency: (1) Contact base records from PERSONAL_DATA, (2) Account records for institutional affiliations, (3) Affiliation records linking Contacts to Accounts via STDNT_CAR_DEGR, (4) Academic Program Affiliations from STDNT_ACAD_PROG, (5) Course Connections from ENROLLMENT, and (6) Applicant records from APPLICANT into Application objects. Implement field-level transformations for date formats, address normalization, and multi-value handling.

Data Validation & Reconciliation

Execute record-count reconciliation at each entity level: total Contacts vs. total PERSONAL_DATA rows, affiliation counts vs. STDNT_CAR_DEGR distinct EMPLIDs, program plan counts vs. ACAD_PLAN. Perform field-sampling audits: compare random 50-record samples for name accuracy, term assignments, enrollment status codes.

User Acceptance Testing

Have institutional users validate record accuracy in EDA sandbox. Confirm academic program affiliations display correctly, enrollment terms align with institutional calendar, and applicant pipeline stages reflect PeopleSoft admission statuses.

Parallel Run & Delta Sync

During parallel run, capture net-new and changed records in PeopleSoft daily. Re-apply delta loads to EDA until delta volume stabilizes below agreed threshold (DELTA_THRESHOLD configurable, typically <50 records/day).

Field Mapping

Edge Cases

• Name Changes Mid-Academic Career — PeopleSoft may retain historical names; EDA Contact.Name represents current state. Preserve prior names in Contact.NamingExemption__c or a custom Historical Name object to avoid enrollment record orphaning.
• Multi-Campus or Multi-Degree Students — Students with multiple ACAD_CAREER values (e.g., Undergraduate and Graduate) generate multiple Affiliation records; ensure affiliation primary-flag logic prevents duplicate "primary" assignments.
• Term Code Format Mismatch — PeopleSoft term codes (STRM) may be 4-digit (YYYY+T) or 6-digit; EDA Terms use distinct Term ID. Pre-validate all active term codes exist in EDA before enrollment loads.
• Program and Plan Records Missing in EDA — If STDNT_ACAD_PROG.PROGRAM value has no corresponding EDA Program record, the affiliation load fails. Seed Program/Plan objects before any affiliation loads.
• Duplicate EMPLID Scenarios — Rarely, PeopleSoft may have duplicate EMPLID assignments across test and production environments. Isolate test data in separate EDA sandbox; never load test EMPLIDs into production.
• Enrollment Status Transitions — PeopleSoft enrollment status codes (ENRL_STATUS: 'E', 'D', 'W') must map explicitly; unmapped codes defaulting to null break academic standing calculations.
• Address Overwrites — If ETL uses upsert on Contact address fields, later PeopleSoft address corrections overwrite EDA addresses. Determine write-authority policy: EDA-only, PeopleSoft-source, or merge logic.

Cutover

Execute cutover during a scheduled maintenance window with no active PeopleSoft transactions. Perform a final delta extraction immediately prior to EDA go-live. Validate that delta records apply without errors; suspend new PeopleSoft-to-EDA integrations until cutover confirmation. Prepare a full rollback package: export EDA records to CSV via Data Loader, preserving ContactId and Student_ID__c mapping. If rollback is required, re-import the CSV to restore pre-migration state. Post-cutover, run a 3-day reconciliation comparing PeopleSoft record counts against EDA totals across all entities, escalating discrepancies within 24 hours. Designate a migration hold period (7–14 days) where all corrections route through the ETL pipeline, not direct EDA edits, to maintain synchronization integrity.