The Knowledge Migration Nobody Is Talking About

Making enterprise knowledge consumable by AI

For decades we have optimised organisational knowledge for exactly one consumer, and that consumer is a human being. We wrote policies in Word. We published procedures as PDFs. We built training decks in PowerPoint. We buried decisions in meeting minutes and SharePoint folders with names like "Final_v3_APPROVED_useThisOne".

That worked, and it worked because humans are extraordinarily good at reconstructing context from very little. You see a heading and understand the paragraphs below belong to it. You notice a table is comparing two things. You register that a footnote qualifies a sentence. You connect a statement on page 47 to a definition introduced on page 3, forty-four pages earlier, without consciously deciding to.

A language model does not experience a document that way at all. Which produces a problem that is going to bite a lot of organisations shortly.

Your organisation may hold an enormous amount of knowledge. That is not the same as your AI being able to consume it reliably.

The problem is not RAG

The standard response is "we will put all our documents into RAG", and on the face of it that is sensible. Extract the text from the PDFs and Word files, generate embeddings, load a vector database, let the model retrieve the relevant pieces. Except a step has gone missing in that sentence, and it is the step that matters: what happened to the document when it became text?

A PDF is not really a knowledge representation. It is much closer to a set of instructions about where marks should appear on a page. Take a two-column layout:

Column A              Column B

Introduction          Conclusion
Paragraph 1           Paragraph 1
Paragraph 2           Paragraph 2

A naive text extractor can hand you this:

Introduction
Conclusion
Paragraph 1
Paragraph 1
Paragraph 2
Paragraph 2

Every word survived. The knowledge did not. That is the failure mode nobody budgets for, and it is worth naming plainly: information can survive extraction while meaning does not.

A concrete example, because this gets hand-waved

Suppose an HR policy contains this table:

Employee type	Notice period
Permanent	4 weeks
Contractor	2 weeks
Executive	12 weeks

A human reads the relationships instantly. A poor extraction can produce this:

Employee type
Permanent
Contractor
Executive

Notice period
4 weeks
2 weeks
12 weeks

Now ask the model what the notice period is for an executive. It has to rebuild a relationship that the extraction destroyed. It might get it right. It might also confidently return four weeks, and someone might terminate a contract on that basis.

That is a hallucination, and it will be recorded as a model failure in the post-mortem. It is not one. The model was handed a mangled representation and asked to guess. Same information, expressed so the relationships are explicit in the text itself:

| Employee type | Notice period |
|---------------|---------------|
| Permanent     | 4 weeks       |
| Contractor    | 2 weeks       |
| Executive     | 12 weeks      |

The row, the column and the value are now in a stated relationship rather than an implied one.

The same thing happens to hierarchy

Consider a policy laid out like this:

3. Security

3.1 Password Requirements

Passwords must contain...

3.2 Service Accounts

Service accounts must...

4. Exceptions

Exceptions may be approved...

Now suppose extraction gives you this:

Security
Password Requirements
Service Accounts
Exceptions
Passwords must contain...
Service accounts must...
Exceptions may be approved...

The content is all present and the hierarchy is gone. A model that retrieves "Passwords must contain..." no longer knows which section it came from, which policy it belongs to, or whether it applies to users, to service accounts, or only inside an approved exception. In a security policy that distinction is the entire point.

Expressed with the structure intact:

# 3. Security

## 3.1 Password Requirements

Passwords must contain...

## 3.2 Service Accounts

Service accounts must...

# 4. Exceptions

Exceptions may be approved...

The hierarchy is now part of the knowledge rather than a visual convention the reader is expected to infer. That is the shift: we are not converting documents into text, we are converting documents into an explicit representation of what they mean.

PDF is not the enemy

None of this makes PDFs bad. PDFs are excellent. They are portable, printable, they preserve presentation exactly, and they are the right way to publish a controlled version of a policy that must look the same for everyone who opens it. The problem is asking one format to be both a human presentation format and a machine knowledge format. Those are different jobs and they pull in opposite directions.

The same goes for Word. It is a fine authoring environment, with comments, tracked changes, styles, headers and footers. But a great deal of what a DOCX contains is presentation metadata rather than knowledge, and when a model consumes it, something has to reconstruct the meaning from the formatting.

Modern tooling does this reasonably well. Azure AI Document Intelligence's layout model extracts paragraphs and assigns them logical roles including titles, section headings, page headers and page footers, maintains section and subsection hierarchy, handles PDF alongside Word, Excel, PowerPoint and HTML, and will emit the result as Markdown via outputContentFormat=markdown.¹

Notice what that actually tells us. The recommended path converts the PDF into Markdown before the knowledge reaches the model. The industry has already voted on which format is the machine-readable one. Most organisations just have not noticed that they are paying for the conversion on every single query rather than doing it once.

Markdown is a better common language, and it is boring

That is precisely why it works. Headings, paragraphs, lists, tables, links, emphasis, code blocks, and almost no presentation complexity. Those constructs map cleanly onto how models read text. Rather than asking a model to infer that some large bold text is probably a heading, you tell it:

## Password Requirements

Rather than expecting it to rebuild a table from coordinates on a page, or to dig hierarchy out of Word styles, you state both directly. The structure stops being something to deduce.

