表格先悄悄地坏，然后才轰然坏掉。

Every agency starts on spreadsheets, and they work. One person, forty students, one file. The failure is gradual and it is not about volume. It is about the day the file is copied - a counsellor takes their own version to work offline, a sub-agent gets a stripped-down copy, someone makes a version for the accountant. From that moment there is no answer to the question "how many students are at the visa stage", only several answers.

The other symptom is that documents and records live somewhere else entirely: a drive, a shared inbox, four phones. The spreadsheet says a student is at the visa stage. What was actually promised to them, and by whom, is in a conversation nobody else can read.

Decide what you are migrating.

Not everything. A migration that tries to bring across five years of history takes four months and stalls. Split the data into three groups and treat them differently.

1. 01Active students. Everyone with a live application or an imminent departure. These must move completely - every document, every note, every commitment made. This is the only group where partial data is dangerous.
2. 02Recent history. Students enrolled in the last year or two, and commission entitlements not yet settled. Move the records that carry an obligation or an expected payment, and summarise the rest.
3. 03Archive. Everything older. Leave it where it is, in a read-only copy with a note saying what it is and how long it is retained. Do not spend migration effort on data you keep only because you have not decided to delete it.

Clean before you move, not after.

Migration is the only moment when someone will look at every row. Use it. Duplicate students under two spellings, students whose status has not changed in two years, entitlements against institutions you no longer work with, files with no owner. Fix them in the spreadsheet first - cleaning is far easier in the tool everyone already knows.

Sequence it around the intake.

Never migrate during a crunch. The window is the quiet stretch after one intake departs and before the next builds - for a September cycle, usually October to December. A migration attempted in June competes with visa deadlines and loses, and the fallback is always the spreadsheet, which means the migration silently fails.

Run one intake in parallel if you can afford the duplication, then stop the spreadsheet on a stated date. Parallel running without an end date is how agencies end up maintaining both systems for two years.

What to insist on from day one.

• Documents attached to the student, with their source and upload date captured automatically rather than typed.
• Counselling notes in the system rather than in a personal inbox, because a note nobody else can read is not a record.
• One definition of each stage, and a dated next step on every active file.
• Commission entitlements linked to the student and the rate that applied, not tracked in a separate sheet that will drift within a month.
• An export you have actually run and opened. Do this in week one, not on the day you might want to leave.

Train on real files, in the quiet period.

Training on demonstration data teaches people the buttons and nothing else. Train each counsellor on their own live students, in the week they migrate them, so the first thing they do in the new system is work they were going to do anyway. Expect the first fortnight to be slower and say so in advance - a team that was promised an immediate speed-up and did not get one concludes the system is bad, when what they met was the ordinary cost of learning anything.

The habit that decides it.

Migrations fail on adoption, not on data. If one senior counsellor keeps a private sheet, the system is already incomplete and every report from it is wrong. That is a management decision rather than a technical one: the record is in the system, and if it is not in the system it did not happen. It is worth saying explicitly, and worth checking a month later.