Moving from XenDirect to Salesforce replaces a noncredit registration and event system with a Commerce storefront on Education Cloud: one data model for catalog, checkout, learner record, marketing, and service. The campus payment processor, the LMS, and the SIS stay. ElevateActual runs the move with delta loads, a parallel period, and a production hot test before XenDirect closes.
What Does XenDirect Do?
XenDirect is a cloud registration system for noncredit education and events from Xenegrade, a long-established small company founded in 1991. The product carries class and event setup, online registration through its WebReg public module, staff registration, payments, waitlists, certificates, instructor records, and reporting. Its typical homes are community college continuing education offices and university professional and continuing education units.
Public review data on XenDirect is too thin to characterize as of October 2026. The Gartner Peer Insights listing exists, and a CIOReview profile describes the product's integrated registration data, but neither is a basis for generalizing. We do not repeat a single review as if it were a pattern.
What we can say is factual: Xenegrade is a small vendor with a long history. As with any small vendor, continuity, roadmap, and support hours are fair questions at every renewal. That is not a statement about XenDirect's future, which nobody has announced; it is a statement about how to buy software.
Why Do Teams Consider Moving to Salesforce?
None of the reasons below is that XenDirect is going away. The reasons are about where the institution wants the learner to live.
The institution is standardizing on Salesforce. Admissions, advancement, or marketing already runs on Salesforce, and the continuing education unit is asked why its learners sit in a separate system. A continuing education storefront on Salesforce puts the noncredit learner on the same Person Account model as the applicant and the donor.
One data model for storefront, CRM, and service. With Salesforce Commerce for higher education, the order, the enrollment, the marketing consent, and the support case are records in one database. The weekly enrollment question becomes a dashboard rather than an export.
Events and courses in one cart. XenDirect shops often sell both classes and events. A Salesforce storefront sells both from one cart, and the attendee and the learner are the same Person Account, which is useful when the conference attendee enrolls in the certificate next spring.
Vendor concentration. Some institutions prefer that a system touching tuition revenue sit on a platform with a large ecosystem of administrators and partners. That is a risk preference, not a criticism of a small vendor that has served the market for decades.
Multi-unit commerce. A storefront built for one unit can sell a camp, a test session, a facilities rental, or a gift from the same cart.
What Moves and What Stays?
Each row is a decision in discovery. The rebuilt rows are where the budget goes.
| Data or capability in XenDirect | Where it goes in Salesforce | Notes |
|---|---|---|
| Public catalog (WebReg) and class pages | Commerce on Core storefront, products and categories | Program marketing can stay on the .edu site with deep links to the storefront. |
| Programs, classes, sections, terms | LearningProgram, LearningCourse, CourseOffering, AcademicTerm | Mapped in the catalog workshop. |
| Events | Products on the storefront; attendees as Person Accounts | Sessions and tickets are modeled in the same workshop. |
| Learner profiles | Person Accounts | Matching on email and campus ID agreed before the first load. |
| Enrollment history, CEUs, certificates | CourseOfferingParticipant | CEUs use the same learning objects as credit. |
| Orders and payments | Order Summary and Order Item Summary | History archived read-only; money stays in the processor. |
| Group and company registration | Accounts and account-based buying | Decide whether companies buy seats or pay for named learners. |
| Payment processor (TouchNet, Transact CashNet) | Stays | Salesforce integrates through hosted checkout; it does not replace it. |
| LMS (Canvas and others) | Stays | Enrollment handoff is built on the LMS API. |
| SIS (Banner, Colleague, PeopleSoft, Jenzabar) | Stays as system of record | Supported APIs only; never direct database writes. |
| Waitlists | CourseOfferingParticipant status | Automatic promotion is Flow automation we build. |
| Document uploads on registration | Files on the Person Account or enrollment | Prerequisite documents are a storefront design decision. |
| State noncredit reporting | Rebuilt as reports or Flow-generated extracts | Each state extract is its own deliverable. |
What Does the Salesforce Side Look Like?
Commerce on Core is ElevateActual's term for B2B and D2C Commerce built on the Salesforce Platform with an LWR Experience Cloud storefront. It is not B2C Commerce, the former Demandware stack. The storefront is an Experience Cloud site your team edits in Experience Builder, and every purchase creates an Order Summary and Order Item Summary record.
Education Cloud (Agentforce Education) supplies the learning model. Salesforce documents the program and offering objects, and continuing education uses the same objects as degree programs. We walk through them in the Education Cloud data model for continuing education. Checkout creates the CourseOfferingParticipant record, so registration and sale are one event. The learner is a Person Account.
Automation runs in Flow and Platform Events. Apex appears only where the platform requires it, such as a tax calculator extension or a payment adapter. Payments follow one of two patterns we have built: Salesforce Payments with Stripe, or a hosted checkout handoff to Transact CashNet or TouchNet with a post-authorization adapter writing the result to the order. The payments article covers both. The SIS stays the system of record for anything it already owns.
Our house demonstration storefront, ElevateActual University, shows the shape of it: 50 programs, seven categories, one cart, guest checkout.
How Do We Run the Migration?
- Discovery. Structured sessions with registration staff, events staff, finance, marketing, and IT. We inventory the XenDirect features you use and the integrations that run.
- Catalog mapping. A workshop that maps XenDirect classes, events, sections, fees, and terms to the learning objects and the Commerce product and price book. Decisions go in writing.
- Build the storefront on your own programs. Not sample data. The first review shows your catalog, which surfaces the exceptions early.
- Delta loads. Learners and enrollment history load in waves while XenDirect keeps running. No data freeze; each load picks up what changed. Export formats from a small vendor's system are checked early, because that is where surprises hide.
- Parallel period. XenDirect finishes the current term while the Salesforce storefront opens the next one. Staff work both for a defined window of weeks.
- Cutover. WebReg URLs redirect, XenDirect registration closes, and a final delta runs. The SIS and payment integrations are already live from the parallel period.
- The production hot test. Your staff buy a real class with a real card in production, confirm the enrollment, the receipt, the SIS record, and the LMS seat, then refund it. The storefront is live when that passes.
Our Commerce accelerator reaches production in about two months for a unit starting fresh. A XenDirect move adds history and integrations, so plan in months. The UAT and go-live article describes the acceptance steps and the hot test.
When Should You Not Move?
If XenDirect does the daily work of your office, your staff know it well, and the institution has no plan to put learners on Salesforce, stay. A unit replacing one registration system with another, with nothing else changing, gains a new look at a real cost. Small vendors also tend to answer the phone, and that has value.
Stay if you are mid-contract; use the time to clean the catalog and document what you actually use. Stay if nobody on campus can own a Salesforce org, because a storefront without an administrator decays. Stay if your state reporting is deeply tied to XenDirect and there is no budget to rebuild it.
Move when the institution wants one learner record across units, when events and courses should share a cart and a CRM, or when the risk preference of the CIO's office favors a large platform. That decision belongs to the cabinet as much as to the dean. Our migration guides cover the other platforms on that path.
Questions We Hear
Does Salesforce replace TouchNet or Transact CashNet when we leave XenDirect?
No. The campus payment processor stays and Salesforce integrates with it. Checkout hands off to the processor's hosted page with a signed request, and the authorization result is written back to the order in Salesforce. Where the institution has no processor requirement, Salesforce Payments with Stripe is the other pattern. The bursar's reconciliation continues as it does today.
Can we get our data out of XenDirect?
Every registration system we have migrated from provides exports, and we check the formats in the first weeks rather than at cutover. Learner, class, enrollment, and transaction extracts are loaded in waves, with matching rules agreed first. If an export is missing a field you rely on, that is a discovery finding, and we would rather find it in week two than week twelve.
We also run events in XenDirect. Does that move?
Yes. Events are products on the storefront, sessions and tickets are modeled in the same catalog workshop as classes, and the attendee is a Person Account. The practical gain is that the attendee and the learner are the same record, so a conference registrant who later enrolls in a certificate has one history and one marketing consent.
How much XenDirect history should we load?
Learner profiles and enrollment history, including CEUs and certificates, almost always move. Financial detail is archived in a read-only form finance can query rather than reloaded as live orders. Expired promotions and old lists stay behind. Load what a staff member would look up for a learner on the phone and archive the rest.
How long does a XenDirect migration take?
Longer than the two-month Commerce accelerator, because of history and integrations. Plan in months, with the count set by how many years you load and how many systems you keep connected. The parallel period is a few weeks, and the production hot test happens the week before the public opening.