A Salesforce Education Cloud implementation takes about two months for a fixed-scope accelerator, three to four months for a single-unit storefront in an existing org, nine to ten months for an admissions replacement with an SIS handoff, and a year or more for an enterprise program. ElevateActual sets the date from scope, integrations, and decision timing.
Why Is How Long the Wrong First Question?
The business problem is usually a date that already exists. A vendor contract ends in June. A fall catalog has to be on sale in April. Asked how long the implementation takes, an honest implementer answers with a second question: which of four very different projects is this. The duration of an Education Cloud (Agentforce Education) implementation is set less by the software than by how many systems it has to agree with, how much history has to move, and how many decisions the institution has to make along the way. This page is the companion to our guide to Salesforce for higher education, which covers what each product does.
What Are the Four Scopes?
| Scope | Definition |
|---|---|
| Fixed-scope accelerator | A pre-defined build (Commerce, Recruitment and Admissions, or Student Success) with structured discovery up front and a fixed feature list. |
| Single-unit storefront in an existing org | One continuing education or professional unit selling courses through a storefront in a Salesforce org the institution already runs, with payment, identity, and SIS integration. |
| Admissions replacement off a managed package | Moving recruitment and admissions from a managed package onto standard Education Cloud, with an applicant portal, historical data, and a handoff of admitted students to the SIS. |
| Multi-workstream enterprise program | Two or more of the above under one governance structure, with staged go-lives. |
Fixed-Scope Accelerator: About Two Months
Each of our three fixed-scope accelerators goes from kickoff to live in about two months. The timeline holds because the scope is written before the contract is signed and discovery is structured to fill in the institution's specifics rather than reopen the feature list. The concern: anything outside the list is a second project. If the unit needs a campus payment processor integration on day one, it is not an accelerator. The recommendation is to use the accelerator when the unit can live on the standard list for its first term and add integrations as a planned second phase.
Single-Unit Storefront in an Existing Org: Three to Four Months
A storefront for one unit, built in the org the institution already owns, takes three to four months including integration and a production hot test. The months go to the systems around the build: single sign-on with the campus identity provider, the payment processor's hosted checkout and its security review, the SIS handoff, and a hot test in production with a real transaction before the public link goes out. The concern: central IT owns most of those steps, and its calendar, not ours, is the long pole. The recommendation is to name the campus integration owner at kickoff and put the production hot test on the calendar in week one.
Admissions Replacement off a Managed Package: Nine to Ten Months
Replacing a recruitment and admissions package with standard Education Cloud takes nine to ten months to go-live. The scope includes Person Accounts, programs and terms, IndividualApplication with timelines and decisions, an applicant portal, migration of historical applicant records, and a staging-table handoff so admitted students are not re-keyed into the SIS. Two concerns drive the length. The office is admitting a class on the old system while the new one is built, so the cutover has to land between cycles. And the data cutoff, the date after which no record on the old system is migrated, must be fixed early and defended against the natural request to move it. The recommendation is to work backward from the package contract end and go live one cycle before it.
Multi-Workstream Enterprise Program: A Year or More
When admissions, a storefront, student success, and advancement move together, the program runs a year or more with staged go-lives. The concern is contention: the same registrar, identity team, and data owner are needed by every workstream in the same month. The recommendation is one decision owner per workstream, a shared integration calendar, and go-lives staged so that no two workstreams need the SIS team in the same quarter. A program office that meets weekly and decides, rather than reports, is the difference between twelve months and twenty.
What Makes Each Scope Longer?
| Scope | Typical duration | What makes it longer | What the institution must staff |
|---|---|---|---|
| Fixed-scope accelerator | About two months | Reopening the feature list after discovery; a catalog that is not ready to load | One decision owner in the unit; a catalog owner; one admin to be trained |
| Single-unit storefront in an existing org | Three to four months | Identity provider setup; the payment processor's security review; SIS availability; a central IT change window; a late brand review | An integration owner in central IT; a finance contact for the processor; the unit's catalog owner; UAT testers |
| Admissions replacement off a managed package | Nine to ten months | Historical data quality; a moving data cutoff; the admitted-student handoff; building during a live cycle | An admissions process owner with authority; a data owner; a registrar contact for the SIS handoff; UAT testers per program |
| Multi-workstream enterprise program | A year or more, staged | Contention for the same campus teams; unresolved ownership of shared records; sequencing debates; executive turnover | A program office; one decision owner per workstream; an enterprise architect; the integration team for the whole duration |
What Does a Two-Week Quote Signal?
A proposal that promises an Education Cloud implementation in two weeks is describing something. In our experience it is one of three things. A demonstration org, configured but not integrated, with sample data and no identity, payment, or SIS connection. A scope that quietly excludes everything that takes time: migration, user acceptance testing, training, and the production hot test are "phase two." Or a template turned on with the institution's logo and left for the admin to finish. The question to ask is what is excluded and who does it. If the answer includes identity, payments, the SIS, data migration, or testing with real users, add the months above to the two weeks. Our breakdown of what drives the cost of a Salesforce storefront covers the same exclusions from the price side.
Which Decisions Must Be Made, and By When?
Timelines slip at decision points more often than at build points. These are the decisions with a date.
| Decision | Decide by | What happens if it slips |
|---|---|---|
| Go-live date and the business event it serves | Kickoff | Every other date derives from it; without it the plan is a task list, not a schedule. |
| Data cutoff for migration | End of design | Each week it moves adds a reconciliation pass and reopens the migration scripts. |
| Integration owner on the campus side | Kickoff, named by role and person | Identity and SIS work waits in a central IT queue with no one to escalate it. |
| Payment path (Salesforce Payments or the campus processor) | End of discovery | The processor's security review cannot start, and checkout cannot be tested end to end. |
| Identity model (campus single sign-on, storefront accounts, or both) | End of discovery | The learner matching rule and the portal build both depend on it. |
| Catalog or application content freeze | Two weeks before user acceptance testing | Testers test moving targets and sign off on something that changes again before launch. |
| Training owner and audience | Start of build | Training is squeezed into the week before go-live, and adoption suffers for a term. |
| Who signs off on user acceptance | Start of build | UAT ends without a decision, and go-live becomes a negotiation. |
The UAT and hot test steps are described in our guide to UAT and go-live for a university storefront.
What Do We Recommend?
Choose the smallest scope that serves the business date, and treat everything else as a planned next phase rather than an expansion of the current one. For a continuing education unit that needs to sell a term's catalog, that is the accelerator or the single-unit storefront. For an admissions office with a contract ending, it is the nine-to-ten-month replacement, started early enough to go live a cycle before the contract ends.
Then fix the decision dates above in the project charter, with a name beside each one. The way we run a delivery is built around those dates: structured discovery, design sign-off with the integration owners named, a build with weekly demonstrations, UAT with named testers, a production hot test, and a go-live window between the institution's own peaks. Institutions that make their decisions on time land on these durations; those that defer them do not. More of the questions we hear at this stage are answered in our FAQ on Education Cloud implementation.
Questions We Hear
Can the admissions replacement be done faster if we skip the historical migration?
It can be shortened, and some offices migrate only the current and prior cycle and keep the old system read-only for a year. The concern is reporting: multi-year funnel comparisons break at the cutover, and counselors lose the history of applicants who reapply. The decision belongs to the admissions dean and the data owner, by the end of design.
What does the institution have to do during the two-month accelerator?
Name one decision owner who can answer questions within a day, prepare the catalog or program list in the template we provide, attend structured discovery, review a weekly demonstration, test during a one-week UAT with named testers, and make the admin available for training in the final two weeks. The decisions, the content, and the testing are the institution's, and the two months assume they arrive on time.
Does building inside our existing org take longer than a new org?
Usually a little longer, and it is still the right choice. An existing org carries security review, release management, and sharing rules that a new org does not. In exchange the learner is one record across admissions, the storefront, and advancement. We plan an extra two to four weeks for the existing-org path and recommend it for any institution already running Salesforce.
When should we start if our vendor contract ends in a specific month?
Count backward from one full cycle before the contract end, not from the end itself. For an admissions replacement, that means starting nine to ten months before the go-live you want. Going live the week a contract expires leaves no room for a cutover problem, and vendors rarely extend by a week on request.
What is the biggest single cause of a slipped date?
An integration owner who was never named. Identity, payment, and SIS work sits in a central IT queue with its own priorities, and without a named person on the campus side with the authority to pull it forward, the finished storefront or portal waits. Naming that person at kickoff, by role and by name, is the cheapest schedule protection an institution has.