Compare tasks, not just screens
Ask representative users to perform the same approved tasks on the source and target: locate a document, open it from the business application, check in a revision, update metadata and complete a workflow action. Record expected outcomes and differences that need training or configuration work.
An 11g-to-12c observation does not establish what 14c will do. Confirm the selected upgrade route and target documentation before carrying a historical change list into a new project.
Check folder behavior and permissions
Oracle’s Content management guide describes folder metadata, propagation controls and action-specific access requirements. Authorship and the operation being performed matter; a blanket instruction to grant Delete permission is inappropriate.
Test the intended operation with the actual user role, including restricted folders and items. Verify both successful changes and access that must remain denied. Distinguish a configuration or permission issue from an expected interface change.
Build a targeted acceptance list
- Document work: search results, identifiers, revisions, renditions and business-record links.
- Folders and metadata: defaults, propagation, required fields and permitted actions.
- Accessibility: the keyboard and assistive-technology workflows users actually need.
- Sign-in: identity-provider behavior, session handling and any explicitly configured password-policy changes.
- Workflow: task visibility, completion and the expected document context.
Do not assume a product upgrade introduces a new password policy or improves an accessibility workflow automatically. Test the configured environment and involve the relevant users.
Treat Sites separately when it is in scope
WebCenter Sites contributors need a comparison of their own publishing, approval, preview and asset-management tasks against the selected Sites release. Check deprecated features and integration dependencies in that product’s documentation. A Content change notice cannot serve as a Sites compatibility assessment.
Publish the differences you actually verified
For each affected user group, provide a short explanation of the changed task, expected result and where to get help. Validate the instructions in the rehearsal environment before distributing them.
Use the upgrade validation checklist to connect this work to technical acceptance and the legacy release route to keep the upgrade scope clear.