Data Migration Into Education Cloud: A Checklist From Our Cutovers

Migrating data into Education Cloud goes well when you inventory the source, pick one identity key, map to standard objects, load in dependency order, run delta loads until cutover, purge test records, and get the registrar's signature on validation reports. ElevateActual runs this checklist on every cutover; the legacy org stays read-only until the first cycle closes.

Why Start With a Checklist?

If this is your first migration into Salesforce Education Cloud, the hard part is not the loading tool. It is the long list of small decisions nobody writes down, each harmless until go-live. A checklist makes them visible and gives each an owner. One habit is worth adopting on day one: a migration is never done done. Every load gets validated, every validation finds something, and the fix gets reloaded. The steps below are in the order we run them on admissions and enrollment projects, and each names the mistake it prevents.

Step 1: What Is Actually in the Source Org?

Inventory the source before any mapping. In an EDA, TargetX, or Enrollment Rx org, records are spread across managed package objects, custom objects added later, and custom fields on standard objects. Pull the full object and field list with record counts and last-modified dates; a field empty for three years needs no destination. Four categories hide in plain sight: files on records, email templates whose merge fields reference old objects, images in those templates hosted inside the old tool, and reports and list views that encode rules written nowhere else.

The mistake this prevents: discovering a package object or a hosted image two weeks after cutover, when the source is read-only and the person who knew has moved on.

Step 2: What Is the Identity Key?

Decide, in writing, which value identifies a person across systems. Education Cloud models learners as Person Accounts, so this decision shapes every later load.

Personal Versus Institutional Emails

An applicant inquires with a personal email. On admission the institution issues an institutional email, and the SIS reports enrollments under it. If email is the only key, the migration creates two Person Accounts for one human: one with the application history, the other with the enrollment. Our recommendation: student ID is the key once the SIS has issued one, email before that. Carry both on every record, and keep every known email.

Matching Rules That Include Contact Point Email

Education Cloud stores additional emails on ContactPointEmail records tied to the Person Account. A duplicate rule that compares only the primary email misses the match when the institutional address is on the contact point. Build the matching rule to check ContactPointEmail as well, test it with a known pair, and switch it on before the first person load.

The mistake this prevents: thousands of duplicate Person Accounts merged by hand after go-live, each merge losing history.

Step 3: How Does the Source Map to Standard Objects?

Map every source object to a standard object before considering a custom one. Programs map to LearningProgram, terms to AcademicTerm, applications to IndividualApplication with its timelines and decisions, sections to CourseOffering, and section enrollment to CourseOfferingParticipant. Salesforce publishes a Data Migration Kit that maps EDA, Admissions Connect, and Student Success Hub data to these objects; start from it even when your source differs. Write the map as a table, one row per source field, with the transformation and who agreed to it. The same map later drives an applicant portal built on standard objects.

The mistake this prevents: recreating the old model as custom objects, which carries every old limitation forward and blocks the standard portals, consoles, and agents.

Step 4: What Order Do the Records Load In?

Load in dependency order:

1. Accounts: Person Accounts for learners, business accounts for high schools, employers, and feeder institutions.
2. Learning Programs and Academic Terms: the reference data that applications and enrollments point to.
3. Applications and enrollments: IndividualApplication, then AcademicTermEnrollment and CourseOfferingParticipant.
4. Activities: tasks, events, emails, and notes.

Validate each layer before the next starts. If step two is off by one program, every application in step three points to the wrong program.

The mistake this prevents: orphaned children that fail because their parent does not exist yet, and a scramble to reload under time pressure.

Step 5: Why Does Every Record Need an External ID?

Put the source record ID in an external ID field on every target record, every object, no exceptions. The second load is where it pays off: with an external ID you upsert, and the loader updates the record it created last time instead of creating a twin. Without it, every reload is a delete and recreate, and every delete breaks the lookups loaded after it.

The mistake this prevents: a reload that doubles the record count, and a validation that cannot trace a record to its origin.

Step 6: How Do Delta Loads Get You to Cutover Without a Freeze?

Admissions offices do not stop working for a migration. Run a full load several weeks before cutover, validate it, then run delta loads on a schedule: every record created or modified since the last run, upserted by external ID. The deltas shrink as the mapping stabilizes, and on cutover day the last one runs and validates in a few hours. The mechanics are in moving from EDA to Education Cloud without a data freeze.

The mistake this prevents: a multi-day freeze during recruiting season, or a cutover that silently drops the last week of applications.

Step 7: What Happens to the Test Records?

During build and testing, staff create applicants named "Test Applicant" and "Zzz Delete Me", testers use their own emails, and developers create records to check a flow. By go-live there can be hundreds, sitting in the same list views, reports, and dashboards as real applicants. Tag every test record at creation with a checkbox or a naming convention, and purge the list in one pass between signed acceptance and the final delta load. Re-run the validation counts afterward, and check the recycle bin, because deleted test Person Accounts leave tasks and emails behind.

The mistake this prevents: fake people in real views, and a funnel dashboard off by the number of testers who clicked through the application.

Step 8: What Should Not Move?

Not every record earns a place. Decide with the registrar and the records officer which stay behind:

• Applications older than the retention policy, which are archived, not migrated.
• Inquiries past a reasonable age that never became applicants.
• Bounced, dead, or unsubscribed email records.
• Campaign members from campaigns that ended years ago.
• Email bodies and attachments past a cutoff date.
• Workflow and automation metadata, which is redesigned in Flow rather than copied.

Record the cutoffs in the mapping table. For a health-sciences university with graduate and doctoral programs, historical applicant records moved so counselors kept their history, while older material stayed in an archive.

The mistake this prevents: paying to store, secure, and clean a decade of data nobody will open.

Step 9: What Does the Registrar Sign?

Validation is a document, not a feeling. After each full load and the final delta, produce the same reports from both orgs and compare them:

• Record counts per object, with the difference from excluded records explained.
• Applications by term, program, and status, as a cross-tab.
• Enrollments by term and course offering.
• A sample of named individuals traced from inquiry to most recent activity.
• Duplicate Person Account count before and after the matching rule.

The registrar signs the comparison. The signature turns validation into an institutional decision and gates the launch that follows, described in UAT and go-live for a university storefront.

The mistake this prevents: an argument in month two about whether the numbers are right, with no agreed baseline.

Step 10: When Is the Legacy Org Turned Off?

Do not turn the old system off at cutover. Reduce it to a read-only archive: remove edit rights, keep a few read licenses, and export a complete backup, including files and email, to storage the institution controls. Turn it off after one full cycle has closed in the new org: an admissions cycle for a recruiting migration, a term for an enrollment migration. If the vendor contract ends sooner, the export is the archive, so test that it opens before the contract lapses.

The mistake this prevents: losing the only copy of a record at contract end, or keeping two editable systems long enough to diverge.

The Checklist in One Table

Questions We Hear