Confluence governance for growing teams
How to connect ownership, information architecture and Jira workflows so that a growing Confluence environment remains useful.
Eugene Victorov · 2026-11-09
Scale changes the governance problem
At Arrival, Eugene Victorov managed a collaboration environment spanning 380+ spaces, 400 projects and 28,000 pages across Confluence, Jira and SharePoint. At Technoserv, he built a company-wide Confluence knowledge base and KM operating models. These records establish the project context; they do not imply a universal migration duration or quantified savings.
Define what belongs where
Start from user tasks: decisions, requirements, reusable lessons, working documents and project status. Agree which system is authoritative for each. Link Jira work to the relevant Confluence context instead of copying status into multiple pages. Define a small number of page patterns and navigation rules that teams can maintain.
Give each space an accountable owner
Record the purpose, audience, owner and review routine for each important space. Agree who maintains reusable knowledge after a project closes. Review permissions with the responsible business and security roles. Open collaboration must not be confused with making confidential information accessible to everybody.
Treat migration as a business change
Before a Jira Cloud migration, assess users, groups, apps, integrations, data and acceptance criteria. Atlassian’s pre-migration checklist explains that automated checks do not cover everything. Use the current vendor documentation and rehearse the relevant scenarios; do not promise a migration date before assessing the actual estate.
Evaluate usability, not just page counts
Ask representative users to find an approved answer and follow the work context. Track broken navigation, unowned content, stale sources and support demand. A higher page count does not establish better knowledge reuse. Agree who will resolve the gaps after launch and which evidence shows the environment is helping the team.