CourseStorm serves community and adult education well, and a small program should stay on it. The move to a Salesforce storefront on Education Cloud makes sense when a unit grows into multi-program university scale, needs a CRM, and wants one learner record across the institution. ElevateActual will say so in discovery, including when the answer is to stay.
What Does CourseStorm Do?
CourseStorm is a registration and marketing platform for small and mid-sized community, adult, and arts education programs. It started in Orono, Maine, and its product is deliberately simple: a hosted catalog, online registration, payment collection, automated marketing email, and reporting, with very little to configure. CourseStorm publishes its pricing on its website, and the model is per-registration: a share of each registration plus a fixed fee, rather than an annual license. We do not quote the figures here; read the vendor's page for the current numbers.
That model is the product's honesty. A town adult education office with a seasonal catalog pays when it sells and pays little when it does not. CourseStorm's own positioning contrasts its community programs with formal institutions like colleges, which tells you who it was built for. Public reviews on Capterra are generally favorable, and we see no reason to argue with them.
This page exists for a narrower reader: the program that started on CourseStorm, grew, and now sits inside a university or college with more than one unit asking for the same thing.
Why Do Teams Consider Moving to Salesforce?
Scale changes the question. A continuing education storefront on Salesforce is not a better CourseStorm; it is a different kind of system, and the reasons to want one appear at a particular size.
Per-registration pricing scales with volume. That is fair for a small program and becomes a line item worth modeling at university volume. We do not quote CourseStorm's figures; put your own registration count against the vendor's published page and against the cost drivers in what drives the cost of a Salesforce storefront. Sometimes CourseStorm still wins that comparison, and we will tell you so.
The unit needs a CRM. Multi-program units market to prospects, not just registrants. They want inquiry capture, nurture email, a learner history across programs, and a support case history, and they want those on the same record. With Salesforce Commerce for higher education, the order, the Person Account, the enrollment, and the case are one database.
The institution is standardizing on Salesforce. When admissions, advancement, or marketing already runs on Salesforce, a unit on a separate registration platform becomes the exception on every data request.
Multi-unit commerce. Once a second and third unit want a catalog, one storefront with one cart and one administrative model costs less to run than three separate registration accounts, and the learner who buys from all three is one person.
What Moves and What Stays?
CourseStorm shops are usually lighter on integrations than university registration systems, which makes the move simpler. The rows that need care are the learner history and the marketing automation.
| Data or capability in CourseStorm | Where it goes in Salesforce | Notes |
|---|---|---|
| Hosted catalog and class pages | Commerce on Core storefront, products and categories | Program marketing can stay on the institution's site with deep links to the storefront. |
| Classes, sessions, terms | LearningProgram, LearningCourse, CourseOffering, AcademicTerm | Mapped in the catalog workshop; the hierarchy usually gets deeper than it was. |
| Registrant profiles | Person Accounts | Matching on email agreed before the first load; many CourseStorm shops have no campus ID yet. |
| Registration history | CourseOfferingParticipant | Becomes the learner history that marketing and advising can use. |
| Orders and payments | Order Summary and Order Item Summary | History archived read-only; money moves to the institution's processor or Salesforce Payments. |
| Automated marketing email | Marketing Cloud or Account Engagement, with Flow for transactional messages | This is a build; CourseStorm's automation is simple and you will be designing yours. |
| Household and family registration | Person Accounts with relationships, or Delegated Access | Parent registering a child is a design decision early in discovery. |
| Payment processor | Institution's processor stays, or Salesforce Payments with Stripe | Salesforce integrates with TouchNet or Transact CashNet; it does not replace them. |
| LMS, if any | Stays | Enrollment handoff is built on the LMS API. |
| SIS, if the unit reports into one | Stays as system of record | Supported APIs only; never direct database writes. |
| Waitlists | CourseOfferingParticipant status | Automatic promotion is Flow automation we build. |
| Instructor pay | Stays in payroll, or rebuilt as a report | Not a standard Salesforce feature. |
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. Every purchase creates an Order Summary and Order Item Summary record the rest of the institution 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. Checkout creates the CourseOfferingParticipant record, so registration and sale are one event. The learner is a Person Account, which is the first time many CourseStorm registrants exist as a record anywhere else on campus.
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. The payments article covers both, and the choice usually depends on whether the unit now reports into a bursar. Where there is an SIS, it stays the system of record.
Our house demonstration storefront, ElevateActual University, shows the shape of it: 50 programs, seven categories, one cart, guest checkout. Guest checkout matters for a community audience that does not want an account.
How Do We Run the Migration?
- Discovery. Structured sessions with program staff, finance, marketing, and IT. For a CourseStorm shop, the first finding is usually how many other units want in, because that changes the scope.
- Catalog mapping. A workshop that maps CourseStorm classes and sessions to the learning objects and the Commerce product and price book. The hierarchy usually grows, and that is the point.
- Build the storefront on your own programs. Not sample data.
- Delta loads. Registrants and history load in waves while CourseStorm keeps running. No data freeze.
- Parallel period. CourseStorm finishes the current season while the Salesforce storefront opens the next. Staff work both for a defined window of weeks.
- Cutover. Catalog URLs redirect, CourseStorm registration closes, and a final delta runs.
- The production hot test. Your staff buy a real class with a real card in production, confirm the enrollment, the receipt, and any LMS or SIS record, then refund it. The storefront is live when that passes.
Because CourseStorm shops carry fewer integrations, this move can land close to the two-month Commerce accelerator timeline when the unit is the only one going live. Adding units, an SIS, or a bursar handoff adds months. The UAT and go-live article describes the acceptance steps.
When Should You Not Move?
Most CourseStorm programs should not move, and we would rather say that here than after a discovery invoice. A community or adult education program with one catalog, seasonal volume, a small staff, and no institutional CRM is exactly who CourseStorm was built for. Per-registration pricing is a feature at that size. Simplicity is a feature at that size. Stay.
Stay if the institution has no Salesforce footprint and no plan for one; a storefront needs an administrator, and a program of three people should not become the campus Salesforce team by accident. Stay if your growth is in registrations rather than in programs and units, because volume alone does not create the CRM need.
Move when the unit has become a multi-program operation inside a university, when two or three other units want the same storefront, or when the institution has decided learners belong in its CRM. That is the point at which a registration tool and a platform stop being comparable. Our migration guides cover the other platforms on that path.
Questions We Hear
We are a small adult education program. Should we move to Salesforce?
Probably not. CourseStorm was built for programs like yours, its published per-registration pricing suits seasonal volume, and a Salesforce storefront needs an administrator you may not have. The move is for a unit that has grown into multiple programs inside a university that already runs, or plans to run, Salesforce. If that is not you, we will say so on the first call, and you can keep the thirty minutes.
Will moving save us money?
We do not know until we model it, and we do not quote CourseStorm's figures or ours on this site. Put your registration count against the vendor's published pricing page, then against the cost drivers of a Salesforce storefront: licenses, the build, payments, and the administrator's time. Sometimes CourseStorm wins. The move is justified by the CRM and the shared learner record more often than by the fee line.
What happens to our automated marketing emails?
They are rebuilt. CourseStorm's email automation is simple and included; on Salesforce, transactional messages such as receipts and reminders run in Flow, and campaign email runs in Marketing Cloud or Account Engagement, which are separate products. That is more capable and more work. Discovery lists each message you send today so nothing is lost in the move.
Does Salesforce replace the campus payment processor?
No. If your unit now reports into a bursar, the campus processor, TouchNet or Transact CashNet, stays and Salesforce integrates with it through hosted checkout. If the unit has no such requirement, Salesforce Payments with Stripe is the other pattern we have built. Either way, the receipt and the order live in Salesforce.
How long does a CourseStorm migration take?
Shorter than most registration system moves, because CourseStorm shops carry fewer integrations. A single unit with no SIS can land close to the two-month Commerce accelerator timeline. Each additional unit, an SIS integration, or a bursar handoff adds time, so plan in months once more than one unit is involved. The production hot test happens the week before the public opening.