How to Migrate Off a Legacy SIS Without Downtime

You migrate off a legacy SIS without downtime by never flipping a single switch. Instead you run the new system alongside the old one, prove that the migrated data reproduces your legacy numbers exactly, and only then move day-to-day work over, with the old system still readable as a fallback. Downtime and data loss come from big-bang cutovers done on faith. A parallel run done on proof removes both. The three steps below are the whole method.

The mindset that makes it safe: a migration is not a copy, it is a reconciliation. You are not done when the data moves; you are done when the new system independently produces the same balances, GPAs, and rosters the old one did.

Step one: extract and map, with provenance

Pull the legacy data and map every entity (students, enrollments, ledger entries, awards, attendance, grades) into the new model, and stamp each migrated row with where it came from: the legacy id, the legacy source, the legacy account. Provenance is not bookkeeping vanity. It is what lets you trace any number in the new system back to its origin when someone asks "where did this balance come from," and it is what makes the next step possible.

Step two: reconcile to the penny, as a release gate

This is the step everyone skips and everyone regrets. Before cutover, the new system must recompute the facts that matter, student balances, GPAs, SAP status, roster counts, aid awarded and disbursed, the 1098-T boxes, and match them against the legacy values within tolerance: balances penny-exact, GPA to the decimal, statuses exactly. Critically, the new system should produce these numbers by running its own live engines, not by copying the old answer, because that is the only way you prove the engines are correct and not just the data. A migration that has not reconciled is a migration that has not happened.

Step three: parallel run, then cut over with a rollback

Run both systems for a real period. Enter the day's work in the new one, keep the old one readable, and compare. When the numbers hold across a full cycle and the team trusts the new screens, you cut over to daily use, with the legacy system still available read-only as your rollback. No midnight switch, no week of frozen operations, no praying the import worked.

How ApolloSRM does this

ApolloSRM ships migration as a reconciliation discipline, not a one-way import. Every migrated row carries its legacy id and source. A reconciliation harness recomputes balances, GPAs, SAP status, roster counts, awards, and 1098-T boxes through the same live engines your staff will use, then diffs them against your legacy baselines with penny-exact tolerances and gates the cutover on a clean run. There is even a dry-run that rehearses the whole extract-reconcile pipeline end to end before a single real record moves. The goal is the same every time: you see the difference before you trust the system, and you keep the old one until you do.

Frequently asked questions

How do you migrate to a new SIS without downtime?

Run the new system in parallel with the old one rather than doing a single cutover. Migrate and map the data, reconcile the new system's numbers against the old ones, run both side by side for a full cycle, then move daily work over while keeping the legacy system readable as a rollback.

How long does an SIS migration take?

It depends on data complexity, but the controllable part is the parallel run, usually at least one full operational cycle (a term or payment period) so balances, aid, and rosters can be reconciled under real conditions before cutover. The reconciliation, not the data copy, is the long pole.

What is the biggest risk in an SIS migration?

An unreconciled cutover. If you move data and assume it is correct without independently recomputing balances, GPAs, and aid through the new system, errors surface after go-live when they are hardest to fix. Reconciliation to the penny before cutover is the safeguard.

Can you keep your old SIS during migration?

Yes, and you should. Keeping the legacy system readable during the parallel run and immediately after cutover gives you a rollback and a reference, which is what makes a zero-downtime migration possible.