Moving from Destiny One to Salesforce means replacing a noncredit registration 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 these moves with a parallel period and a production hot test before the old system closes.
What Does Destiny One Do?
Destiny One is a registration and student lifecycle system for noncredit and lifelong learning units. Modern Campus now markets it as Modern Campus Lifelong Learning. It began at Destiny Solutions in Toronto, which merged with OmniUpdate in October 2019 to form the company that became Modern Campus. Modern Campus then acquired Augusoft and its Lumens product in January 2022, and Providence Equity Partners took a majority investment in the company in 2025. As of October 2026, Modern Campus sells two continuing education registration products, Destiny One and Lumens, and has announced no plan to combine them.
Destiny One's typical home is a university professional, continuing, and online education division or an extension school. It carries the public catalog, section scheduling, registration, waitlists, CEU and transcript tracking, certificates, instructor records, payments and refunds, promotion codes, corporate and group registration, and marketing consent. A unit that has run on it for a decade treats it as the operational system, not just the shopping cart.
Modern Campus describes its integrations under the name Destiny Connect. The vendor's integrations page lists plug-ins for an LMS (Canvas is named), Salesforce and Pardot CRM, CAS, LDAP, and Shibboleth authentication, and a generic exchange with SIS, ERP, and payment processor systems. Destiny One can already talk to Salesforce, so the decision to move is about which system owns the learner, not about connectivity.
Why Do Teams Consider Moving to Salesforce?
None of the four reasons below is that Destiny One is going away; nothing of the kind has been announced.
The campus is standardizing on Salesforce. Admissions, advancement, or marketing already runs on Salesforce, and the continuing education unit is asked why its learners live somewhere else. A continuing education storefront on Salesforce puts the noncredit learner in the same CRM as the applicant and the donor.
One data model for storefront, CRM, and service. With a registration system plus a CRM plug-in, the learner exists twice and the integration decides which copy wins. With Salesforce Commerce for higher education, the order, the Person Account, the enrollment, the marketing consent, and the support case are records in one database. Reporting is a report, not an export.
Template and customization limits. Some reviewers on GetApp report rigid templates that are hard to customize and a heavy IT support burden. Most of those reviews date from 2019 and 2020, so weigh them against your own experience of the current release. On the Salesforce side, the storefront is an Experience Cloud site your team edits in Experience Builder.
Multi-unit commerce. A storefront built for one continuing education unit can also sell a conference registration, a summer camp, a certificate from a second college, or a gift, from one cart. Destiny One was designed for noncredit registration. Salesforce Commerce was designed for selling things.
What Moves and What Stays?
Your discovery will add rows to this table. The last four decide whether the move is worth it.
| Data or capability in Destiny One | Where it goes in Salesforce | Notes |
|---|---|---|
| Public catalog and course pages | Commerce on Core storefront, products and categories | Program marketing can stay on the .edu site with deep links into the storefront. |
| Programs, courses, sections | LearningProgram, LearningCourse, CourseOffering, AcademicTerm | Mapped in the catalog workshop during discovery. |
| Learner profiles | Person Accounts | Matching rules on email and SIS identifier are agreed before the first load. |
| Enrollment history, grades, CEUs | CourseOfferingParticipant | Education Cloud models CEUs on the same learning objects as degree credit. |
| Orders, payments, refunds | Order Summary and Order Item Summary | Money stays in the campus processor; history is archived read-only, not reloaded as live orders. |
| Corporate and group registration | Account-based buying on Commerce on Core | Decide in discovery whether a company buys seats or pays for named learners. |
| Payment processor (TouchNet, Transact CashNet) | Stays | Salesforce integrates with it through hosted checkout; it does not replace it. |
| LMS (Canvas and others) | Stays | The enrollment handoff is an integration built on the LMS vendor's API. |
| SIS (Banner, Colleague, PeopleSoft, Jenzabar) | Stays as system of record | Supported APIs only; never direct database writes. |
| Waitlists | CourseOfferingParticipant status | Automatic promotion from the waitlist is Flow automation we build, not a switch. |
| CEU transcripts | Rebuilt as a portal page or document | The data is standard; the transcript itself is a build. |
| Instructor pay | Stays in payroll, or rebuilt as a report | Salesforce holds the assignment and headcount; the calculation is not a standard feature. |
| State noncredit reporting | Rebuilt as reports or Flow-generated extracts | Budget each state extract as 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, which we do not use for higher education. Every purchase produces an Order Summary and Order Item Summary record the rest of the org can report on.
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: LearningProgram, LearningCourse, CourseOffering, CourseOfferingParticipant, and AcademicTerm. We lay this out in the Education Cloud data model for continuing education. The learner is a Person Account. Checkout creates the enrollment record, so the registration and the sale are the same event.
Automation runs in Flow and Platform Events. Apex appears only where the platform requires it, for example a tax calculator extension or a payment adapter. Unit administrators manage course content from Salesforce fields under a Commerce Admin permission set rather than as system administrators.
Payments follow one of two patterns we have built: Salesforce Payments with Stripe, or a hosted checkout handoff to Transact CashNet or TouchNet, where the item code equals the course number and a post-authorization adapter writes the result back to the order. The payments article covers both. The SIS remains 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, finance, marketing, and IT. We leave with the list of Destiny One features you use, the ones you pay for and do not use, and the integrations that actually run.
- Catalog mapping. A workshop that maps Destiny One's programs, courses, sections, fees, and locations to the learning objects and the Commerce product and price book. The data model decisions are made here, in writing.
- Build the storefront on your own programs. Not sample data. From the first review session the catalog is yours, which is the fastest way to surface the exceptions.
- Delta loads. Historical learners and enrollments load in waves while Destiny One keeps running. There is no data freeze; each load picks up what changed since the last one.
- Parallel period. Destiny One finishes the current term's registrations while the Salesforce storefront opens the next term's. Staff work both for a defined window of weeks.
- Cutover. Catalog URLs redirect, Destiny One registration closes, and a final delta load runs. The SIS and payment integrations are already live from the parallel period.
- The production hot test. Before public opening, your staff buy a real course with a real card in production, confirm the enrollment, the receipt, the SIS record, and the LMS seat, then refund it. We do not call a storefront live until that test passes in front of the people who will run it.
Our Commerce accelerator goes live in about two months for a unit starting fresh. A move off a registration system with years of history runs longer; plan in months, with the count set by history depth and the integrations you keep. The UAT and go-live article describes the hot test in detail.
When Should You Not Move?
Destiny One is mature at the administrative work of noncredit education. Waitlists, CEU transcripts, instructor pay, and state reporting are built in, and a unit that runs on those features every day should count the cost of rebuilding them before it counts the benefit of a shared CRM. If your registration staff are content, your state extracts run on time, and the institution has no plan to put learners in Salesforce, stay.
Stay, too, if you are in the middle of a multi-year term. Use the remaining time to clean the catalog, document the integrations, and run a discovery so the decision at renewal is informed. Stay if nobody on campus can own a Salesforce org; a storefront without an administrator decays.
And if the only complaint is how the public catalog looks, fix the marketing site. That is cheaper than a migration and it might be enough. The move is right when the institution wants one learner record across units, which is a decision for the provost's office as much as for the continuing education dean. The rest of our migration guides cover the other platforms on that path.
Questions We Hear
Does Salesforce replace TouchNet or Transact CashNet when we leave Destiny One?
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 there is no campus processor requirement, Salesforce Payments with Stripe is the other pattern. The bursar's reconciliation continues where it is today.
How much Destiny One history should we migrate?
Learner profiles and enrollment history, including CEUs, almost always move, because they drive transcripts and marketing. Financial transaction detail is archived in a read-only form that finance can query rather than reloaded as live orders. Expired promotion codes and old marketing lists are left behind.
Can we keep Destiny One for administration and use Salesforce only as the storefront?
You can, and Destiny Connect lists a Salesforce plug-in, but you will have two systems that both believe they own the learner. In our experience that arrangement produces the reporting problems people were trying to escape. If the goal is one record, let Salesforce own enrollment and keep the SIS as system of record for what it already owns.
What happens to our waitlists?
Waitlists are modeled as Course Offering Participant records with a waitlist status, which is standard Education Cloud. Automatic promotion when a seat opens, the notification to the learner, and the hold on the seat while they pay are Flow automation we build to your rules. It is a known piece of work, but it is work, and it belongs in the scope from day one.
How long does a Destiny One migration take?
Longer than a fresh storefront. Our Commerce accelerator reaches production in about two months with no history to load. A Destiny One move adds catalog mapping, historical loads, and the integrations you keep, so plan in months. The parallel period is usually a few weeks, and the production hot test happens the week before public opening.