Skip to content
Choosing an SMS2 min read

Switching student management systems without losing your history

A practical migration sequence (students, enrolments, results, notes, CRICOS and PRISMS history) with dry runs, de-duplication and undo.

The biggest reason providers stay on a system they’ve outgrown is migration risk. Years of enrolments, results, notes and compliance history feel too valuable to move. That’s reasonable: a migration that loses history or creates duplicates can do real damage.

This guide describes how Academywise’s Data Migration Hub approaches the problem.

Supported sources

The hub reads:

  • aXcelerate CSV exports
  • Meshed CSV exports
  • AVETMISS NAT files: NAT00080/85 (clients), NAT00120 (enrolments) and NAT00130 (completions)

aXcelerate and Meshed are trademarks of their respective owners. Academywise reads their standard export formats and isn’t affiliated with either.

Import in a deliberate order

Each import handles one record type. The recommended sequence is:

  1. Students
  2. Enrolments
  3. Unit results
  4. Notes and interventions
  5. CRICOS details: CoE, passport, visa, OSHC
  6. PRISMS history

Running them in order means each later import can match records created by the earlier ones.

Always dry-run first

Every import can run as a dry run. You see how many rows were parsed, how many matched existing records, how many would be created, and a list of issues, all before anything is written. Fix the issues in your export, run again, and only then import for real.

How duplicates are avoided

Students are matched against existing records by USI, student number, email plus date of birth, or legacy source and ID. Re-running an import matches the records it created last time instead of creating new ones.

Legacy student IDs are kept on the student record. They’re shown in the profile header, searchable from Enrolments, and accepted (with date of birth) on the public payment page, so students and staff can keep using the numbers they know.

Formats are normalised for you

Dates in Australian, ISO, NAT or Excel serial formats are normalised automatically. Outcome codes such as C, NYC, W, RPL and CT are mapped to AVETMISS outcomes 20, 30, 40, 51 and 60.

Notes keep their meaning

Imported notes keep their original timestamps and author labels. Notes that look like warnings, at-risk flags, attendance or progress concerns, show-cause or NOIC records are classified into interventions with a severity level. Everything else goes to the communication log.

Undo is built in

Every batch is logged with the rows it created. Undo deletes only what that batch created, and for CRICOS imports it restores any fields the batch overwrote. Blank cells never overwrite existing values in the first place.

Who can run it

The migration hub is restricted to super administrators, and every batch, including dry runs, is recorded in the migration log.

This guide describes how Academywise works and is general information only. It isn't legal or compliance advice. Always confirm your obligations with the official sources linked above.

Keep reading

See Academywise with your own workflows in mind

Book a guided demo. Tell us how you run admissions, delivery and compliance today, and we'll show you the parts of Academywise that matter to you.

  • Walkthrough tailored to your modules
  • Discuss migration from your current system
  • Clear status on every feature