What to audit before replacing a school information system

Audit the work, not only the database

A system replacement affects people and routines as much as fields and tables. Interview admissions, teaching, finance, HR, family support, and IT owners. Ask what they enter, what they approve, what they publish, and what they export when the current system cannot answer a question.

Create five inventories

The audit should leave a practical record that the project team can use during vendor evaluation and migration.

• Data inventory: entities, fields, quality issues, retention, and owners.
• Workflow inventory: triggers, handoffs, approvals, exceptions, and deadlines.
• Access inventory: roles, sensitive data, edit rights, and review frequency.
• Integration inventory: payment, identity, messaging, reporting, and exports.
• Outcome inventory: reports, family actions, compliance duties, and term-start tests.

Separate must-preserve from must-improve

Some behaviors are essential even if the current system handles them poorly. Others exist only because a workaround grew around a limitation. Label each requirement as preserve, improve, retire, or investigate. This prevents a replacement project from copying every old workaround into a new interface.

Finish with a migration decision

The audit is useful when it produces a phase-one boundary. Identify the records that must migrate, the records that can be archived, the owners who validate them, and the tests that block go-live. If the school cannot name those owners, it is not ready to promise a migration date.

Ask each owner to sign off on a small representative sample rather than a vague statement that the data “looks right.” Include ordinary records and exceptions. The sample should remain available as a repeatable test when a mapping rule or import file changes.

Record the reason for every field that will not migrate. It may be redundant, obsolete, unsafe to retain, or dependent on a process the school is retiring. An intentional omission is easier to explain and review than a missing value discovered after launch.

Include a list of reports, exports, and family actions that depend on each important field. This connects a data decision to its operational consequence and gives testers a precise way to confirm that a migration did not preserve a field while breaking the work around it.