Eleven-Month Deadline for a Student System Replacement

Take the commercial product, configure rather than customize, and phase by function. The date and the money are fixed, so scope is the only variable and it must be managed deliberately.

Triage the 47 gaps instead of weighting them equally:

• Bolt-on or interface (roughly 12): the financial aid mainframe will not change, so a scheduled file exchange or a thin service is the right answer, not a modification every future upgrade must carry.
• Configure or change the process (roughly 23): most recorded gaps turn out to be differences in workflow. Cost them in training and business change, not code.
• Genuine must-have build (a handful): each gets a named owner, a written scope, and an explicit statement of upgrade liability. Customizations on a commercial core are permanent maintenance debt.

On governance: sign-off before build cannot mean a requirements freeze in month two. Faculty will not adjudicate 640 written requirements, but they will adjudicate a configured prototype. Sign off module by module on walkthroughs.

Waterfall repeats the 2019 pattern - one migration, one go-live, no earlier feedback. Phase admissions and records first, financial aid integration second, and let MoSCoW priorities owned by the registrar absorb slippage rather than the deadline.

They are the most accurate requirements document the project has, and treating them as misconduct guarantees they go underground.

• Inventory and read them. Each encodes a reconciliation rule someone discovered painfully - a registration timing quirk, a program-specific override. Those are requirements formal elicitation missed.
• Buy cooperation by solving their problem. Have the new system produce the exception report automatically at each registration close. Once the department gets the reconciliation without manual work, the reason for the shadow system disappears.
• Use them as test oracles. Their historical outputs are a free acceptance suite: run the same term through the new system and compare exceptions line by line.
• Retire on a schedule, not immediately. Two clean close cycles, a named data steward per department, a written sunset date, and IT removing the share and credentials afterward.
• Do not migrate their data. It is derived and of unknown quality; migrating it imports the disagreements. Migrate from the system of record, reconcile to the shadow output, and explain each difference.

Give the departments a role in acceptance testing and they become allies who defend the new system to their peers.

It means the defect classes are already known and the fix is process, not heroics at cutover.

• Profile before anything else. Across the 820,000 student records: duplicates, missing required fields, orphaned program codes, impossible dates, and records whose status disagrees with the financial aid extract. Produce a defect count by category and make the registrar sign off the resolution rule for each category.
• Build a rule book. Each rule states the correct value, who decides, and what happens to records that cannot be resolved. Cleanse in a staging layer with full logging so every transformation is reversible. Never edit the source of record, which the old system and the mainframe still depend on.
• Iterate with mock loads. Three runs minimum, each with reconciliation counts by category, each closer to zero unexplained. The third run is the rehearsal: measure elapsed time against the freeze window and fix what overruns.
• Brand the exceptions. Some records will never be perfect. Give each category a business owner so it does not block go-live, but count and report it.
• Cut over in a quiet period with the old system read-only for a defined window. The 2019 failure most likely came from one migration attempt, under time pressure, with no reconciliation evidence to show what had been lost.