Skyward to PowerSchool: A Methodical SIS Migration for a 1,900-Person School
Situation
The American International School of Riyadh had been running Skyward as its student information system for years. It worked, in the sense that student records were in it. It did not work, in the sense that the rest of the school had outgrown what Skyward could do as a hub. Scheduling was fragmented. Reporting required exports and spreadsheets before anyone could make a decision. The integrations we needed downstream — identity through ClassLink, finance and operations through Odoo, payments through Zenda — were harder to attach to Skyward than they needed to be.
We made the decision to move to PowerSchool SIS. The forcing factors were straightforward: we wanted unified reporting and scheduling across the whole school, we wanted a SIS that accredited international schools in the region were already on so that staff mobility worked in our favour, and we wanted a platform whose integration surface matched the stack we were building around it. I led the implementation solo, covering 300+ staff and 1,600+ students.
Action
I broke the work into four layers: data, identity, academic operations, and communications. Each one had to land cleanly before the next one could be trusted.
Data came first. I pulled full exports out of Skyward — students, parents, staff, enrolments, schedules, historical grades, attendance, disciplinary records. The raw exports were not importable as-is. Field names did not line up, code tables did not match, and there were years of accumulated drift: duplicate parent contacts where remarriages had been handled inconsistently, students with multiple active records from re-enrolments, staff who had left but had not been closed out. I wrote mapping scripts that normalised the exports into the PowerSchool import templates, then ran correction passes — dedup on parent contacts keyed on email and phone, reconciliation of student IDs against historical records, and validation of enrolment start and end dates against the school calendar. I imported in stages: students and parents first, then staff, then historical academic records, so that any failure was contained to one layer.
Identity was next. ClassLink became the single point of truth for authentication. I configured SAML between ClassLink and PowerSchool, set up rostering through OneRoster so that class lists flowed from PowerSchool down to the instructional tools teachers actually used, and tested the login path for each user class — admin, teacher, parent, student — before any of them saw it.
Academic operations was the part where a migration either earns trust or loses it. I rebuilt the master schedule in PowerSchool rather than trying to import Skyward's schedule wholesale, because the old schedule encoded old constraints I did not want to carry forward. Grading scales, GPA calculations, and report card templates were rebuilt from the curriculum up. I ran a parallel reporting cycle — generating a set of report cards out of both systems for the same cohort — so that when discrepancies showed up I could trace them to a specific rule rather than a mystery.
Communications ran alongside all of it. Parents at an international school expect to be told what is happening and when. I published a cutover timeline, sent targeted messages to the groups who would see changes first (teachers needing to learn the new gradebook, parents needing to re-bookmark the portal), and kept the old Skyward portal reachable in read-only mode for a defined window after go-live so that anyone who needed an old document could still get to it. That read-only bridge is not glamorous, but it took a huge amount of anxiety out of the cutover week.
Outcome
PowerSchool went live across the school with the full population — 300+ staff, 1,600+ students, and the parent community behind them — on the planned cutover. Reporting and scheduling consolidated into a single system, which meant leadership stopped reconciling spreadsheets before meetings and started making decisions from live data. Downstream integrations attached cleanly: Odoo picked up student and family records for finance workflows, ClassLink became the single sign-on surface for the whole stack, and Zenda handled payment flows tied to the new student IDs.
The quieter win was that the migration set the table for everything that came after it. The Oracle Cloud crisis migration a year later was only possible because the PowerSchool footprint had been built clean, with integrations that pointed at stable endpoints and identity that was not tangled into the SIS itself.
Lessons
If I had to tell another school considering this migration one thing, it would be this: the migration is not a technology project. It is a data project with a change-management project wrapped around it. The hard part is not standing up PowerSchool. The hard part is deciding what to carry forward and what to leave behind — which old codes, which dormant accounts, which historical quirks your new SIS should never learn about.
Do not import your mess. A migration is the one moment you have permission to leave it behind, and you will not get that permission again for another decade.
The second lesson is about solo implementations. It is possible — I did it — but only if you sequence the work so that each layer is verifiable before the next one starts. Data, then identity, then academics, then communications. Run them in parallel and you will be debugging four things at once on go-live morning. Run them in order and you will know exactly where to look when something breaks.