The Meeting Where Good Ideas Stop
The registrar’s office has a problem. Transfer evaluation is slow, the backlog grows every peak season, and skilled staff spend their days re-keying coursework. So someone finds a promising solution and brings it to IT.
Then the question arrives. How does it connect to Banner? Or PeopleSoft, or Workday, or Colleague.
The conversation then stops, and not because IT is being ‘difficult’. The last migration took years, the budget is spent, and nobody wants another one. The SIS is stable, and stability is worth protecting.
So, the transfer problem stays where it is, and everyone agrees to look at it again next year.
Four Degrees of "It Integrates"
The answer to that meeting is not complicated. You add capability at the layer where the work happens, the system of record stays exactly what it was, and your rules, records, and academic history stay authoritative where they are. The difficulty is that a great many systems describe themselves that way, and the phrase alone will not tell you which one you are being shown. Here are four things it can mean, in rough order of how much manual work each removes.
Screen automation. A bot navigates your SIS interface and types the way a person would. Architecturally it changes nothing, which is the appeal. It also breaks when the interface changes and usually needs someone watching it.
Scheduled file exchange. Data moves as flat files on a schedule. Reliable, and often the right answer for reporting. For evaluation work it adds delay, and someone still owns the error report when a file partially fails.
Read-only integration. The system pulls data out of the SIS, processes it, and shows you a result. Then a person keys that result back in. This is the one that would have sailed through that meeting, because in a demonstration extraction and update look identical. Extraction is automated. The part where the record actually changes is not, and roughly half the manual work survives.
Real-time write-back. Verified results are written into native tables as the work happens, with no re-keying. And because the write happens in real time rather than on a schedule, its result comes back in the same moment: if something needs fixing, it surfaces then and there, while the person still has the source in front of them, rather than turning up later in an error report to reconcile. This is the threshold where manual entry disappears rather than moving somewhere else.
Past that threshold, integrations differ in how much they read back from you. Some push finished results in. Others also pull your equivalency rules out, so those rules apply before anyone opens a record. That second kind is bi-directional, and it matters if you have a substantial rules library. Both get described the same way, so ask which is in front of you.
The Questions That Change That Meeting
These are worth asking of any prospective partner, including us:
- Where do verified results land? If the output arrives on a screen or in a report rather than in the system of record, someone on your team is still typing it in.
- When the work is done, where does the authoritative record live? If the answer is the partner’s platform, you now have two systems of record and a reconciliation job you did not have before.
- Native tables, or a parallel store you will have to sync? The second creates ongoing work that rarely appears in a proposal.
- Does it update the existing student record, or create a new one? An integration that inserts rather than matches produces duplicate academic histories. Ask to see what happens when the same student’s second transcript arrives.
- What happens at our next SIS upgrade or patch? Ask specifically what broke at other institutions during their last upgrade cycle, and how long it took to resolve.
When Migration Really Might Be the Answer
This argument has a limit. If your SIS is end of life, unsupported, or no longer fits how your institution operates, layering capability on top is a new roof on a condemned building. Integration extends the life of a system that works. It does not rescue one that does not.
The question is whether the SIS is the problem, or whether the manual work around it is. For most institutions we talk to, it is the second. And a migration on the horizon is a reason to act sooner, not later: a layered integration is repointed to the new environment rather than rebuilt, and your rules and logic carry over.
The Solution: Add a Layer, Not a System
This is the principle the Student Mobility Suite is built on. Transcripts are structured and your own equivalency rules applied before anyone opens a record, and once verified and pushed, the results are written into the tables your staff already trust. Your system stays the system of record, and nothing is rehoused.
The Takeaway: Protecting the SIS is Not the Same as Doing Nothing
Caution about the system of record is good judgment, not resistance to change. The question was never whether to modernize. It was at which layer. When someone brings another solution proposal into your meeting, establish where the source of truth sits once the work is done. If it is still your SIS, nothing is migrating. Your team is doing less manual work, and more of the work only they can do.