One honest caveat, because it undercuts the tidy version of this argument. Markdown pipe tables cannot express merged cells or multi-row headers, which real enterprise documents are full of. Microsoft hit exactly this and changed the layout model in v4.0 so that tables inside its Markdown output are emitted as HTML tables instead, specifically to support merged cells and multi-row headers.¹ So the target is not "pure Markdown". It is Markdown as the structural backbone, with something richer where Markdown genuinely cannot carry the meaning.

Nobody is suggesting you rewrite 300,000 PDFs

This is where organisations need to be pragmatic, because the maximalist version of this idea is a two-year programme that delivers nothing. Nobody is going to hand-convert twenty years of corporate knowledge, and nobody should try. What you want is a transition with two different tracks.

For existing knowledge, run it through a document-understanding pipeline that recovers structure rather than one that flattens it. The difference is the whole game:

document -> structure -> sections -> tables -> relationships -> metadata -> Markdown

  not

document -> plain text

For new knowledge, which is where the real opportunity sits, Markdown becomes the canonical machine-readable representation from the start. The PDF becomes a publication artefact. The Word file becomes an authoring convenience. The Markdown becomes the knowledge. That is a far cheaper model to sustain, and it stops the problem growing while you are busy fixing the backlog.

Knowledge needs a lifecycle, not a migration project

Here is the mistake I would put money on organisations making. They will spend six months converting their knowledge into AI-readable formats, declare the programme a success, and then carry on producing Word documents for the next five years. Within two years they are exactly where they started, with a more expensive tooling estate.

Knowledge has to be treated as something continuously compiled:

Human authoring
      |
      v
Knowledge representation
      |
      v
   Validation
      |
      v
   Markdown
      |
      v
Knowledge processing
      |
      v
LLM / agent consumption
      |
      v
   Feedback
      |
      v
Knowledge update

The feedback arrow is the part that gets dropped, and it is the most valuable part. When an AI system working across your knowledge discovers that a policy is ambiguous, that two documents contradict each other, that a definition is missing, that a procedure references a system decommissioned in 2021, that a control has no supporting evidence, or that two teams use the same word to mean different things, that should not evaporate at the end of a chat session.

The AI is not only a consumer of your knowledge. It is the most thorough mechanism you have ever had for finding out where your knowledge is broken.

Markdown is not the answer either

To be clear, because this is where these arguments usually overreach: putting everything in Markdown does not solve knowledge. It solves a representation problem, which is one problem. It does nothing at all for provenance, authority, ownership, versioning, conflicts, effective dates, definitions, relationships, evidence, approval or historical state.

Those have to live around the content, which in practice means structured metadata attached to it:

---
title: Password Requirements
owner: Security
version: 4
effective_from: 2026-07-01
status: approved
source: Security Policy
---

## Password Requirements

Passwords must contain...

The Markdown carries the knowledge. The metadata says what that knowledge is, where it came from, and whether you should trust it today. Once AI systems start making decisions on the strength of organisational knowledge, the second half stops being administrative tidiness and becomes the thing that decides whether the decision is defensible.

We do this to ourselves, for what it is worth. Our own compliance standards are authored as Markdown with a structured metadata block at the top, and the build refuses documents whose metadata is incomplete. It is not glamorous. It does mean that when an assistant cites one of our standards, the version and the approval state come along with the text rather than being reconstructed by somebody later.

Why this shows up in retrieval quality

There is a measurable payoff, and it lands in the least glamorous place: chunking. With a flat text dump you retrieve something like this:

PDF page 37
characters 4,812-7,921

With structure preserved you retrieve something that knows where it lives:

Security Policy
  -> Authentication
    -> Password Requirements

The chunk carries its own context. This is the same problem Anthropic set out to fix with contextual retrieval, and the numbers are worth quoting because they are larger than most people expect. Prepending chunk-specific context before embedding cut the top-20 retrieval failure rate by 35%, from 5.7% to 3.7%. Combined with contextual BM25 it fell 49%, to 2.9%. Adding reranking took it to 1.9%, a 67% reduction overall.²

Read that as an architecture argument rather than a tuning tip. Two thirds of your retrieval failures were never a model problem or an embedding problem. They were a context problem, created upstream, at the moment a document became a pile of characters.

The uncomfortable bit

A lot of organisations are about to discover that they do not have an AI-ready knowledge base. They have a document archive, and those are different things with different purposes.

A document archive is built to answer "where is the document". An AI knowledge system has to answer "what do we know", and then immediately afterwards it has to answer the harder ones: why do we believe it, where did it come from, is it still true, what contradicts it, who owns it, and what changed. That is a considerably bigger problem than RAG, and it is why loading PDFs into a vector database is a procurement decision rather than a knowledge strategy.

It was never PDF versus Markdown

PDF is not going anywhere and should not. The likely end state is human-readable publication alongside machine-readable knowledge: the PDF stays the thing people download, the Markdown becomes the thing machines consume, structured metadata governs both, and a pipeline keeps them aligned so they cannot drift apart.

Organisations that get this right will not merely have better AI search. They will have knowledge that can be consumed, reasoned over, challenged, updated and governed by machines without first reverse-engineering how somebody formatted a document in 2019.

That is the actual transition, and it is not documents to AI. It is documents to knowledge.

• AppGenie Compliance MCP