Full-time architect role
Two AI agents and one audit trail
A second AI agent independently re-checks AI-assisted migration work against the source systems and writes the audit trail, in place of spot checks by hand.
Case study
A financial aid migration you can run twice
Financial aid records for an entire student population had to be migrated, and the result had to stand up to a federal aid audit. The answer was an engine that can be run again and again without doing harm, and that shows its work for every student.
The situation
Financial aid data is the least forgiving data a college holds. An award on the wrong term or a disbursement posted twice is not a typo; it is a compliance finding, and it lands on a student’s account.
A common way to migrate it is a long script, run once, late at night, followed by fixing what it got wrong by hand. Afterward it is hard to say exactly what was changed, and nobody wants to run it again.
What I built
A migration engine with one command for the whole population, designed around three ideas.
Check first. Every run can be a check-only run that reports what it would change, record by record, and changes nothing. That report is read and approved before the real run.
Safe to run again. The engine looks at each record, works out what “correct” means for it, and changes only what is not already correct. A second run finds nothing left to do. A run that stops halfway is simply started again.
Evidence for every student. Each record gets a before-and-after entry. That is what makes the result auditable: not a statement that the migration succeeded, but the proof for each student.
The engine is ordinary code, so it makes the same decision about the same record on every run. AI agents helped me build it and check it; they do not decide what happens to a record.
Try the idea yourself
The panel below is a small working model of that behavior, running in your browser on twelve made-up records. It is not the engine and it uses no AI; it is here because the idea is easier to believe when you can press the button twice.
Made-up records. No real students, schools or amounts. A simplified model that runs in your browser. No AI here, on purpose. This part should be plain, predictable code.
Twelve records are waiting. In the new system some are missing, some are wrong, some are duplicated, and several are already correct.
| Record | Old system says | New system has | Result |
|---|---|---|---|
| DEMO-0001 | Fall 2025, $2,750 | Fall 2025, $2,750 | Not checked yet |
| DEMO-0002 | Fall 2025, $1,500 | nothing | Not checked yet |
| DEMO-0003 | Spring 2026, $3,200 | Fall 2025, $3,200 | Not checked yet |
| DEMO-0004 | Fall 2025, $2,000 | Fall 2025, $2,000; Fall 2025, $2,000 | Not checked yet |
| DEMO-0005 | Spring 2026, $1,850 | Spring 2026, $1,580 | Not checked yet |
| DEMO-0006 | Spring 2026, $2,400 | Spring 2026, $2,400 | Not checked yet |
| DEMO-0007 | Fall 2025, $2,400; Fall 2025, $2,900 | nothing | Not checked yet |
| DEMO-0008 | Fall 2025, $3,100 | Fall 2025, $3,100 | Not checked yet |
| DEMO-0009 | Fall 2025, $900 | nothing | Not checked yet |
| DEMO-0010 | Spring 2026, $2,750 | Spring 2026, $2,750 | Not checked yet |
| DEMO-0011 | Spring 2026, $2,750 | Spring 2026, $2,750; Spring 2026, $2,750 | Not checked yet |
| DEMO-0012 | Fall 2025, $1,200 | Fall 2025, $1,200 | Not checked yet |
Show the technical detail
The fix is one small function. For each record it works out what the new system should hold from what the old system says, compares that with what is there, and changes only the difference. Because it works from the desired end state and not from a list of steps, running it again finds no difference and does nothing. Engineers call that property idempotent. A record whose source is ambiguous is never guessed at; it is set aside with the reason.
Safeguards
- Production is read-only until a person, with the authority to do so, runs the approved change.
- Every production run is checked before and after in three ways: through the system’s own interface, in the database, and by a set of validator reports that financial aid staff can run for themselves inside the student system.
- Records the rules cannot decide are not guessed at. They are held for a person, with the reason shown.
The result
The engine was built and shipped: one command that corrects financial aid records for an entire student population, can be re-run safely, and keeps per-student before-and-after evidence for federal aid audit.
What I would tell another school
Ask your migration vendor one question: “What happens if we run it twice?” If the answer is anything other than “nothing changes,” you are being asked to get it right the first time, on the one night nobody is at their best.
Printed from https://www.datazak.com/work/financial-aid-migration/. An address in parentheses after a link that begins with a slash is a page on https://www.datazak.com.
More work
Consulting engagement
The race that emailed students an empty link
A timed job sometimes lost a race with the email scheduler, so students got an invitation with no link. Now the link is saved as soon as the record is.
Consulting engagement
From batch jobs to near-live student data
A new integration layer on Azure replaced batch jobs, so a change in the student system reaches the other systems as it happens.
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.