Anthology Student consulting
Hands-on help with Anthology Student (formerly CampusNexus and CampusVue) from someone who has worked in it since 2007, first as a user and then building on it.
Student data migration and conversion: Move the data once, and be able to prove it
Migrations and conversions for student, academic and financial aid data. Rehearsed in test, safe to run again, and verified record by record before anyone signs off.
The problem
A migration is the one project where being 99 percent right is a failure. The missing one percent is a student whose award is on the wrong term, a transcript with a course missing, or a ledger that no longer balances. It surfaces weeks later, in front of the student.
In my experience, most migration trouble comes from three habits: running it once and hoping, checking a sample instead of everything, and fixing problems by hand so that nobody can say afterward exactly what was changed.
What I do
- Whole-population migrations. Student, academic, document and financial aid data, moved through the student system’s supported interfaces.
- Check first, change second. Every run has a check-only mode that reports what it would do. You approve that report before anything is written.
- Safe to run again. If a run stops halfway, or a late batch of records arrives, the same command is run again. It changes only what still needs changing.
- Proof for every record. Each record gets a before-and-after entry. The result is checked three ways: through the system’s interface, in the database, and by validator reports your staff can run for themselves inside the student system.
- A track record you can read. A full document-set migration delivered on deadline with zero defects, verified record by record before sign-off, is written up in this document migration case study.
I do this work mostly on Anthology Student (formerly CampusNexus and CampusVue, now an Ellucian product), and also on Thesis Elements.
Financial aid is its own discipline
Title IV data is where a migration mistake becomes a federal compliance problem. I have built a migration engine for exactly that data, described in the financial aid migration case study. I was also a financial aid administrator before I was an engineer, so I know what the aid office will look for the morning after.
How it runs
- Read. I study the source and target data as they really are, not as the documentation says.
- Rehearse. A full run on a copy, with the check-only report and the evidence pack.
- Review. Your staff look at real results and tell me what the rules missed.
- Cut over. The rehearsed run, applied by a person, with verification before and after.
- Hand off. The evidence, the runbook, and the ability to run it again.
Self-check
Is your data migration ready?
Eight yes, no or not sure questions to answer before a student data migration, each with one line on why it matters. The answers score into one of three bands, with the pages on this site that speak to the gaps. It runs in your browser and sends nothing anywhere.
Nothing leaves your browser. The scoring runs on this page, and no answer is sent or stored anywhere. These are eight general good-practice checks to answer before a student data migration, not a description of any one school.
What drove this result
Show the text that will be copied
Your answers stay in this browser tab. The Copy button puts the text on your clipboard for you to paste wherever you choose, such as a message to Zak through the contact page. This page sends nothing on its own.
How the score reads
Ready
The habits that make a migration safe to run are in place: a rehearsal on a fresh copy, a report of what would change, a person who signs off, and evidence you can show afterward. Treat each not sure as a small task to settle before the production run.
Worth a look
Nothing here means stop, but a few gaps are the kind that turn a cutover into a long night. The answers listed with the result are the ones to settle first, ideally before the production run is scheduled. Most close with a written rule or a rehearsal.
At risk
Several answers, or several not sures, point at a migration that would be tried for the first time in production. That is common when a move is planned late, and it is fixable. Start with a rehearsal on a fresh copy and a check-only report, then agree who signs off before a date is set.
Where the fixes live
- How the data migration service runs: read the data as it is, rehearse on a copy with a check-only report, review the results with your staff, cut over with a person applying the rehearsed run, and hand off the evidence.
- The seven questions to ask before a student data migration: plain questions to put to anyone about to migrate your student data, and what a good answer sounds like.
- The document migration case study: a full document set rehearsed first, then verified record by record against its source before sign-off.
- The financial aid migration case study: a check-only run, a second run that finds nothing left to change, and before-and-after evidence for each student.
Show how the score is worked out
Each question has a good answer. The other answer is the risky one and scores the question's weight: 4 safeguard questions (the check-only run, the written rules, the sign-off, and the restore plan) score three points each, the rest score two. Not sure scores one point, and a question left blank counts as not sure. 2 points or fewer reads Ready; 3 to 7 reads Worth a look; 8 or more reads At risk, out of a possible 20. The answers that scored are listed under the result, risky answers first, then the not sures.
Common questions
Questions people ask
What happens if a migration goes wrong halfway through?
It is designed to be run again. A run that stops partway is restarted and changes only what still needs changing. You can try a small working model of that in the financial aid migration case study.
Can you work in our test environment first?
Yes, and I would rather not work any other way. I build in your test environment in small steps, each with evidence that it does what it should. A migration is rehearsed on a copy of your data, with a check-only run that lists what would change before anything does. Production changes are rehearsed first and applied by a person, so the real run is not the first time the work has been tried. See data migration.
How do you handle student data?
As little of it as the job needs, inside your environment wherever possible, under a written agreement, and not by email. The details are on the security and data handling page.
Other services
SIS integration
Connect your student system to everything around it, as changes happen, with a record of every change.
Reporting and dashboards
SSRS reports and Power BI dashboards your staff trust, including Crystal Reports rebuilt for the web client, by someone who has used those reports.
Financial aid automation
Automation around financial aid data, built by a former aid administrator, with the evidence an auditor asks for.
Workflow automation
Take the manual steps out of admissions, registrar, aid and finance work with Workflow Composer and FormsBuilder, inside the system your staff already use.
Applied AI
Put AI agents to work on real operational tasks, with the controls and the audit trail a college needs.
Managed hosting
Nowhere to run an integration? I host and maintain it on Azure, in your subscription or a dedicated one.
All services
The full list, and the three ways an engagement can run.
Have a system that needs untangling?
Tell me what you run and where it hurts. The first call is 30 minutes, free, and you will leave with a clear next step whether or not we work together.