Implementing Salesforce Education Cloud: 15 Questions, Answered

It depends on scope, and the ranges are stable across the projects we have run. A fixed-scope slice, such as admissions for one college or a continuing education storefront for one unit, takes about two months. Admissions for a whole institution with an applicant portal, forms, review, decisions, and an SIS handoff takes four to ten months, with the SIS integration setting the pace. Multi-module programs that add student success or advancement run a year or more, usually in phases that each go live. The concern with shorter estimates is that they omit data migration and integration, which are where the time goes. Recommendation: scope the first phase to one unit and one go-live. Decide the phase boundary before contracting. The timeline by scope article lays out each range.

A quick-start configures the product with sample data and a standard layout, hands over an admin guide, and stops. It is fast, and its concern is that nothing in it is yours: no migrated records, no integration, no trained staff, no process decisions. A full implementation covers discovery, design, data migration, integration, testing, training, and a go-live, and its concern is that scope grows unless someone holds the line. A fixed-scope accelerator sits between them: a defined deliverable list with your data and your branding, delivered in about two months, with structured discovery at the start. Recommendation: buy a quick-start only if you have an internal team ready to do the rest. Decide which you are buying before you compare prices. See the accelerators page.

Not always. An institution with a Salesforce administrator, a data lead, an integration developer, and a sponsor who can make decisions weekly can implement Education Cloud alone, and some do. The concern is that this team rarely exists in full, and that the first implementation is where the expensive mistakes are made: the Person Account conversion, the learning model, the sharing model. A partner's value is pattern recognition from previous orgs, not labor. Recommendation: use a partner for the first module and the migration, keep your own administrator in every design session, and plan to own the second module yourselves. Decide the ownership model before the statement of work is written, because it changes what the partner should deliver. The how we deliver page describes the model we use.

A fixed-scope accelerator is an implementation with a published list of deliverables, a known timeline, and a known price, in exchange for the institution accepting the scope as written. ElevateActual offers three: Commerce, Recruitment and Admissions, and Student Success, each live in about two months and each starting with structured discovery. The benefit is predictability for procurement and a short path to a working system. The concern is fit: an accelerator serves one unit with standard processes, and a unit that needs three application types and two payment paths will outgrow it before launch. Recommendation: start with the accelerator for the unit most ready to change, then scope phase two from what you learn. Decide the pilot unit before kickoff. Details are on the accelerators page.

Early enough to plan backward from it, and late enough that it is informed by discovery. The academic calendar sets the candidates: an admissions go-live lands before applications open, a storefront before a catalog publishes, a student success rollout before a term starts. The concern with fixing the date at contract signing is that nobody yet knows the data quality or the integration owner's availability; the concern with leaving it open is that the project drifts. Recommendation: name the target calendar event at kickoff, confirm the date at the end of discovery with the integration owner present, and record any later change as a formal decision. Decide by the end of discovery. The UAT and go-live article covers the final month.

Education Cloud, the paid product built on standard objects and Person Accounts. EDA, the Education Data Architecture, is a free managed package with a custom-object data model, and as of October 2026 Salesforce has not announced its retirement. Moving between them is a migration, not an upgrade. The concern for an EDA institution is timing: staying is supported, but new Salesforce investment, including Agentforce for Education, is built on Education Cloud. Recommendation: plan the move around a natural break such as an admissions cycle end, migrate one college first, and keep EDA read-only for history rather than freezing operations. Decide whether to migrate within the same org or to a new one before anything else. See moving from EDA to Education Cloud without a data freeze.

No retirement has been announced as of October 2026. Both are Salesforce.org managed packages built on EDA, and both still run. What has changed is direction: Salesforce's Data Migration Kit includes packages that map Admissions Connect and Student Success Hub data to Education Cloud objects, and new features arrive in Education Cloud's Recruitment and Admissions and Student Success modules rather than in the packages. The concern is being the last institution on a package when the people who knew it have moved on. Recommendation: treat both as migration sources, plan the move within the next planning cycle, and use the kit's mapping as the starting inventory. Decide which package moves first based on which office has the quieter season. The migration page covers both.

