A weak modernization plan treats access control like a set of CRUD screens. Create cardholder, edit card, assign reader, export report. That is not how the operational risk behaves.
In WebKD, access decisions cross people, cards, devices, groups, schedules, events, reports, and operator permissions. A change to one concept can affect effective access, reader reloads, attendance reporting, and the visibility an operator needs when investigating an event.
That is why CloudFloo starts from the domain model. PKD cardholders, KAD access cards, TKD readers and controllers, RCP servers, GLC structures, groups, schedules, sequences, events, and reports have to be named before they can be safely changed.
The model also separates functional permissions from data permissions. An operator may be allowed to use a feature, but still be limited to specific cardholders, devices, groups, or organizational scopes.
This separation matters for UX. A screen that hides the domain behind generic labels forces operators to remember invisible rules. A screen that mirrors the domain lets the operator understand why a permission exists and what could be affected by changing it.
For engineering, the same model becomes a test strategy. Permission recalculation, event flows, reports, and reader updates can be tested around domain behavior instead of only around endpoints.
The SEO lesson is also practical: a serious case study should name the domain. "Enterprise platform modernization" is weak. "Access-control permissions across PKD, KAD, TKD, RCP, groups, schedules, and reports" tells the right buyer that you understand their world.