From Confluence to Kopexa: migrate policies and manage them with control

You do not need to rewrite your policies when moving from Confluence to Kopexa. Start with a representative page, transfer its content and check the result. Then configure the workflow you are moving for: collaborate on changes, review a specific version, trace its approval and deliver the valid content to employees.

Perhaps the policy already lives in Confluence. But who still needs to approve the new version? When will its content next be reviewed? And how does the change reach those expected to follow it? If that work currently spans several tools and informal agreements, examine the complete process.

This fourth part of “Moving your ISMS” covers Confluence policies. Part 1 explains general data transfer; part 3 on evidence history explores preserving earlier versions and decisions.

Key takeaways

• Reuse content: test copy and paste on a real sample page before transferring everything.
• Approve a version deliberately: transfer and substantive approval are different steps.
• Separate version review from currency: a new version needs a decision; existing valid content needs its next review trigger.
• Involve employees: the Workforce Hub supports reading and acknowledging policies and checking knowledge.

When is moving a Confluence ISMS worthwhile?

Confluence is a working environment for shared knowledge. It can also represent approvals: Atlassian describes Confluence Cloud approval requests with approval, requested changes and decision history. Examine your actual setup rather than tool names alone. See the Atlassian approval documentation.

More specific questions determine the value of your move:

• Do you want to manage policies alongside their requirements, measures and evidence in a shared ISMS environment?
• Should the next content review, its owner and deadline be visible directly at the document?
• Do you want to connect expert-team maintenance with employee communication and acknowledgement?

Kopexa brings this work together in policy management and the Workforce Hub. The benefit appears in the workflow: owners see what is due, reviewers see outstanding decisions and employees receive the content intended for them.

That does not mean moving your entire company wiki. You can limit the change to ISMS policies and relevant working instructions while keeping Confluence for other team knowledge. Decide clearly where authoritative versions will be maintained.

1. Which pages should become policies?

Select content by its purpose. An approved policy, a discussion page and a personal note do not need identical treatment. For each relevant page, clarify its owner, valid version and audience.

A concise transfer inventory helps:

When the same content appears in several places, first check whether it is genuinely the same version and scope. A similar title alone does not justify merging it.

2. Start with a test page: check copy and paste

For individual policies, copy and paste is a natural starting point: open the confirmed source version, copy its contents and paste them into Kopexa’s document editor. Choose a page with typical elements, such as headings, lists, a table and important references.

Then check completeness and usability:

• Are text, headings and lists complete and sensibly structured?
• Are tables still readable, with rows and columns correctly aligned?
• Can authorised people actually open images and attachments?
• Do internal links lead to the intended document or still only to the old Confluence page?
• How are macros, embedded content and dynamically generated sections handled?

Preserve the meaning of each element deliberately. A dynamic overview may need a different implementation from ordinary text. Record required corrections before the version enters review.

For larger collections, agree on the transfer path together. Atlassian documents several export formats and format-dependent contents and export permissions. An export format alone does not promise that another application can import the entire space and its history. See Atlassian’s content export guidance.

Copy and paste transfers page content, not automatically the earlier version and approval history. Part 3’s evidence-chain check explains which originals to preserve and how to retain their associations.

3. Review changes to a specific version

Kopexa’s version review examines a specific revised version. Reviewers approve it or request changes. Their decisions remain traceable to that version. Development teams also know this principle from pull requests.

For ISMS owners, three questions matter: which version is under review? Who needs to decide? Which approvals are still missing? This prevents an informal “looks good to me” message from later standing without a version reference.

Product view in German: reviewers and progress remain visible in the version review.

For example, your work-equipment policy changes its rule on personal devices. The owner edits the draft. Named reviewers assess the change within their responsibilities and approve it or request revision. Feedback therefore concerns the exact version examined.

Product view in German: an explicit decision on the reviewed version.

During migration, define which roles will review in future and how the first transferred version is approved. Today’s approval documents today’s transition; the original Confluence history remains distinguishable.

4. Manage new versions and the next content review separately

Approving a changed version answers: “May this version be used?” Periodic content review asks: “Does the existing content still fit our organisation and working practices?”

Kopexa represents these as separate workflows. Name reviewers for a new version. For content review, configure reviewers, interval and dates on the document. The last and next review stay visible; Kopexa reminds you when the next review is due.

Not every review must create a new version. Concluding that no change is needed is different from producing and approving a revised version. Where work arises, linked tasks can coordinate it.

Include this distinction in the transfer plan: decide which documents need substantive review first and which confirmed versions provide the starting point. Technical transfer does not make that business decision for you.

5. From an approved document to the Workforce Hub

Approval within the expert team does not answer how the policy reaches affected employees. In the Workforce Hub, employees can read and acknowledge policies and complete knowledge checks. The maintained version becomes content they can engage with.

Example Workforce Hub view in German: employees see their assigned tasks and content.

During the transition, define who needs which policies and how material changes are communicated. Test the workflow with an intended employee role: is the correct content accessible? Is the task understandable? Is it clear what must be acknowledged?

A read acknowledgement records the confirmation given. Add suitable knowledge questions if you want to examine understanding. The Workforce product page shows how this work can be organised.

A workflow rather than just a file transfer

Test the migration using one policy:

1. Select the confirmed Confluence version and document its source.
2. Transfer content and correct problematic elements.
3. Define owners and reviewers and have the transferred version reviewed.
4. Keep the valid version and next content review traceable.
5. Test the content for intended employees in the Workforce Hub.

Kopexa supports migration. CSV import paths and a GraphQL API are also available for structured data. Establish which route suits page contents, metadata and supplementary sources against your actual records.

Bring an anonymised sample policy for planning. Use it to show current approval, a typical change and the intended audience. This lets you discuss the entire workflow rather than just file transfer. See Kopexa policy management for the product workflows.