A project management system can load normally after an update while still losing permissions, automation, custom fields, notifications, or reporting behavior. Verification should compare the changed system with a documented baseline and test the workflows that matter to the organization. Start with read-only checks and use test records rather than altering live customer work.
Define the change and the baseline
Record the update time, vendor release or migration reference, administrator, affected sites or projects, changed settings, integrations, and rollback window. Capture a pre-change baseline when possible: project counts, key workflows, permission groups, custom fields, automation rules, dashboards, integrations, and a recent export. State which business processes must keep working, such as intake, assignment, approval, time tracking, or customer notification.
NIST SP 800-128 describes security-focused configuration management as a way to manage and monitor system configurations while supporting business functions and minimizing risk. Use that principle practically: compare the new state with an approved baseline, document exceptions, and verify changes rather than assuming the update preserved every configuration.
Verify access and permissions
Test at least one administrator, project manager, contributor, viewer, guest, and disabled or former-user scenario where those roles exist. Confirm users can see only the projects, fields, attachments, and reports they should. Check group membership, single sign-on, multifactor requirements, service accounts, API tokens, guest links, and ownership of automation. Ensure deactivated users did not regain access and new default permissions did not make private projects discoverable.
Review the audit trail around the change. Atlassian says its organization audit log tracks key activities within an Atlassian organization, while availability depends on product and plan. In any platform, confirm what was logged, who performed the change, and whether important configuration updates are visible. Export relevant audit entries when an incident or compliance record requires retention.
Test core workflows end to end
Create a clearly labeled test project or work item. Move it through each required status, assignment, approval, comment, attachment, mention, notification, and close-out step. Verify required fields, validators, due dates, recurrence, dependencies, templates, and permissions at each stage. Check email and in-app notifications without messaging real customers. Test mobile and browser access if both are used.
Then test integrations one at a time: calendar, source control, chat, email intake, time tracking, forms, storage, and reporting. Confirm authentication, data direction, duplicate prevention, error handling, and the account that owns the connection. Review scheduled automation for skipped or repeated jobs. Use a change log so each test has an expected result, actual result, evidence, and owner.
Verify data and recovery
Compare counts and samples of active projects, closed projects, users, comments, attachments, custom fields, and reports with the baseline. Open older records and recent records. Confirm search, filters, dashboards, exports, and API consumers still interpret fields correctly.
A vendor backup can have important exclusions. Atlassian's Jira Cloud export documentation says a backup can include work items, fields, board and sprint data, users and groups, comments, selected media, and configuration data. It also lists exclusions such as automation flows, third-party app data, and some service-specific features. Atlassian notes that backups containing attachments, avatars, or logos require 48 hours between backups and that some restore paths have age limits. For any platform, inventory excluded data and keep separate exports or rebuild instructions for it.
Run a restore test in an isolated environment when the change is high risk. Verify not only that the import completes, but that permissions, attachments, custom workflows, integrations, and notifications behave as expected. Do not overwrite the production site to prove a backup works.
Decide whether the change is accepted
Classify findings as pass, minor defect, major defect, security issue, or rollback trigger. A change is ready only when critical workflows pass, access is correct, data samples reconcile, integrations are stable, exports work, and owners accept documented limitations. Keep screenshots or exported evidence with the change record.
If rollback is needed, pause new writes if possible, preserve the changed state for analysis, follow the vendor's supported recovery path, and repeat the same verification after restoration. Finish with lessons learned and update the baseline. That makes the next software change easier to verify and reduces the chance that a visually normal interface hides an operational failure.
Sources
- SP 800-128: Guide for Security-Focused Configuration Management of Information Systems — National Institute of Standards and Technology, Oct. 10, 2019
- What activities does the audit log include? — Atlassian
- Export data from Jira Cloud — Atlassian Support