The short answer
Verify migrated roles by testing effective permissions for representative users and sensitive actions, not by comparing role names. Map source grants, property/entity scope, inherited access, approval limits, service accounts, and terminated users to target behavior; hold access that cannot be justified.
Operational checklist
Mark your progress, then save a working copy. Selections reset when you leave this page. A checked box is not an approval or evidence of completion.
☐
People and machine identities inventoried
☐
Source authority and target identity matched
☐
Property/entity scope mapped
☐
Sensitive capabilities and thresholds mapped
☐
Positive and negative tests executed
☐
Disabled users and old tokens checked
☐
Exceptions contained and retested
0 of 7 marked
Key takeaways
- Equivalent role names do not prove equivalent capability.
- Test both allowed and denied actions.
- Include removed users, service accounts, and emergency access.
Map capabilities and scope, not labels
Inventory active people, teams, service accounts, API credentials, temporary access, and users expected to be disabled. For each, record the authoritative employment or vendor status, target identity, properties/entities, data domains, actions, approval thresholds, and role inheritance.
NIST account-management and least-privilege concepts support authorization review and prompt removal. The control catalog is a security reference, not a claim that a particular property manager is subject to federal requirements.
Run positive and negative tests
Use non-production or controlled test records where possible. Verify what the user can see, create, change, approve, export, and administer—and what should be denied. Do not perform real payments, notices, or other consequential actions merely to test a button.
| Test persona | Allowed evidence | Denied evidence |
|---|---|---|
| Property operator | Assigned properties and ordinary work actions | Unassigned property and role administration |
| Accounting preparer | Prepare reconciliations | Approve own restricted release if policy separates roles |
| Manager/approver | Approved limits and property scope | Actions beyond threshold or entity |
| Service account | Named integration operations | Interactive login or unrelated exports |
| Departed/disabled user | No active access | Login, token use, shared-link access |
Treat unexpected access as a cutover defect
Record the exact identity, property, action, observed result, expected rule, evidence, containment, owner, and retest. Avoid solving an inherited-role problem by adding broader access elsewhere.
After fixes, export the effective-access state if the platform supports it and obtain the appropriate owner’s acceptance. Record emergency or break-glass paths, expiry, monitoring, and post-use review separately.
Edge cases
- Target roles are broader than source roles: create a compensating control or hold cutover for affected users.
- A shared login exists in the source: do not reproduce it without explicit security review.
- A user needs temporary dual-system access: set expiry and review both systems at handback.
Sources and references
Follow each source to check the underlying claim. Access checks and professional review are different steps.
1. Primary source · National Institute of Standards and Technology
SP 800-53 Rev. 5, Security and Privacy ControlsAccount management and least-privilege concepts support timely access review and removal. The federal control catalog is used as a process analogy, not a landlord mandate.
Source checked 2026-09-18
Automated source-access check: 2026-09-18.
Continue the workflow
PMS migration acceptance criteriaIntegration credential rotation after PMS cutoverVendor access credential lifecycle for rental propertiesRevision history
2026-09-18
Initial Phase 3 operational article with a distinct decision artifact, failure states, source-scope notes, and AI-assisted technical review.