Migration plan & milestones

flowchart TB
  subgraph phase ["This phase — M1 to M4"]
    P[Four portals] --> API[Portal API]
    API --> CMS[Campus CMS family SoR
Lesotho pilot first]
  end
  subgraph later ["Longer term — M5+"]
    G[Verified gap] --> MIG[Migration strategy]
    MIG --> U[Progressive unified CMS]
    CMS -.->|retire desk only when ready| U
  end
  phase --> later
          

flowchart LR
  M1[1. Confirm rules
and integration] --> M2[2. Admissions launch]
  M2 --> M3[3. Core student portal]
  M3 --> M4[4. Lesotho pilot
acceptance]
  M4 --> M5[5. Campus expansion
and remaining CMS]
          

Kickoff and backend commitments: TBC.

Not a UI milestone. Unblocks every later “Needs checking” row. Full text: SDD-03 §M1.

Student-only demo UI is insufficient. Lecturer publish/mark and staff approval paths for the same CAP IDs must be Live or explicitly served by the old CMS. Full text: SDD-03 §M3 · portals SDD-05 / SDD-06 / SDD-07.

Full text: SDD-03 §M4. Approach: lesotho-pilot.md.

1. Confirm admissions staff can complete offer → first enrolment on old CMS (or document the gap).
2. Deliver CAP-53 first slice: auth + applicant create/read + document metadata acknowledgment.
3. Only then promote student Demo journeys that mutate registration or finance.
4. Do not mark any CAP Live from frontend Demo alone.
5. Do not rebuild working staff desks — Portal API + verified old CMS (SDD-14).

Near-term design rule (next two weeks)

Student portal v1 is deepest on M3 screens; product priority still puts M2 before M3.

1. Freeze new student demo screens unless they are on the M2 critical path (auth, mobile shell, accessibility).
2. Prioritise CAP-53, CAP-01, applicant CAP-02/03/07, and Registry old-CMS verification.
3. Keep existing student demos, but label them Demo until wired.

A capability is Live only when all of the following are true:

1. Real data from the system of record, not a mock session.
2. Durable save where the user can mutate data.
3. Server-enforced permission for that role and campus.
4. The paired staff/lecturer action exists in new UI or is verified in the old CMS.
5. Accountable owner named.
6. Core mobile accepted if the CAP is in PRODUCT-MOBILE.
7. Country/campus operating checks in the next-action column are closed or explicitly waived.