The kit moves data. It is a set of unmanaged packages and Data Processing Engine definitions, run in clusters, that transform EDA, Admissions Connect, and Student Success Hub records into Education Cloud objects, converting accounts and contacts to Person Accounts along the way, within the same org or into a new one. It does not move custom code, Flows, reports, dashboards, page layouts, permission sets, or integrations, and it does not redesign anything you modeled badly the first time. The concern is institutions that schedule the kit's run time and forget the metadata rebuild around it. Recommendation: inventory custom metadata before touching the kit, and decide what not to rebuild. Salesforce documents the kit at Migrate Your Data to Education Cloud; the data migration checklist covers the rest.

Yes, and each in a different way. Banner and Colleague expose supported APIs through Ellucian's integration layer; Jenzabar institutions often work through staging tables and scheduled jobs; PeopleSoft Campus Solutions usually goes through the campus integration team's existing middleware. The common rule is that Education Cloud is the system of engagement and the SIS stays the system of record, integrated only through supported interfaces and never by direct database writes. The concern is ownership: an integration with no named campus owner is the most frequent cause of a slipped go-live. Recommendation: name the integration owner at kickoff, and decide which direction each record flows (inquiry to SIS, admitted student to SIS, enrollment from SIS) before design. The SIS integration patterns article compares the options by system.

Education records in Salesforce are covered by the institution's FERPA obligations, so the question is not whether FERPA applies but how the org enforces it. The tools are standard: organization-wide defaults and sharing rules decide which staff see which learners, field-level security hides sensitive fields from roles that do not need them, and Experience Cloud portals are scoped so a learner sees only their own records, with Delegated Access covering parents and proxies. The concern is sharing models designed for a sales team and never revisited. Recommendation: have the registrar sign off on the sharing model as a deliverable, and audit it each release. Decide who the FERPA reviewer is before design begins. The data migration checklist includes the security model steps.

Four roles, and they can be part-time but not absent. A sponsor with authority to decide process questions within a week. A product owner from the business unit who attends every design session and owns user acceptance. A Salesforce administrator who will run the org afterward and therefore learns it during the build. A data and integration lead who can answer for the SIS. The concern with skipping the administrator is a go-live followed by a support contract nobody budgeted for. Recommendation: name all four before kickoff and put their time in the project charter. Decide whether the administrator is hired, reassigned, or augmented by the end of discovery. The how we deliver page describes how we work with each role.

The institution does, from the first day, and the build should assume it. Ownership means the administrator can explain every Flow, the permission sets are documented, the decision log says why each custom field exists, and the partner's access can be removed without anything breaking. The concern is the alternative: a storefront or admissions org that only the vendor understands, which is a dependency rather than a system. Recommendation: build on standard objects and Flow so the org is readable, include a recorded handover, and keep the partner on a retainer for releases rather than for operations. Decide the post-launch support model when the statement of work is signed. The standard objects first article explains why readability is a governance choice.

Standard-first is the rule that an implementation uses Salesforce's standard Education Cloud objects and fields whenever one fits, adds custom objects and fields only with a written reason, puts automation in Flow and Platform Events, and writes Apex only where the platform requires it. It matters because every custom object is something the next administrator must learn, every Apex class is something to retest each release, and Salesforce's new features, including Agentforce for Education, assume the standard model. The concern is the opposite habit: rebuilding the old system's tables inside Salesforce. Recommendation: make the written reason a required field in the design review. Decide the rule at kickoff, before the first design session. The standard objects first article lists what we refuse to customize.

User acceptance testing is where the business unit proves the system does its job, so the unit writes the scripts, not the partner. Each script is a real task in the unit's own words, with real data from the migration, a named tester, and a pass or fail recorded against it. Run two or three cycles a week apart in a sandbox with migrated data, triaging defects daily into fix now, fix after launch, or not a defect. The concern is UAT compressed into the last week, when every finding becomes a go-live risk. Recommendation: schedule UAT for at least three weeks. Decide the acceptance criteria and the person who signs before UAT starts. The UAT and go-live article includes a script template.

One row per decision, kept from discovery through handover: the date, the question, the options considered, the option chosen, the reason, who decided, and what it would take to reverse it. Typical entries are the Person Account matching rule, the refund policy, whether noncredit enrollments post to the SIS, and which fields are custom and why. The concern with not keeping one is that the same question is reopened by each new stakeholder, and the org's design looks arbitrary to the administrator who inherits it. Recommendation: make the log a living document the product owner maintains. Decide its owner on day one and store it where the administrator will find it in three years. The data migration checklist shows which decisions the migration itself forces.