Enrollment Rx is a managed package on Salesforce, so its records already sit in your org. Moving to Education Cloud means remapping package objects onto standard objects such as Individual Application and Learning Program, rebuilding forms on an Experience Cloud portal, and retiring the package without losing a cycle. ElevateActual runs that move beside a live admissions season.
What Does Enrollment Rx Do?
Enrollment Rx is an admissions CRM built natively on the Salesforce Platform. It is sold as modules: online applications, events and visits, and application review, with companion tools for data import and integration. Because it is a managed package, an Enrollment Rx institution already owns a Salesforce org, already has admissions users with Salesforce logins, and already stores applicants, applications, programs, and terms as Salesforce records. Many installs sit alongside EDA, the free Education Data Architecture package, which supplies the account, contact, program, and term structure underneath.
The question is not whether the data can reach Salesforce. It is already there. The question is how to reshape it from package objects into the standard Education Cloud admissions model so the institution stops maintaining a second data model on top of the platform it already runs. The broader picture of what Education Cloud (Agentforce Education) covers is on our Salesforce for higher education guide.
Why Do Admissions Teams Consider Moving?
The institution's situation usually looks like one of these.
- Two data models in one org. Package application objects, EDA program and term objects, and a growing set of custom fields all describe the same applicant. Reports join across them, and every new staff member has to learn where the truth lives.
- Older page technology. The applicant-facing and reviewer-facing pages in older installs are Visualforce. They work, but changing them takes a developer rather than an administrator.
- Education Cloud is now the standard. Salesforce's paid Education Cloud product models applications, timelines, decisions, reviews, and recommendations as standard objects. Institutions that want Agentforce, Data 360, or Student Success on the same records are pulled toward that model.
- The package has become the storefront. Some continuing and online units stretched Enrollment Rx into a registration and payment front door. UNE Online replaced a Salesforce EDA plus Enrollment Rx storefront with Education Cloud and Commerce on Core (our term for B2B or D2C Commerce on the Salesforce Platform with an LWR Experience Cloud storefront), and said at the Education Trailblazers Summit in June 2026 that most of its support tickets had come from the old storefront not working. The UNE Online case study covers that storefront scope.
"It's bad for the college and worse for me." UNE Online, Education Trailblazers Summit, June 2026, on the old platform.
None of this means Enrollment Rx has stopped working. It means the institution has outgrown a package layer and wants the standard layer underneath it.
What Moves and What Stays?
The recommended mapping below assumes a typical install with EDA underneath. Where EDA is present, Salesforce's own Data Migration Kit handles the EDA half (contacts to Person Accounts, terms, programs, course connections). The Enrollment Rx application objects are not covered by that kit and need their own mapping, which we build in Data Processing Engine definitions or Data Loader jobs. Our article on moving from EDA to Education Cloud without a data freeze explains the EDA side in detail.
| Enrollment Rx or EDA data | Where it goes in Education Cloud | Notes |
|---|---|---|
| Prospects, applicants, and contacts | Person Accounts (Account with IsPersonAccount), ContactProfile | Conversion requires one contact per account, same owner, and no active portal user on the contact. Deduplicate first. |
| Programs and terms | LearningProgram, AcademicTerm, ProgramTermApplnTimeline | Program-by-term deadlines become timeline records instead of picklists. |
| Applications | IndividualApplication with ApplicationTimeline and ApplicationDecision | One application per person per program per term. Status history is reconstructed from field history where it exists. |
| Reviewer scores and comments | ApplicationReview | Rubrics become review templates; historical scores load as closed reviews. |
| Recommendations | ApplicationRecommendation, ApplicationRecommender | Letters move as Files linked to the recommendation record. |
| Checklist items and next steps | Action Plans on the application | Open items migrate; completed items load as history or are summarized. |
| Test scores | Examination, PersonExamination | Matches the Data Migration Kit target for EDA tests. |
| Events and visits | Campaign, CampaignMember | Standard objects; registration forms are rebuilt on the portal. |
| Online application forms (Visualforce) | Rebuilt on the Experience Cloud applicant portal | Forms do not migrate. The field list does. |
| Custom Apex, triggers, and TDTM handlers | Retired or rebuilt in Flow | Table-Driven Trigger Management is not compatible with Education Cloud, per Salesforce Help. |
| Reports, dashboards, and email templates | Rebuilt on the new objects | We inventory and cut. |
| Admissions decisions as the record of truth | Stays in the SIS | Salesforce holds the funnel; the student information system holds the matriculated student. |
What Does the Salesforce Side Look Like?
After the move, an application is an IndividualApplication record tied to a Person Account, a LearningProgram, and an AcademicTerm. Deadlines come from ApplicationTimeline. Reviews are ApplicationReview records that a committee works through in a Lightning console. Decisions are ApplicationDecision records, so a deferral and a later admit are two records rather than an overwritten picklist.
Applicants work in an Experience Cloud portal: they start an application, upload documents, see their checklist as Action Plan items, and read their decision. Our applicant portal on standard Education Cloud article shows what that portal contains and what it deliberately leaves out.
Automation runs in Flow and Platform Events. Record-triggered flows advance stages, create reviewer assignments, and send acknowledgments. Apex appears only where the platform requires it. The SIS remains the system of record for the admitted and enrolled student; Salesforce pushes the admit through a supported integration and never writes to the SIS database directly.
How Do We Run the Migration?
- Discovery. We inventory every package object, custom field, trigger, Visualforce page, report, and integration that touches admissions, and tag each one keep, map, rebuild, or retire. Salesforce Optimizer runs early to surface technical debt.
- Object mapping. A written mapping from each source object and field to its Education Cloud target, with the transformation rule and the owner who signs it off. This is the document every later step refers back to.
- Same org or new org. Salesforce supports both. Same-org keeps record IDs and integrations but doubles storage during the move, because migrated data is copied rather than moved. We recommend same-org unless the existing org carries debt the institution wants to leave behind.
- Initial load and delta loads. A full load into a full sandbox first, then into production while the old pages stay live, then delta loads of records changed since the last run. Deltas keep the parallel period honest.
- Parallel period. Staff review the same applications in both models for one to two weeks. Counts by program, term, and stage must match.
- Identity and username planning. This is the trap on Enrollment Rx moves. Applicants who already have portal logins are contacts with active Experience Cloud users, and Salesforce will not convert such a contact to a Person Account. The plan has to deactivate those users, convert, create new users on the Person Accounts, and re-establish record ownership. If the old application pages stay up during the parallel period, usernames must not collide between the old and new portal. We decide the username pattern and the notification wording before the first production load.
- Cutover. A dated switch, outside a deadline week, after which the old pages are read-only. Migration packages and their temporary fields are uninstalled once validation closes.
- Hot test. Within 24 hours of cutover, real staff submit a test application end to end on production, review it, decide it, and confirm the SIS handoff.
A full working list of loads, checks, and sign-offs is in our data migration into Education Cloud checklist. Our other platform guides sit on the migrations hub.
When Should You Not Move?
Candidly, some institutions should stay put for now.
- The package is doing its job and the team is small. If one administrator runs admissions on Enrollment Rx with few customizations and no plans for portals, student success, or commerce on the same records, a move adds work without changing outcomes this year.
- The license position is unclear. Education Cloud is a paid product distinct from EDA. If the institution has not confirmed its Education Cloud licensing, that conversation comes before any mapping.
- You are inside a recruitment cycle with no quiet window. The parallel period needs staff attention. Rolling admissions programs can still move, but the plan has to carve out a window.
- The real pain is the SIS integration. If applications flow fine and the complaint is re-keying admits into the SIS, fix the integration first. It may be enough.
What to decide before building: same org or new org, which historical cycles migrate as records and which are archived, the username pattern for portal users, and who owns the mapping document on the institution's side.
Questions We Hear
Do we lose our historical applications?
No. Historical applications load as closed IndividualApplication records with their decisions, reviews, and timelines, flagged as migrated. The institution decides how many cycles move as records and how many are archived to reporting storage. Most keep three to five cycles in Salesforce for yield analysis and move the rest to an archive that reports can still reach.
Can we keep Enrollment Rx running while Education Cloud is built?
Yes, and we recommend it. The package pages stay live through the build and the parallel period. Delta loads carry records changed in the old model into the new one until the dated cutover. After cutover the old pages become read-only, and the package is uninstalled only after validation and the hot test have passed.
Does Salesforce's Data Migration Kit cover Enrollment Rx?
Not directly. As of October 2026 the kit on Salesforce Help targets EDA, Admissions Connect, and Student Success Hub. If your install runs on EDA, the kit handles the contact, program, term, and course connection records. The Enrollment Rx application, review, and event objects need a mapping we write, typically as Data Processing Engine definitions in the same style.
Do our online application forms migrate?
The forms themselves do not. They are rebuilt on the Experience Cloud applicant portal using the field list and conditional logic from the old forms as the specification. The applicant data behind past submissions does migrate. Rebuilding is also the moment to cut questions nobody uses.
How long does the move take?
For a single admissions office with one application form family, plan on roughly three to four months from discovery to hot test, with the parallel period inside that window. Multi-school universities with several application types, many reviewer rubrics, and an SIS integration run longer. The schedule is driven by how many forms must be rebuilt and how clean the contact data is.
What happens to our SIS integration?
It is re-pointed, not rewritten from scratch. The integration that pushes admits to Banner, Colleague, Jenzabar, or another SIS now reads from IndividualApplication and the Person Account instead of the package objects. Because record IDs for accounts change during Person Account conversion, the integration's key mapping is tested in a sandbox before production.