A school software onboarding checklist

Who owns the rollout, and what is in scope?

Appoint one accountable school owner and a small decision group covering teaching, administration, data and technical operations where relevant. Then write the first release down in terms anyone can check:

• Named users, locations and year groups in the first release.
• The workflows, data categories and dependencies in scope.
• What is out of scope, so a late request cannot quietly widen the pilot.
• Success criteria, each with an owner, a measurement method and a decision date.

Define success as evidence rather than a promised outcome: a named task completed, access kept within the approved matrix, an import reconciled, a support case resolved, an agreed export produced. If the owner cannot sign off these lines, the rollout does not proceed to phase 2.

Which product and service claims are confirmed before setup?

Build a claim register from the proposal, contract, demonstration notes and support documents. Give every claim one status, and record the product, package, version, evidence date and source beside it.

ConfirmedExcludedDependentPlannedUnresolved

If a workflow depends on another system, licence, device or service, write the dependency next to the claim, not in a footnote. Only confirmed claims move into setup. Dependent claims wait until their dependency is confirmed; planned and unresolved items stay out of training and out of the pilot script. Easy Edu’s questions to ask in a school platform demo produce most of this register.

Why be this strict? A licence count is not a rollout; only confirmed claims can be trained and tested.

How should the school prepare data before import?

List the data the approved scope needs, with its source, owner, quality checks and transfer method. Import nothing beyond that list. Before the first transfer, work through these checks:

• Remove duplicates and correct known errors at the source.
• Agree the identifiers that will match people across systems.
• Import a small test set first, then reconcile record counts and key fields.
• Record rejected rows and why they failed.
• Rehearse how the school would restore or correct a wrong import.

Document the purpose, access, retention, export and deletion path for each important data category. Malaysia’s Personal Data Protection Department publishes seven personal-data-protection principles and six data-subject rights in its public FAQ as general context; take advice on the actual arrangement rather than treating a checklist as a legal ruling.

How are roles and accounts configured and tested?

Approve a role-by-action matrix before inviting anyone beyond the project team. Then create representative accounts for each role and run the same four account tests against every one, checking both the allowed and the refused actions for viewing, editing, approving, downloading and sharing:

1. CreateSet up a user with the minimum access the role needs, and confirm what they cannot open.
2. ChangeMove a user to a new role or class and confirm the old access has gone.
3. RecoverRestore a lost sign-in through the school’s approval route, not around it.
4. CloseRemove a leaver while keeping any record the school must retain.

Include administrator delegation and temporary access. Save the configuration and each result with the onboarding record. Easy Edu’s guide to evaluating teacher, student, parent and administrator access has the full matrix.

What should a limited pilot test?

Choose a small group, such as one class or one department, and a fixed period with a stated end date. Give participants named scenarios rather than open access, and record the device, connection, role and configuration for each so a result can be interpreted rather than reduced to “worked” or “did not work”.

1. Routine taskComplete a routine task for each role in scope.
2. CorrectionCorrect an error and confirm who approved the change.
3. Role changeChange a user’s role mid-pilot.
4. Help requestRequest help and time the response.
5. ExportExport a sample and check what came out.
6. Planned failureHandle a planned failure, such as an interrupted connection.

Set entry, stop and exit criteria before day one: who can pause the test, how issues are prioritised, which defects block broader use and how sample or real data is handled when the pilot closes.

What training and communication does each audience need?

Train people on the tasks and limits confirmed for their role, and never train a planned workflow as if it were released.

Give each audience a short practice task and a way to report problems. Attendance at training does not prove competence or adoption.

What must be handed over before broad launch?

Launch day is the wrong time to discover who answers the phone. Collect these in writing, and treat any unwritten support expectation as open rather than part of the service:

Support

Hours, channels, escalation owner and any response commitments.

Change

Maintenance and release notices, and the school owner for configuration changes.

Known limits

Defects accepted at pilot close, each with an owner and review date.

Export

The agreed export run for real, with the output checked.

Exit

Retention and deletion answers, and the end-of-service path.

Name who will read new release notes after launch, and set the date when the school will next revisit the claim register from phase 2. Keep the export result and the exit path with the handover record. Easy Edu’s school data ownership, export and deletion questions set out what to ask for.

What does the complete onboarding checklist look like?

Use this as the sign-off sheet. Tick a line only when its evidence is filed with the onboarding record, and stop at the first line that cannot be ticked.

The downloadable worksheet carries the same phases with space for owners and evidence.