Admissions Connect and Student Success Hub are Salesforce's own managed packages for admissions and advising. Salesforce publishes a Data Migration Kit that maps their records onto standard Education Cloud objects such as Individual Application, Care Plan, and Service Appointment. The kit moves data, not custom code or metadata, which is where ElevateActual spends most of the project.
What Do Admissions Connect and Student Success Hub Do?
Admissions Connect is a managed package that adds application review, applicant checklists, and an applicant experience on top of EDA, the free Education Data Architecture package. Student Success Hub is a managed package for advising: appointments, success plans, alerts, advising cases, and advisor assignments, again on top of EDA. Student Success Hub grew out of Salesforce Advisor Link, and its package namespace, sfal, still carries that lineage; institutions that licensed Advisor Link years ago usually run Student Success Hub today.
Both packages store their records in the institution's own Salesforce org. As of October 2026, Salesforce has not announced a retirement of either package or of EDA. What Salesforce has done is publish Education Cloud, a paid product with a standard data model for the same work, and a Data Migration Kit that transforms EDA, Admissions Connect, and Student Success Hub data into that model. The student success and admissions capabilities that replace the two packages are described on those solution pages, and the whole platform picture is on our Salesforce for higher education guide.
Why Do Teams Consider Moving?
- Education Cloud is where new features land. Advisor and director consoles, care plans, success teams, Einstein Advising Summary, pulse checks, Intelligent Degree Planning, and the Agentforce education agents all read from Education Cloud objects, not from the
sfalorrandapackage objects. - Three data layers in one org. EDA objects, Admissions Connect or Student Success Hub objects, and the institution's custom fields describe the same student. Every report and every flow has to know which layer holds the truth.
- Person Accounts. Education Cloud models a student as a Person Account. EDA's account-plus-contact pattern, with an administrative account per person, is what most reporting pain on these orgs traces back to.
- TDTM. EDA's Table-Driven Trigger Management framework is not compatible with Education Cloud, per Salesforce Help. Business logic built in TDTM handlers has to be rebuilt in Flow regardless of when the institution moves.
- One model for admissions, advising, and commerce. An institution that wants the admitted applicant, the advised student, and the continuing education learner to be one record needs the standard objects.
The pull is toward the standard layer underneath.
What Moves and What Stays?
The table below follows the object mapping in Salesforce's kit. The kit's Data Processing Engine definitions run in clusters, and each cluster is validated before the next runs.
| Source data | Where it goes in Education Cloud | Notes |
|---|---|---|
| EDA Contacts with administrative Accounts | Person Accounts (Account with IsPersonAccount), ContactProfile | Only account-contact pairs with one contact, one owner, and no active portal user convert. |
| EDA Affiliations and Relationships | AccountContactRelation, ContactContactRelation, PartyRoleRelation | Standard relationship objects replace the package junctions. |
| EDA Terms, Courses, Course Offerings, Course Connections | AcademicTerm, LearningCourse, CourseOffering, CourseOfferingParticipant | The same objects continuing education and commerce use. |
| EDA Program Plans and Program Enrollments | LearningProgramPlan, LearnerProgram | Plan requirements map to LearningProgramPlanRequirement. |
| EDA Tests and Test Scores | Examination, PersonExamination | Standard objects. |
| Admissions Connect Applications and Timelines | IndividualApplication, ApplicationTimeline | Requires an application record type configured before the run. |
| Admissions Connect Application Reviews | ApplicationReview | Reader scores and comments carry over. |
| Student Success Hub Alerts | RecordAlert | A record alert category per old alert record type must exist first. |
| Student Success Hub Success Plans and Templates | CarePlan, CarePlanTemplate | Care Plans must be turned on in Setup before the run. |
| Student Success Hub Appointments, Attendees, Topics, Locations | ServiceAppointment, AssignedResource, WorkTypeGroup, ServiceTerritory, ServiceResource | Appointment categories, engagement channel types, and service territories are set up first. |
| Advising cases and case participants | Case, CaseParticipant | Custom fields the kit expects on Case Participant and Care Plan are added before the run. |
| Custom code, flows, TDTM handlers, page layouts, reports, Experience Cloud sites | Not moved by the kit; rebuilt or retired | This is where the real project is. |
| Student record of truth | Stays in the SIS | Education Cloud holds the relationship; the SIS holds the transcript. |
Two mechanics matter. First, the kit copies data rather than moving it, so the org's storage reflects both the original and the migrated records until the package objects are cleared. Second, the kit supports migrating within the same org or into a new org; the new-org path adds Data Loader steps for users, tasks, events, and alerts. The same-org path is the common choice and the one our EDA to Education Cloud without a data freeze article walks through.
What Does the Salesforce Side Look Like?
On the admissions side, an applicant is a Person Account with IndividualApplication records per program and term, ApplicationTimeline for deadlines, ApplicationReview for readers, and ApplicationDecision for outcomes. The applicant works in an Experience Cloud portal with Action Plan items as next steps.
On the advising side, an advisor opens a console that shows the student's CarePlan with goals and tasks, open RecordAlert records, upcoming ServiceAppointment records, and the success team as case participants. Students book appointments and see their plan in the same Experience Cloud portal. Our student success on Education Cloud article shows how care plans, alerts, and success teams fit together after the move.
Automation is Flow and Platform Events. Alerts route to the right advisor by record-triggered flow; appointment reminders go out by scheduled flow; the TDTM handlers are gone. The SIS remains the system of record for enrollment, grades, and holds, feeding Education Cloud through supported integrations only.
How Do We Run the Migration?
- Discovery. Inventory of every package object in use, custom field, TDTM handler, flow, report, and Experience Cloud page. Salesforce Optimizer runs early. Marketing Cloud subscriber keys are checked, because a Person Account ID that differs from the old contact ID breaks the connector unless keys are migrated.
- Object mapping. We start from Salesforce's published kit mapping and record every deviation the institution needs, with a reason. Picklist values in source fields are added to target fields before any run, because the kit fails on missing values.
- Prerequisites. Education Cloud turned on, Person Accounts enabled, Group Membership and Care Plans enabled where Student Success Hub is in scope, record alert categories, appointment categories, engagement channel types, service territories, application record types, and the handful of custom fields the kit expects.
- Initial load and delta loads. The kit's unmanaged packages are installed in a full sandbox and the clusters run in sequence, each validated before the next. Production follows the same order while the package pages stay live. Delta runs pick up records changed since the last cluster run.
- Parallel period. Advisors and admissions staff work both models for one to two weeks. Caseload counts, open alerts, and application stage counts must reconcile.
- Identity and username planning. Students and applicants with portal logins are contacts with active Experience Cloud users, and such contacts will not convert to Person Accounts. The sequence is deactivate, convert, and create new users on the Person Accounts. When the old portal stays up during the parallel period, the new username pattern must not collide with the old one. This is the one trap on these moves, and it is scheduled before the first production run.
- Cutover. A dated switch outside registration and deadline weeks. Package pages become read-only, migration packages are uninstalled after validation, and the package objects are cleared on a planned date to recover storage.
- Hot test. Within a day, staff raise an alert, book an appointment, and submit and review a test application on production.
The validation queries and sign-off list live in our data migration into Education Cloud checklist; other platform guides are on the migrations hub.
When Should You Not Move?
- Nothing on the Education Cloud roadmap is pulling you. If the packages serve a stable advising office and nobody is asking for care plans, Agentforce, or a shared learner record, there is no deadline forcing the move. Salesforce has announced no retirement as of October 2026.
- Licensing is unsettled. Education Cloud is a paid product distinct from the free packages. Confirm the license position first.
- The customization debt is the real problem. If the org carries dozens of TDTM handlers and nobody knows what they do, the honest first project is an automation inventory.
- No window. Advising offices are busiest at registration and midterm alerts. If the next quiet window is months away, plan the move for it rather than forcing it.
What to decide before building: same org or new org, which package objects migrate and which are archived, the portal username pattern, the Marketing Cloud key strategy, and who on staff owns the mapping document after go-live.
Questions We Hear
Does the Data Migration Kit do the whole migration?
No. It transforms and copies data from EDA, Admissions Connect, and Student Success Hub objects into Education Cloud objects using Data Processing Engine definitions. It does not move custom code, flows, TDTM handlers, page layouts, reports, dashboards, email templates, or Experience Cloud sites. On a typical project the data runs are the minority of the effort.
Can we migrate Student Success Hub and leave Admissions Connect for later?
Yes. The kit ships separate definition packages for EDA, Student Success Hub, and Admissions Connect, and the EDA foundation runs first in either case. Many move advising first, then admissions after the next cycle closes. The Person Account conversion happens once, in the first phase.
What happens to our Advisor Link history?
Historical appointments, success plans, and alerts move as closed ServiceAppointment, CarePlan, and RecordAlert records, flagged as migrated. Advisor notes carry over as the related records the kit maps. The institution decides how many years move as records; most keep the current students' full history and archive graduated cohorts to reporting storage.
Will our Experience Cloud portal keep working?
Not without changes. Portal users tied to contacts must be deactivated for the Person Account conversion and recreated on the new records, and portal pages that read package objects must be re-pointed to the standard ones. We treat the portal as a rebuild on the standard objects, and we schedule the user switch so students are not locked out during a deadline.
How long does it take?
For an advising office on Student Success Hub with a modest amount of custom automation, plan on roughly three months from discovery to hot test. Adding Admissions Connect, a heavily customized EDA org, or a new-org destination extends that. The schedule is governed by data cleanliness for the Person Account conversion and by how much TDTM logic must be rebuilt in Flow.
Do we need Education Cloud licenses for every advisor?
Education Cloud is a paid product, and the standard objects and consoles require it. Which users need which license is a conversation with your Salesforce account executive, and we have it before mapping begins. The published list price is on Salesforce's Education Cloud pricing page.