TargetX is a recruitment and admissions CRM built on the Salesforce Platform, so moving to Education Cloud is a same-platform migration: the records stay in Salesforce while the applicant model, the portal, and the email tooling move to standard objects. ElevateActual plans the cutover against the TargetX contract end date and runs both models in parallel.
What Does TargetX Do?
TargetX is a recruitment and retention CRM delivered as managed packages on Salesforce. It covers inquiry capture, event management, online applications, application review, communication plans, and an email tool, with a student portal in front. Liaison International acquired TargetX in October 2020. The product remains available as of October 2026.
Because TargetX lives in a Salesforce org the institution owns, the admissions funnel is already Salesforce data. The move is from a package data model to the standard Education Cloud admissions model inside the same platform, which is why we describe it as data continuity rather than data migration in the usual sense. Our Salesforce for higher education guide covers how Education Cloud (Agentforce Education) fits with the rest of the institution.
Why Do Admissions Teams Consider Moving?
The institution's situation is usually some mix of the following.
- Support after the acquisition. Some reviewers on TrustRadius report that customer and account support changed after the Liaison acquisition, and that heavy customization makes other AppExchange tools harder to adopt. We state that as reviewer sentiment, not as our finding.
- A contract end date is approaching. When the renewal comes up, institutions compare the package against running admissions on Education Cloud objects they may already be licensed for.
- The package model has been stretched. Years of customization leave applicant data spread across wide records with dozens of status picklists. Reporting on the funnel means spreadsheets.
- One platform for the whole student lifecycle. Institutions that want admissions, student success, advising, and continuing education commerce on the same Person Account are pulled toward the standard model.
- The graduate and professional funnel needs its own shape. Doctoral and professional programs have rolling terms, interview stages, and registrar contingencies that are easier to model as separate standard records than as additional fields.
A Worked Example
A private health-sciences university with graduate and doctoral programs across two campuses moved recruitment and admissions off TargetX onto standard Education Cloud. The build used Person Accounts, Learning Programs, Academic Terms, Individual Application with Application Timelines and Decisions, Action Plans as applicant next steps, an Experience Cloud applicant portal, FormAssembly forms for inquiry and application, CRM Analytics funnel dashboards that replaced spreadsheets, and a staging-table integration to its Jenzabar SIS so admitted students are no longer re-keyed. Historical applicant records migrated. Registrar evaluation and contingencies run inside Salesforce, each contingency as its own case. The new system went live in summer 2026, ahead of the TargetX contract end. The full story is in our health-sciences university admissions case study.
What Moves and What Stays?
The recommended mapping below is the one we start from. Every TargetX org is customized, so discovery adjusts it.
| TargetX data or capability | Where it goes in Education Cloud | Notes |
|---|---|---|
| Inquiries, prospects, and applicants (Contacts, often with Accounts per person) | Person Accounts (Account with IsPersonAccount), ContactProfile | Conversion needs one contact per account, matching owners, and no active portal user. Clean duplicates before converting. |
| Programs, majors, and entry terms | LearningProgram, AcademicTerm, ProgramTermApplnTimeline | Program-term deadlines become records, not picklists. |
| Applications and their status fields | IndividualApplication with ApplicationTimeline and ApplicationDecision | Each status transition becomes a dated record. See the trap below. |
| Reader reviews and committee scores | ApplicationReview | Rubrics become templates; past scores load as closed reviews. |
| Recommendations | ApplicationRecommendation, ApplicationRecommender | Letters move as Files on the recommendation. |
| Checklists and missing items | Action Plans on the application | Open items migrate; completed items load as history. |
| Test scores | Examination, PersonExamination | Standard Education Cloud objects. |
| Events, visits, and attendance | Campaign, CampaignMember | Registration forms are rebuilt on the portal. |
| Communication plans and email | Marketing Cloud, Account Engagement, or Flow email, per the institution's license | Templates are rebuilt. Images hosted by the old tool must be re-hosted (see below). |
| Student portal and online forms | Experience Cloud applicant portal with standard application rendering or FormAssembly | Forms do not migrate; the field specification does. |
| Custom Apex, triggers, and package automation | Retired or rebuilt in Flow | Inventory first. Most of it exists to work around the flat model. |
| Matriculated student record | Stays in the SIS | Salesforce owns the funnel; the SIS owns the student. |
The Flat Record Model Trap
The one trap on TargetX moves is the flat record. On the orgs we have inherited, much of the applicant story sits on the Contact and on a single application record as side-by-side fields: program, term, status, sub-status, decision, decision date, and deposit flag. Education Cloud wants that as related records. A person has several applications; each application has timelines, reviews, and decisions. If you map flat fields one to one onto IndividualApplication, you reproduce the problem on new objects and lose the reason for moving. The mapping has to pivot: one source record often becomes one application plus several child records, and field history, where it was tracked, becomes the source for dated decision records.
Email Images Hosted in the Old Tool
TargetX email templates typically reference images hosted by the email tool. When the contract ends, those URLs stop resolving, and every template copied forward breaks visually. Before cutover we export the image library, re-host it in the new email platform or in Salesforce content, and rewrite template references. This is a small task that is painful to discover after the contract has lapsed.
What Does the Salesforce Side Look Like?
An applicant is a Person Account. Each application is an IndividualApplication tied to a LearningProgram and an AcademicTerm, with ApplicationTimeline for deadlines, ApplicationReview for readers, and ApplicationDecision for outcomes. Next steps are Action Plan items the applicant sees in the portal.
The portal is Experience Cloud. Applicants start and resume applications, upload documents, track checklist items, and read decisions. Our applicant portal on standard Education Cloud article describes the pages and the permission model.
Automation is Flow and Platform Events: stage advancement, reader assignment, acknowledgments, and the handoff to the SIS when a decision becomes an admit. Funnel reporting runs on standard reports or CRM Analytics against the new objects. The SIS stays the system of record; Salesforce feeds it through a supported integration or a staging table, never through direct database writes.
How Do We Run the Migration?
- Discovery. Inventory of package objects, custom fields, automation, email templates, portal pages, reports, and integrations, each tagged keep, map, rebuild, or retire. We also pull the TargetX contract end date, because it anchors everything after this step.
- Object mapping. A signed mapping document, including the pivot rules that turn flat fields into application, timeline, review, and decision records.
- Initial load and delta loads. A full load into a full sandbox, then into production while TargetX remains live, then scheduled delta loads of changed records.
- Parallel period. Counselors work both models for one to two weeks. Counts by program, term, and stage must reconcile, and a sample of applications is read side by side.
- Identity and username planning. While the TargetX portal stays up, applicants with existing logins are contacts with active Experience Cloud users, which blocks Person Account conversion. We schedule user deactivation, conversion, and new user creation, pick a username pattern that cannot collide with the old portal, and write the applicant notice before the first production load.
- Cutover. A dated switch set well before the contract end, outside any deadline week. The old portal is turned off, the email images have been re-hosted, and the SIS integration points at the new objects.
- Hot test. Within a day of cutover, staff submit, review, and decide a real test application on production and confirm it reaches the SIS.
The load order, validation queries, and sign-off list are in our data migration into Education Cloud checklist. Other platform guides are on the migrations hub.
When Should You Not Move?
- The contract has years to run and the team is content. If TargetX is doing its job and nobody is asking for student success, commerce, or Agentforce on the same records, the honest advice is to plan the move for the renewal window rather than now.
- Education Cloud licensing is not settled. The standard objects require Education Cloud, a paid product. Settle licensing before mapping.
- The institution is heading to a different admissions tool entirely. If admissions is moving to another vendor by a decision already made, this page is not the plan.
- No internal owner. If nobody on staff will own the mapping document and the portal after go-live, start with that hire.
What to decide before building: the cutover date relative to the contract end, how many historical cycles migrate as records, the email platform that replaces the TargetX tool, and the username pattern for the new portal.
Questions We Hear
Is this a migration or a reconfiguration?
Both, in the same org. The records never leave Salesforce, which removes the export, transport, and reload risk of a cross-vendor move. What changes is the shape of the data, from package objects and flat fields to standard Education Cloud objects, and the user-facing layer, from the TargetX portal and email tool to Experience Cloud and a new email platform.
What happens to applicants mid-cycle at cutover?
They carry over with their open applications, checklist items, and documents, because delta loads bring every changed record up to the cutover moment. Applicants receive a notice with their new portal login. Deadline weeks are excluded from the cutover window so nobody is locked out while a submission is due.
Can we keep our custom fields?
Some, and only with a reason written down. Most custom fields on TargetX orgs exist to work around the flat model and are replaced by standard related records. Fields that carry institution-specific meaning, such as a licensure track or a campus preference, move to the appropriate standard object as custom fields with documentation. Our stance is standard objects first.
Does the SIS integration have to be rebuilt?
Re-pointed, usually. The feed that sends admitted students to Jenzabar, Banner, or Colleague now reads from IndividualApplication and the Person Account. Because account IDs change during Person Account conversion, key mappings are tested in a sandbox before production. The health-sciences university example used a staging-table integration to Jenzabar for this handoff.
How far ahead of the contract end should we start?
Six to nine months is comfortable for a single admissions office. That leaves time for discovery, a mapping that handles the flat-record pivot, two sandbox loads, a parallel period, and a cutover that is not the week before the contract lapses. Multi-college universities with several application families should start earlier.
Will our funnel reports survive?
The reports are rebuilt; the numbers are preserved. Historical applications load with their decisions and dates, so year-over-year funnel comparisons continue. The health-sciences university used the move to retire spreadsheet reporting in favor of CRM Analytics dashboards on the new objects.