Pricing Dashboard Sign up
Recent
· 10 min read · MDisBetter

Word to Markdown for SOPs: Company Policies as Searchable Wiki

Standard Operating Procedures live in a peculiar documentation purgatory. They're business-critical (when the audit comes, you need them), they're widely required (every operations team, every regulated industry, every quality-management system), and they're almost universally maintained as Word documents in a SharePoint folder that nobody can find. The combination of high importance and low usability is what kills SOP programs over time — employees don't read SOPs that are hard to find, can't search across SOPs that live as separate Word files, and quietly ignore the formal procedure in favor of asking a colleague who has done the task before. Migrating the SOP library from Word to a searchable Markdown wiki fixes the discoverability problem and is one of the highest-leverage operational documentation projects most companies can run. This article is the playbook, with honest notes on the one-at-a-time web workflow and when to drop down to Pandoc on a corporate machine for bulk migration.

Why SOPs end up in Word and why that breaks them

SOPs accumulate in Word because the original SOP authors had Word, the legal or quality team templated their first SOP in Word, and inertia did the rest. The library grows one document at a time, each saved with its template-of-the-day formatting, and within a few years the SOP folder is a heterogeneous mess. The failure modes are predictable:

Markdown plus a wiki tool fixes all five problems. The migration is the unglamorous middleware that makes the fix possible.

Wiki tool selection

The wiki target depends on your existing stack and ops team preferences. The four contenders most operations teams settle between:

All four ingest Markdown cleanly. The migration produces the same Markdown files; the wiki choice determines where they end up. Pick one early in the migration program — don't try to support multiple wiki targets in parallel.

Step 1: SOP inventory and triage

Before any conversion, run an inventory similar to other Word migrations. Per SOP file:

The triage decision is the most important output. SOPs are particularly prone to going stale (the procedure changed but the document didn't), and the migration is the right moment to force a freshness review. The pattern: every SOP that hasn't been reviewed in 18+ months gets flagged for SME confirmation before migration. Confirmed-current SOPs migrate; out-of-date SOPs get either updated first or formally retired with a note in the wiki.

Step 2: convert through the web tool, one SOP at a time

For most SOP libraries (typically 50-300 documents), the one-at-a-time web workflow is the right shape. The workflow per SOP:

  1. Upload the .docx to word-to-markdown
  2. Download the .md output
  3. Open in your text editor
  4. Walk the document, fixing heading hierarchy, table integrity, and any embedded image references
  5. Add wiki frontmatter (department, owner, last-reviewed date, regulatory reference, version number)
  6. Commit to the wiki (paste into Confluence/Notion, commit to MkDocs repo, etc.)

An ops team member can process 4-8 SOPs per day at this level of attention. For 200 SOPs that's 4-6 weeks of part-time work — slower than a Pandoc batch, but the manual step is what catches the staleness, formatting issues, and outdated cross-references that make the migrated SOPs actually usable.

For SOP libraries in the thousands (large healthcare systems, multinationals, regulated manufacturers), the one-at-a-time workflow is the wrong shape. Drop down to Pandoc for a bulk first pass:

#!/bin/bash
# Bulk convert SOP library, preserve folder hierarchy

SRC=~/SharePoint/SOPs
DEST=~/wiki-staging/sops

find "$SRC" -name '*.docx' -type f | while read f; do
  rel="${f#$SRC/}"
  out="$DEST/${rel%.docx}.md"
  mkdir -p "$(dirname "$out")"
  pandoc "$f" -f docx -t gfm --wrap=preserve --extract-media="$DEST/media" -o "$out"
done

The bulk output is the staging area. The editorial pass and SME review still happens per-SOP before publishing to the wiki, but the structural conversion is done overnight rather than over weeks.

Step 3: standardize the SOP template

One of the highest-leverage outputs of the migration: every SOP in the new wiki uses the same template. The standard SOP template that most operations teams converge on:

---
title: SOP-042 Customer Refund Escalation
department: Customer Operations
owner: Sarah Chen
last_reviewed: 2026-04-15
next_review: 2027-04-15
version: 3.1
regulatory_ref: SOC 2 CC6.1
---

# SOP-042 Customer Refund Escalation

## Purpose

Defines the escalation path for customer refund requests above the
front-line agent's authorization threshold.

## Scope

Applies to all customer-facing operations staff handling refund requests.

## Procedure

1. Refund request received from customer
2. Front-line agent verifies eligibility per SOP-041
3. If refund amount ≤ $5,000: agent processes per SOP-041
4. If refund amount > $5,000: agent escalates per below

### Escalation steps

1. Agent submits escalation form in CRM
2. Team lead reviews within 4 business hours
3. Decision logged in CRM with reasoning
4. Customer notified within 1 business day

## References

- SOP-041 Standard Refund Processing
- Customer Operations Manual section 4.3
- Finance Approval Authority Matrix

## Revision history

- 3.1 (2026-04-15): Threshold raised from $3,000 to $5,000
- 3.0 (2025-08-22): Restructured for new CRM workflow
- 2.4 (2024-11-03): Initial migration from Word

The frontmatter feeds the wiki's metadata system (Confluence labels, Notion properties, MkDocs Material's metadata). The body sections (Purpose, Scope, Procedure, References, Revision history) appear in every SOP, which makes the wiki feel coherent rather than like a collection of converted Word documents.

