A move from Salesforce EDA to Education Cloud does not need a weeks-long data freeze. Stand up Education Cloud, map each EDA object to a standard Education Cloud object, run one full load and then delta loads while staff keep working in EDA, and cut over on one weekend. ElevateActual settles the username and retirement decisions first.
Where Most EDA Institutions Start
The typical institution we meet has run the Education Data Architecture (EDA) for five to ten years. Each Contact carries an Administrative or Household account. Flows, Apex handlers registered in EDA's Table-Driven Trigger Management, and a few integrations keep it running. The data is valuable. The structure is the problem, because Salesforce's newer student success, admissions, and academic operations features are built on the Education Cloud objects, not on the EDA package objects.
This page belongs to our Salesforce for higher education guide; the data migration checklist covers the field-level work that follows.
What Is the Difference Between EDA and Education Cloud?
EDA is a free managed package. It adds custom objects in the hed namespace on top of standard Account and Contact, and it ships a trigger framework (TDTM) that runs most of its logic. A person is a Contact under an Administrative account or a shared Household account.
Education Cloud (Agentforce Education) is a paid Salesforce product. A person is a Person Account, one record that behaves as both Account and Contact. Programs, courses, terms, and enrollments are standard objects in the Learning model: LearningProgram, LearningCourse, CourseOffering, CourseOfferingParticipant, AcademicTerm, and LearnerProgram. Admissions runs on IndividualApplication, and advising runs on Case, Care Plan, and Record Alert. Salesforce Help states that TDTM is not compatible with Education Cloud, so automation moves to Flow or to Apex triggers written outside the framework.
As of October 2026, Salesforce has not announced a retirement of EDA. Institutions move because the new features land on Education Cloud, not because EDA is going away.
What Does the Data Migration Kit Do, and What Does It Not Do?
Salesforce publishes a Data Migration Kit for EDA, Admissions Connect, and Student Success Hub: unmanaged packages that install Data Processing Engine definitions. Each definition reads a source object, transforms the records, and writes them to the matching Education Cloud object. Salesforce supports migration inside the same org, with Education Cloud turned on next to EDA, and migration to a new org through shadow objects and Data Loader.
The kit moves data. It converts Account and Contact pairs to Person Accounts and maps the EDA academic objects to the Learning model. Users, Tasks, Events, and alerts move through separate Data Loader steps on the same Help pages.
The kit does not move anything else. Flows, Apex, validation rules, page layouts, permission sets, reports, dashboards, Experience Cloud sites, and integrations are rebuilt by hand against the new objects. Salesforce Help is explicit that Contact automations must be recreated on Account with an IsPersonAccount check, that Experience Cloud users are deactivated and recreated, and that TDTM trigger handlers are deactivated before the run. Also, the kit copies data rather than moving it, so storage grows during the migration.
How Do EDA Objects Map to Education Cloud Objects?
The table follows the source and target object lists on the kit's Help pages. Salesforce's field-mapping spreadsheet, linked from those pages, is the authority for your release.
| EDA object | Education Cloud object | Note |
|---|---|---|
| Contact plus Administrative or Household Account | Person Account (Account with IsPersonAccount), ContactProfile | Only one-contact accounts convert. Household members each become a Person Account; the household becomes a group. |
| Academic Program (Account record type) | LearningProgram | Programs stop being accounts. |
Affiliation (hed__Affiliation__c) | AccountContactRelation, PartyRoleRelation | Requires the setting that relates a contact to multiple accounts. |
Relationship (hed__Relationship__c) | ContactContactRelation | Reciprocal rows collapse to one record with a role. |
Term (hed__Term__c) | AcademicTerm, with AcademicYear and AcademicSession | Parent terms become years; child terms become sessions. |
Course (hed__Course__c) | Learning and LearningCourse | Two records per course in the Learning model. |
| Course Offering and Course Offering Schedule | CourseOffering, CourseOfferingSchedule | Near one-to-one. |
Course Connection (hed__Course_Enrollment__c) | CourseOfferingParticipant | Student and faculty record types both map; faculty rows carry a role. |
Term Grade (hed__Term_Grade__c) | CourseOfferingParticipantResult | Grades become results on the participant. |
Program Enrollment (hed__Program_Enrollment__c) | LearnerProgram, AcademicTermEnrollment | One EDA record often becomes a program record plus one term enrollment per term. |
| Program Plan and Plan Requirement | LearningProgramPlan, LearningProgramPlanRequirement | Feeds Intelligent Degree Planning later. |
Application (hed__Application__c) | IndividualApplication, ApplicationTimeline, ProgramTermApplnTimeline | Timelines are new records you create per program and term before the run. |
| Test and Test Score | Examination, PersonExamination | Composite and section scores both supported. |
| Education History | PersonEducation | Verify against the kit's mapping sheet for your release. |
Address (hed__Address__c), custom objects, custom fields | Not in the kit's object list | Plan these yourself: standard address fields, or custom objects re-created with a written reason. |
Which Migration Approach Should You Choose?
The choice among three approaches is about how long staff can stop entering data, and whether the institution can tolerate two systems of record at once.
| Approach | How it works | Concerns | Our recommendation |
|---|---|---|---|
| Big-bang freeze | Stop data entry in EDA, run the kit and the manual loads once, validate, open Education Cloud. | The freeze runs two to four weeks for a mid-size org once validation and rework are counted. Admissions and advising cannot pause that long mid-cycle. | Only for small orgs, or for units that can pick a dead month. |
| Delta loads | One full load early, then incremental loads of records changed since the last run. Staff work in EDA until a one-weekend cutover. | Needs a legacy Id stored as an external ID on every target object, and a mapping that runs the same way every time. Deletes in EDA must be detected separately. | The default for admissions, advising, and continuing education units. |
| Parallel run | Both orgs live. Staff enter data in both, or a sync keeps them aligned. | Double entry fails within days. A two-way sync between a Contact model and a Person Account model is a project of its own. Usernames collide across orgs. | Avoid. If leadership asks for it, offer a read-only legacy org after cutover instead. |
What Does the Delta-Load Plan Look Like?
Stand Up the Target
Decide same org or new org first. Same org keeps the contract, the integrations, the users, and every piece of technical debt; the Help page tells you to run Salesforce Optimizer before you begin. New org gives a clean security model and clean flows, at the cost of re-creating users and integration endpoints. In our experience, units that share an org with other campus teams usually move to a new org, and single-unit orgs usually migrate in place. In the target, turn on Education Cloud and Person Accounts, create the supporting records the kit requires, and build the security model before any data arrives.
Initial Load
Run the kit's definitions in order against a full sandbox copy first, then against production. Store each EDA record's Salesforce Id in an external ID field on its target object. That field makes every later load an upsert, which is what lets staff keep working in EDA.
Delta Loads
Every week, and nightly in the last two weeks, extract the records whose SystemModstamp is later than the previous run and upsert them through an integration tool or Data Loader with the kit's field mapping. Capture deletes from the source with a deletion report or a soft-delete flag, because an upsert never removes a record. Validate each run with the same counts and spot checks, and publish the results to the registrar and the admissions director.
Cutover Weekend
Friday evening, EDA goes read-only for everyone except administrators. Run the last delta. Validate. Repoint the SIS integration and the forms. Create or reassign the Experience Cloud users. Monday morning, staff log in to Education Cloud. The freeze lasted a weekend, not a month.
How Do You Handle Usernames Across Two Orgs?
A Salesforce username must be unique across every Salesforce org, not only yours. If the EDA org stays up after cutover, even read-only, every staff member who needs the new org must log in with a different username than today's. Two patterns work. Rename the legacy usernames at cutover, for example by appending a suffix, so the production usernames move to the new org and single sign-on keeps working. Or issue temporary usernames in the new org and swap them when the legacy org closes. The first is cleaner; the second is what you get when the retirement date is left open. Decide before the first user is created, because renaming users later creates a second wave of support tickets.
When Does the Legacy Org Go Away?
Set a hard date and tie it to a contract: the EDA org's Salesforce term end, the renewal of an integration tool, or the end of a sandbox entitlement. State in the project charter that the legacy org becomes read-only on cutover weekend and is deactivated on that date, and that any report still needed from it is rebuilt in Education Cloud before then. Without the date, the legacy org lingers, and the new org never becomes the system of record in practice.
The One Trap: Contacts Tied to Portal Users Will Not Convert
Salesforce Help lists the conditions a Contact must meet to become a Person Account. The one that stops projects is that the contact cannot be associated with an active Experience Cloud user. Every applicant, student, or alumni portal login in EDA blocks its own conversion. The sequence is to deactivate those users, convert the contacts, create new users against the Person Accounts, and reassign ownership. Run the deactivation in the final delta window and have the new portal ready to issue logins on Monday. The other conditions (one contact per account, the same owner on both records, no parent account, no Reports To value) surface in the first sandbox run.
What to Decide Before Building
- Same org or new org. This decides the username problem, the integration work, and how much technical debt comes along.
- What a person is. Every Contact becomes a Person Account. Decide how Households are represented and whether employers, high schools, and feeder colleges stay business accounts.
- Which EDA objects are in scope. Custom objects, Address records, and unmapped fields each need a written decision: migrate by hand, replace with a standard field, or archive.
- How far back history goes. Many institutions keep the full enrollment history and cut application history to the last few cycles.
- The cutover weekend and the retirement date. Both on the calendar, both tied to a contract.
- Who validates. Named people in the registrar's office, admissions, and advising sign off on counts after every delta.
The Enrollment Rx migration page and the Admissions Connect and Student Success Hub page cover the same sequence with different source objects. Admissions design for the new org is on our admissions solution page, and the glossary keeps the names straight.
Questions We Hear
Do we have to leave EDA?
No. As of October 2026, Salesforce has not announced a retirement of EDA, and the package still works. Institutions move because the newer admissions, advising, degree planning, and Agentforce features are built on the Education Cloud objects and do not read EDA records. If your office uses EDA only as a contact database, the case for moving is weaker than for an admissions or advising team that wants the new tooling.
Can EDA and Education Cloud run in the same org?
Yes. Salesforce's same-org migration scenario depends on it: you turn on Education Cloud next to EDA, run the kit, and validate before anyone uses the new objects. Treat it as a transition state. TDTM trigger handlers must be deactivated before the run, which means EDA's own automation stops working in that org, so the overlap should be short and planned.
How long does the delta-load approach take?
For a single unit with few custom objects, the first full sandbox run usually lands within the first month, and cutover follows in the third to fifth month. The variables are custom objects the kit does not map, the flows and Apex to rebuild, and the integrations to repoint. Delta loads add little calendar time; most of the schedule is the rebuild.
What happens to our flows and Apex?
They are rebuilt. Salesforce Help directs you to recreate Contact automations on Account with an IsPersonAccount check, to retire TDTM handlers, and to move remaining Workflow Rules and Process Builder processes to Flow. We treat this as the moment to simplify: most EDA orgs carry automation nobody can explain, and a migration is the one time you can delete it without an argument.
What happens to Marketing Cloud?
Salesforce Help calls out three items. If the Person Account Id differs from the Contact or Lead Id that Marketing Cloud used as the subscriber key, migrate the subscriber keys. If you move to a new org, use the multi-org connector. Reimplement Marketing Cloud Connect for the new objects and triggers where needed. Plan this with the enrollment marketing team early.