Moving from Lumens to Salesforce replaces a noncredit class registration system with a Commerce storefront on Education Cloud: one data model for catalog, checkout, learner record, employer accounts, 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 Lumens closes.
What Does Lumens Do?
Lumens is a software-as-a-service class registration system for noncredit continuing education, corporate training, and workforce programs. It was built by Augusoft, a Minneapolis-area company. Modern Campus acquired Augusoft in January 2022, and the product is now sold as Modern Campus Lumens. Modern Campus itself formed from the 2019 merger of OmniUpdate and Destiny Solutions, and Providence Equity Partners took a majority investment in the company in 2025.
That history matters for one reason. As of October 2026, Modern Campus sells two continuing education registration products, Lumens and Destiny One. It has announced no plan to combine them, and we do not speculate about one. Ask the vendor how the two relate before you renew; it is a fair question. Our Destiny One guide covers the sibling product.
Lumens's typical home is a community college workforce or continuing education division. It covers the public catalog, class and section setup, online and staff registration, payments, waitlists, certificates, instructor assignment, and reporting. Modern Campus's case studies for Lumens emphasize growth in self-service registration; those are vendor-reported figures and we do not repeat them.
Why Do Teams Consider Moving to Salesforce?
The reasons are the same four we hear about every registration system, plus one that is specific to workforce divisions. None of them is that Lumens is going away; nothing of the kind has been announced.
The college is standardizing on Salesforce. Recruitment, advising, or the foundation already runs on Salesforce, and the workforce division is asked why its learners live somewhere else. 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 employer account, and the support case are records in one database. The dean's enrollment question becomes a report rather than an export.
Interface friction. A small number of reviewers on G2 report too many clicks for basic tasks and difficulty locating settings. The sample is small, so treat it as a prompt to time your own staff on a common task, not as a verdict.
Employer sales. Workforce divisions sell contract training to companies, and that sale looks like a B2B deal: an Account, Contacts, a quote, a purchase order, and a cohort. Registration systems were built for individual registrations. Salesforce was built for the Account.
Multi-unit commerce. One storefront and one cart can sell a certificate, a camp, a test session, a conference seat, and a facilities rental across divisions. We cover the wider community college case in Salesforce for community colleges.
What Moves and What Stays?
Each row is a decision in discovery. The rebuilt rows are where the budget goes, and we would rather you see them now than at week six.
| Data or capability in Lumens | Where it goes in Salesforce | Notes |
|---|---|---|
| Public catalog and class pages | Commerce on Core storefront, products and categories | Program marketing can stay on the college site with deep links to the storefront. |
| Programs, classes, sections, terms | LearningProgram, LearningCourse, CourseOffering, AcademicTerm | Mapped in the catalog workshop. |
| Learner profiles | Person Accounts | Matching on email and college 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. |
| Company and contract training | Accounts, Contacts, account-based buying | Decide whether companies buy seats or pay for named learners. |
| Staff-entered registrations | Order entry in Salesforce or the storefront on the learner's behalf | Phone and walk-in registration is a workflow we design, not an afterthought. |
| Payment processor (TouchNet, Transact CashNet) | Stays | Salesforce integrates through hosted checkout; it does not replace it. |
| LMS (Canvas, Blackboard, D2L) | Stays | Enrollment handoff is built on the LMS API. |
| SIS (Colleague, Banner, PeopleSoft) | Stays as system of record | Supported APIs only; never direct database writes. |
| Waitlists | CourseOfferingParticipant status | Automatic promotion is Flow automation we build. |
| Instructor pay and contracts | Stays in payroll, or rebuilt as a report | Salesforce holds the assignment; the calculation is not a standard feature. |
| 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 pages are edited in Experience Builder by your team, 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. Checkout creates the CourseOfferingParticipant record, so registration and sale are one event. The learner is a Person Account; the employer is an Account with Contacts.
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. 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, the contract training team, finance, marketing, and IT. We inventory the Lumens features you use, the ones you pay for and do not, and the integrations that run.
- Catalog mapping. A workshop that maps Lumens programs, classes, 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 Lumens keeps running. No data freeze; each load picks up what changed.
- Parallel period. Lumens finishes the current term while the Salesforce storefront opens the next one. Staff work both for a defined window of weeks.
- Cutover. Catalog URLs redirect, Lumens 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 in front of the people who will run it.
Our Commerce accelerator reaches production in about two months for a unit starting fresh. A Lumens 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?
Lumens does the daily work of a noncredit office, and a division whose staff are content, whose state extracts run on time, and whose college has no plan to put students on Salesforce should stay. Replacing one registration system with a storefront, with nothing else changing, is a lot of effort for a new look.
Stay if you are mid-contract; use the time to clean the catalog and document integrations so the renewal decision is informed. Stay if nobody at the college can own a Salesforce org. Stay if your contract training volume is small enough that a spreadsheet is honestly fine.
Move when the college is putting students on Salesforce anyway, when employer sales have outgrown individual registration, or when the division wants its learners in the same CRM as the rest of the institution. That is a cabinet decision as much as a dean's. Our migration guides cover the other platforms on that path.
Questions We Hear
Does Salesforce replace TouchNet or Transact CashNet when we leave Lumens?
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 college has no processor requirement, Salesforce Payments with Stripe is the other pattern. The bursar's reconciliation continues as it does today.
Should we wait to see what Modern Campus does with Lumens and Destiny One?
Ask Modern Campus directly; it is a reasonable renewal question and the vendor is the only reliable source. Nothing has been announced as of October 2026 and we will not guess. Our advice does not depend on the answer. If the college wants one learner record on Salesforce, the move is right regardless. If it does not, stay with whichever product serves you.
Can staff still register a learner over the phone?
Yes, and it is a workflow we design on purpose rather than leave to chance. Staff can place the order in Salesforce on the learner's behalf, or use the storefront as the learner would, with the payment handed to the processor the same way. Which one you want depends on how your front desk works today, and discovery is where we find out.
How much Lumens 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 Lumens 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.