Step 4: cross-link the SOP corpus

SOPs in a folder of Word documents have no cross-links — every reference to another SOP is a plain-text "see SOP-041" that the reader has to manually find. SOPs in a wiki can have actual hyperlinks. Adding cross-links during the editorial pass turns the SOP library from a collection of separate documents into an interconnected reference corpus.

The links matter most for:

For an SOP library of 200 documents, expect to add 5-15 internal links per document during the editorial pass. The compounding effect across the corpus is significant — once cross-linked, the wiki becomes navigable rather than searchable-only.

Step 5: enable search and discovery

The headline benefit of moving SOPs into a wiki is full-text search across the entire library. All four wiki tools above include this natively. The practical guidance:

Search query logs are also one of the best inputs to AI-assisted SOP question answering, covered next.

Step 6: the AI-assisted SOP layer

Once the SOP library is Markdown in a wiki, it becomes a substrate for AI-assisted question-answering. Employees ask natural-language questions in Slack or Teams; an AI assistant retrieves the relevant SOPs and produces an answer with citations.

The architecture is the standard RAG pattern (covered in detail in word to Markdown for enterprise knowledge bases). For SOP-specific implementation, two extra considerations:

For most operational questions, this AI layer cuts the time-to-answer from "open three SOPs and search each" to "ask in Slack and get an answer with links in 5 seconds." Employees actually use it; the SOPs actually get followed; the operations team's quality-of-life improves measurably.

The healthcare-SOP exception

One important honesty disclaimer for any SOP migration involving protected health information: the web tool at mdisbetter.com is not HIPAA-compliant infrastructure. For SOPs that are themselves about handling PHI (clinical workflow procedures, EHR system documentation), the web upload is fine — the SOP itself doesn't contain PHI. For any SOP attachment that contains actual patient data, work locally with Pandoc on a HIPAA-compliant device. For clinical documentation tools that handle PHI directly, look at Suki, Augmedix, or Nuance Dragon Medical — different category of product entirely. The mdisbetter web tool is for the general operational SOP migration, not for handling PHI.

Cross-feature: training and onboarding material

SOPs are one part of an operational documentation corpus that typically includes training material, onboarding guides, recorded training sessions, and reference policies. The same wiki holds all of them; the conversion path varies by source format:

The unified wiki becomes the operations team's single source of operational truth. The migration to get there is a 2-4 month project for most mid-sized companies; the leverage afterward compounds for years.

For related migration patterns see word to Markdown for compliance teams (the regulatory-document analog of SOPs) and word to Markdown for technical writers (the docs-as-code transition that ops teams often follow second).

Frequently asked questions

Should I keep the original Word SOPs after migrating to the wiki?
Keep them in a frozen archive folder for one to two years after migration, then formally retire. The reason for keeping them initially: regulators, auditors, and internal stakeholders sometimes need to verify what the SOP said at a specific point in time, and the original Word documents are the unambiguous historical record. Once your wiki has been the canonical source for 12-18 months and its version history covers any timeframe of interest, the original Word files become redundant and can be retired per your records-retention policy. Don't let the original Word folder become a parallel canonical source — every SOP change goes through the wiki only after migration day.
How often should SOPs be reviewed and updated in the new wiki?
Standard practice is annual review for low-volatility SOPs (administrative procedures, compliance policies that don't change often) and semi-annual or quarterly review for high-volatility SOPs (customer-facing workflows that respond to product or policy changes). Build the review cadence into the wiki via the frontmatter — every SOP has a 'next_review' date, and an automation flags overdue reviews to the SOP owner. The wiki migration is the right moment to establish this discipline; in the Word-folder world, reviews almost always slipped because there was no systematic visibility into which SOPs were stale. After migration, the wiki dashboard makes overdue reviews obvious and accountability follows.
Can our SOPs handle PHI or other regulated data after Markdown conversion?
The Markdown SOP itself (the document describing a procedure) is not regulated data — it can move to a wiki freely. The honesty disclaimer matters for two adjacent scenarios. (1) If your SOPs include sample data, screenshots, or attachments containing actual PHI, those attachments are regulated and need handling per your HIPAA program — don't upload them to the web converter; work locally with Pandoc on a HIPAA-compliant device. (2) The web tool at mdisbetter.com is not HIPAA-compliant infrastructure for any workflow involving PHI. For clinical documentation tools that handle PHI directly (ambient voice notes during patient encounters, etc.), look at purpose-built tools like Suki, Augmedix, or Nuance Dragon Medical — those are different product categories. mdisbetter is for general operational SOP migration where the SOP content itself is not PHI.