Most companies write their first policies wherever they happen to be working: a Word file on a shared drive, a Google Doc in someone's folder. Moving them into Confluence puts them where people already look, with page history and search built in. The import itself is the easy part. The work is in deciding what to bring, cleaning up what arrives, keeping the history auditors care about, and making sure nobody keeps reading the old copy.
How to import Word into Confluence Cloud
Confluence Cloud has a built-in importer for Word documents (.docx), Google Docs and Word files stored in OneDrive. At the time of writing, the flow starts from a new page:
- Click Create in the top navigation to open a blank page in the space where the document should live.
- Open More actions (the
•••menu next to Share) and choose Templates and import. - Go to the Import tab and pick the source: a Word document, a Google Doc or OneDrive.
- For Google Docs and OneDrive, connect your account when asked, then select the files.
- Finish the import, review the result and publish.
A few details are worth knowing before you start:
- Only
.docx. Older.docfiles need to be opened and saved as.docxfirst. - Size limits. Atlassian currently lists 5 MB per document (not counting images and other attachments), and bulk imports of up to 30 files and 50 MB in total, with no single file over 10 MB.
- Single and bulk imports land differently. One file becomes a draft page you publish yourself. Several files at once are created as child pages under a restricted placeholder page called "Imported pages", so you can review them privately before moving them into place and opening them up.
- Menus move. If a label above doesn't match what you see, search Atlassian's support site for "import external documents".
Moving Google Docs to Confluence
To move Google Docs to Confluence, use the same importer and choose Google Doc, then connect a Google account when asked. Run the import as someone who can open every document in the policy folder.
Two alternatives come up often. Copy and paste works for short documents with simple formatting. Embedding shows a Google Doc or Word file on a Confluence page through a link or macro, depending on what your site has enabled. An embed is not a migration, though: the text still lives in the old tool, Confluence's page history doesn't see changes to it, and readers may need separate access. For policies, import the text.
What converts well, and what to check
Atlassian's documentation is short on detail here. It says basic text and formatting come across, Word shapes are replaced with placeholders, and images in unsupported formats are replaced with placeholder text (common formats such as PNG, JPG, GIF and SVG are supported). It doesn't say how comments, tracked changes, footnotes, or headers and footers are handled. Before you migrate a whole folder, import one representative document and compare it side by side with the original.
| Element | What to expect | What to do |
|---|---|---|
| Headings | Heading styles are the most reliable structure to carry over. | Use real heading styles in the source, not bold body text, before importing. |
| Tables | Merged cells and fixed widths are where conversions tend to go wrong. | Simplify complex tables first, or rebuild them in Confluence. |
| Images | Supported formats come across; others become placeholders. | Convert unusual image formats to PNG first. Replace screenshots of text with real text. |
| Shapes and drawn diagrams | Replaced with placeholders. | Export diagrams as images and add them back. |
| Comments and tracked changes | Not documented. | Resolve every comment and accept or reject every change before importing. A policy should arrive as clean, final text. |
| Footnotes | Not documented for Confluence Cloud. | Check the test import. Moving footnotes into the body or a "References" section is usually clearer on a web page anyway. |
| Headers and footers | Not documented. | Assume they won't carry over. Move anything that matters (document owner, classification, version) into the page body. |
Tip: Prepare the source documents before you import. Accepting tracked changes and fixing heading styles in Word takes minutes; untangling the same problems in twenty Confluence pages takes an afternoon.
Cleaning up after the import
Every imported page needs a short pass before anyone relies on it. Work through this list per page:
- Title. Use the policy's name only, such as "Access Control Policy". Leave version numbers, dates and "FINAL v3" out of the title: the title should stay the same for the life of the policy so links to it keep making sense.
- Leftover document furniture. Delete cover pages, manual tables of contents with page numbers, and blank paragraphs that held the Word layout together. Clear formatting on any paragraph that looks odd and reapply headings.
- Links. Links that pointed at other Word files or shared-drive folders now point at the old world. Change them to the matching Confluence pages, or remove them.
- Metadata. Add the things the header used to carry: owner, effective date, next review date and who the policy applies to. A small table at the top works well.
Preserving the history
Confluence keeps a version history for every page: you can compare versions and restore an old one. That history starts at the import, though. The edits inside a Word file or a Google Doc's revision history don't come with it, and an auditor may still ask when a policy was first adopted and who approved the last version.
Bridge the gap in two ways:
- Add a revision table to the bottom of each page, carrying forward what you know from the old document and noting the migration itself.
- Keep the final source files. Export the last approved version of each document as a PDF and store the set in one restricted archive location. Don't delete the originals while they might still serve as evidence.
An example revision table:
| Version | Date | Change | Approved by |
|---|---|---|---|
| 1.0 | 2024-03-12 | First version adopted (Word document) | CEO |
| 1.1 | 2025-03-20 | Annual review, added MFA requirement (Word document) | CEO |
| 1.1 | 2026-09-15 | Migrated to Confluence from Access-Control-Policy-v1.1.docx. No content changes. Source PDF kept in the policy archive. | Not applicable |
The "no content changes" note tells a reader the Confluence page is the same policy approved in 2025. If you change the text during the migration, treat it as a new version that needs approval. Policy version control and approvals auditors accept covers how to run that approval properly.
Deciding what to migrate and what to retire
A migration is the cheapest moment to prune. Sort every document into one of four piles before you import anything:
- Migrate as is. Current, approved and still accurate. Import it and record the migration in the revision table.
- Migrate, then revise. Still needed but out of date. Import the approved text first, so the history shows what changed, then edit and get the new version approved.
- Merge. Several documents covering the same ground, such as a password standard and an access control policy. Combine them into one policy.
- Retire. Superseded, never adopted, or about tools you no longer use. Don't import these. Archive the final copy with a note saying when and why.
If you are working toward a SOC 2 report, compare the result against the list of policies a SOC 2 program usually needs. Gaps are easier to spot now than during an audit.
Structuring the destination page tree
Give policies one home: a parent page, ideally in a space dedicated to policies or to your compliance program. A simple tree is enough:
- Policies (what lives here, who owns the program, how to ask questions)
- One child page per policy, titled with the policy name
- Policy archive (restricted: retired policies and the original source files)
Resist mirroring the old folder structure: a flat list of policies under one parent is easier to read, link to and permission. For the wider space layout, including activities and evidence, see how to run a SOC 2 compliance program in Confluence, and for what to add once the pages exist, Confluence policy management beyond a wiki page.
After a bulk import, move each cleaned-up page from the "Imported pages" placeholder to Policies.
Handling the cut-over
The riskiest part of a migration is the period when two copies exist: the onboarding checklist still links to the Google Doc, and six months later a team is following the old version. Plan the cut-over as a short, deliberate step:
- Pick a date. Announce that from that day the Confluence pages are the only current versions.
- Mark every old copy as superseded. Add a line at the top of each Word file and Google Doc: "Superseded on (date). The current version is in Confluence:" followed by the page link. Then make the old copies read-only.
- Redirect the links you control. Search your handbook, onboarding checklists, HR system and ticket templates for links to the old files and point them at the Confluence pages. Inside Confluence it is easier: when you move a page, links to it are redirected automatically.
- Archive, don't delete. Move the old files into the archive after a grace period. Archive old Confluence drafts in Confluence: links to archived pages keep working and are marked as archived.
- Tell people where to look. One short company message linking to the Policies page does more than any banner.
Taking it further with Compliance in a Box
Once your policies are Confluence pages, Compliance in a Box can turn them into a managed SOC 2 program. The app creates a compliance space with its own policy pages, and you bring your existing text into them in one of two ways, both described in the user guide:
- Paste it in. The policy owner opens the app's policy page in the Confluence editor, replaces the text with yours and publishes.
- The import wizard. A Compliance Admin picks existing Confluence pages, from any space they can view, and maps each one to a policy. It reads Confluence pages, so a Word or Google Docs policy first goes through Confluence's own importer (a staging space works well), and the wizard takes it from there.
The import wizard has four steps: Pick pages, Map to policies, Review and Import. Each page goes into one of the app's existing policies, replacing its text, or becomes a New custom policy for something the framework doesn't include, owned and approved by the importing admin until you reassign it.
When you add a page, the wizard warns you about content that won't copy cleanly. If your imported page has images, expect the attachments warning: images and files stored on the source page aren't copied, so the owner re-attaches them. It also flags macros that show other content, mentions of people (copying notifies them) and pages over 900 KB, which can't be imported. The source page is never changed.
Importing copies text only. It never carries over approvals or sign-offs from your old documents. The imported text becomes a new, unapproved version of the policy page, so the policy shows as a draft (or changes pending, if an earlier version was approved), and the owner reviews it and clicks Submit for approval as usual. Your revision table keeps the old approvals as history.
FAQ
Can I import a PDF into Confluence?
PDF isn't among the sources Atlassian lists for the importer (Word, Google Docs and OneDrive). If a PDF is the only copy of a policy, find the original document or convert it to Word first and check the result carefully.
Does Confluence keep my Word version history?
No. Confluence's version history starts when the page is created. Carry the important history forward in a revision table and keep the final source files in an archive.
Do my old approvals still count after I migrate policies to Confluence?
They are still history, and a revision table plus the archived originals show what was approved and when. Whether a migrated policy needs a fresh approval depends on whether the text changed and on what your auditor expects. Any new or edited version should be approved on the page itself.