Product guides
Rollout timeline for school management, ERP, and SIS
A practical school management software rollout timeline built around discovery, data readiness, configuration, testing, training, support, calendar constraints, and go-live evidence.
Define the timeline from the outcome
A rollout timeline should begin with the workflow the school intends to operate, the date it must be dependable, and the evidence required to release it. A list of vendor activities is not enough. The school must know what it has to prepare, test, approve, communicate, and support.
State the phase-one boundary and the conditions that hold or narrow launch. Include the academic calendar, admissions periods, reporting, fee cycles, staff absence, family communication, and other operational peaks.
Phase 1: discovery and ownership
Name the decision maker, workflow owner, data owner, access owner, implementation lead, training owner, support route, privacy adviser, and security adviser. Map the current process, source records, exceptions, dependencies, and desired result.
End discovery with an agreed process map, data inventory, role matrix, acceptance tests, risk register, communication plan, and list of unresolved assumptions. If the team cannot define the workflow, the timeline is not ready.
Phase 2: data readiness and design
Profile a controlled sample for duplicates, missing values, stale relationships, inconsistent dates, unclear ownership, and fields that should not move. Define the source of truth, mapping, validation, correction, archive, export, and retention rules.
The U.S. Department of Education data-quality guidance emphasizes business rules, validation processes, infrastructure, and professional learning. Build those activities into the schedule rather than treating clean data as an assumption.
- Data inventory and approved field list
- Role and permission design
- Workflow and exception mapping
- Migration sample and reconciliation
- Privacy, security, and supplier review
Phase 3: configuration and integration
Configure the bounded workflow and identify what is native, configured, integrated, manual, roadmap, or unknown. Test identity matching, permissions, dates, approvals, publishing, exports, notifications, and reconciliation with controlled data.
Do not compress integration and exception work into a final technical day. A successful exchange is only one result; the school also needs timeouts, partial writes, duplicate messages, stale values, and recovery paths.
Phase 4: acceptance and training
Run role-based acceptance tests with the people who will operate the workflow. Include the normal path, correction, absence, permission denial, family view, support escalation, and reporting or financial handoff. Record evidence and unresolved defects.
Training should use realistic scenarios and explain the expected result, correction route, escalation boundary, and support context. Ask users to perform the task rather than only attend a presentation.
Phase 5: go-live and stabilization
Go live only when data, permissions, support, communication, monitoring, and rollback or hold criteria are ready. Keep a controlled temporary route for critical work and reconcile it later. Do not allow urgency to erase access or audit requirements.
Review at 30, 60, and 90 days using correction loops, workflow completion, support questions, access exceptions, data quality, family experience, and the original outcome. Expand when evidence supports it; hold or narrow when it does not.
Make the timeline honest
GOV.UK procurement guidance recommends early attention to responsibilities, data protection by design, access control, security, subprocessors, incident notification, and end-of-contract data handling. Include these dependencies in the schedule and assign their owners.
A credible timeline shows school effort, decision gates, evidence, dependencies, and buffer. It is not less ambitious because it contains a hold rule; it is more useful because the school can operate it safely.
Show the handoff between phases explicitly. Discovery does not end when a meeting ends; it ends when owners accept the process map and tests. Testing does not end when a script runs; it ends when the affected users review the result and the decision maker accepts the remaining risk.
