Quran Academy Software Implementation Checklist: From Records to Go-Live

A Quran academy software implementation should move through clear evidence gates: ownership, scope, data preparation, configuration, testing, training, approval and first-cycle review. Do not begin by uploading every record you can find. Begin by deciding what must work on the first useful day and who is authorised to approve it.

Still evaluating products? Start with the guide to choosing Quran academy management software. This article begins after the academy has identified a likely system and needs a controlled rollout plan.

1. Name the people who own the implementation

Choose one implementation owner who can resolve priorities and keep the decision record. Then name the people who understand admissions, teaching, scheduling, learner records, reports, fees and access. A vendor can configure a system, but it should not decide which conflicting academy record is correct.

2. Define the first useful day

“Move everything” is not a testable objective. Describe what an administrator, teacher, parent and learner must be able to do on the first useful day. Keep phase one small enough to test completely.

• Administrators can review accepted learners, guardians, teacher assignments and schedules.
• Teachers can find today's classes and record attendance and lesson evidence.
• Parents or adult learners can access only their authorised records.
• The academy can distinguish a held class from learner absence, teacher absence or cancellation.
• Named staff know where to get support and what to do when a record is wrong.

Use the complete academy operating workflow to map enquiry, enrolment, scheduling, teaching, reporting and review before deciding which stages belong in the first release.

3. Inventory and protect the source records

List every place that currently holds an academy record: paper registers, spreadsheets, form responses, exported chats, payment records, personal notebooks and a previous system. For each record type, name the authoritative source and the person allowed to resolve conflicts.

1. Create a source register containing the record type, location, owner, format and date range.
2. Preserve an untouched, dated copy of the records approved for the project.
3. Restrict the working copy to the people who need it.
4. Never place passwords, meeting secrets or unnecessary safeguarding narratives in a migration sheet.
5. Agree how working files will be transferred, retained and removed after acceptance.

The Nigeria Data Protection Act 2023 regulates personal-data processing in Nigeria. This checklist is operational guidance, not legal advice; obtain appropriate advice for the academy's privacy, safeguarding and retention obligations.

4. Clean and map a working copy

Clean a working copy, never the preserved baseline. Standardise formats without silently changing meaning. A guardian relationship, teacher assignment, learner status or payment state should change only through an authorised decision that can be explained later.

5. Configure the academy before loading live records

Configure the meaning around the records first. A learner schedule cannot be checked properly until operating days, timezones, teachers and holidays are known. A report cannot be approved until the academy has agreed its assessment and approval rules.

• School identity, contact details, timezone, operating days and calendar.
• Quran, Arabic and Islamic Studies programmes and the class formats actually offered.
• Teacher responsibilities, one-to-one and group scheduling rules, and meeting-link process.
• Attendance values, missed-class categories and who may make an authorised correction.
• Lesson-record expectations, ratings, feedback and parent-reporting process.
• Report-card templates, grading choices and approval responsibilities.
• Family fee settings, reconciliation responsibilities and escalation rules.
• Role permissions and the minimum access each person needs.

For Nigerian pricing, WAT scheduling and payment considerations, use the Nigeria-specific Quran school software guide.

6. Load foundation records in dependency order

Relationships determine the order. Create the academy configuration and authorised staff first. Then add learners and guardians, teacher assignments, recurring schedules and group membership. Add selected history only after the current relationships work.

1. Academy configuration, roles and authorised staff.
2. Fictional pilot learners and guardians.
3. Teachers, assignments and one-to-one schedules.
4. Group classes and per-learner membership.
5. Current operational records required for launch.
6. Only the historical records with an agreed purpose, source and validation method.

Do not assume that every source field belongs in the new system. Decide whether old records will be migrated, retained in a controlled archive or excluded under an authorised retention decision.

7. Test complete workflows with fictional accounts

A screen opening successfully is not acceptance. Run complete scenarios from one role to the next and inspect the resulting history.

Use the existing admissions and trial workflow, Quran progress workflow and session audit template as detailed acceptance references.

8. Test access boundaries deliberately

Use fictional accounts for every role. Confirm that a teacher cannot open an unassigned learner, a parent cannot open another family's child, a student cannot open another learner, and one academy cannot read another academy's records. Also test empty states: an academy with no assigned learners or teachers should not inherit classes, calendars or records from anywhere else.

Record who performed each access test, what account was used, the expected result and the actual result. A failed isolation test is a stop condition, not a cosmetic defect.

9. Reconcile records and obtain acceptance

Compare the agreed source and target by record type and status. Then inspect representative learner-guardian relationships, teacher assignments, schedules, group memberships, progress history and fee states. Keep an exception list with an owner and decision for every material mismatch.

• Counts match the agreed scope by active, paused and archived status.
• Stable identifiers and names point to the intended person.
• Guardian, teacher, group and schedule relationships remain correct.
• Historical entries retain their date, meaning and authorised source.
• Every material exception is corrected or accepted by a named owner.

10. Train people by the tasks they perform

Do not call a general demonstration training. Give each role a short set of realistic tasks and ask them to complete those tasks on the device they will normally use.

• Administrator: approve intake, assign a teacher, review exceptions, release a report and reconcile a fee.
• Teacher: find today's class, record attendance and lesson evidence, manage a group and respond in chat.
• Parent: switch between linked children, check progress, open a report, find a fee invoice and contact the teacher.
• Learner: find the next class, review feedback and complete the permitted follow-up task.

Al-Ibiewi's current video tutorials can support task-based practice, but the academy should still confirm that each person can complete their own responsibilities.

11. Use a written go-live gate

Choose a date that avoids an avoidable admissions, reporting or fee-collection peak. Before activation, record a go or no-go decision against evidence—not optimism.

12. Review the first full operating cycle

Implementation does not end when accounts are activated. Review the first complete admissions, teaching, reporting and fee cycle. Look for missing records, repeated support questions, incorrect permissions, unresolved exceptions and tasks that still happen in an unofficial spreadsheet or chat.

Assign every defect or improvement to an owner. Update the academy's procedure and training material after the correction. Decide separately when old source copies may be archived or removed; go-live alone is not a deletion instruction.

How Al-Ibiewi supports the rollout

Al-Ibiewi LMS currently connects applications, learner and guardian records, teacher assignment, one-to-one and group schedules, attendance, Quran and subject progress, chat, monthly reports, report cards, school calendars and parent fee collection. Role-specific dashboards and tenant boundaries keep each academy and authorised role within its permitted records.

The platform does not decide which source record is correct, replace the academy's policy decisions, assess Tajweed automatically or host live video. Agree the migration method and scope before sending records; do not assume a bulk-import feature or upload personal data through an informal channel.

Your next step

Download the implementation checklist, name the owner and complete the scope and source-register stages before moving any live records. When you are ready to test the workflow, apply to use Al-Ibiewi or ask an implementation question.