---
title: How to Preserve Version History in Knowledge Base Migrations
slug: how-to-preserve-version-history-in-knowledge-base-migrations
date: 2026-09-25
author: Raajshekhar Rajan
categories: [Knowledge Base, Migration Guide, Confluence]
excerpt: Most KB exports flatten content to the current revision. Learn which platforms expose version history via API and three strategies to preserve it during migration.
tldr: "You usually cannot recreate native page history in a new KB. Decide early whether to flatten and archive, export revisions as artifacts, or keep the source read-only — compliance requirements usually decide for you."
canonical: https://clonepartner.com/blog/how-to-preserve-version-history-in-knowledge-base-migrations
---

# How to Preserve Version History in Knowledge Base Migrations


Most knowledge base migrations silently destroy version history. Every standard export — Confluence XML, Zendesk CSV, Notion markdown — flattens content to the current revision. The audit trail of who changed what and when vanishes the moment you import into the new platform.

The problem is architectural, not operational. Every knowledge base models page history differently, and target platforms do not accept version data through their import pathways. You cannot `POST` an array of historical revisions into a new system and expect it to render a native, interactive timeline of past edits.

For IT and compliance teams, losing this metadata is not just an inconvenience — it can violate change management controls required by SOC 2, SOX, HIPAA, and industry-specific regulations.

This guide covers which platforms expose version history via API, why importing historical states into a new system is functionally impossible, and the three strategies engineering teams use to preserve audit trails during migration. If you're planning the broader cutover, pair this with our [knowledge base migration checklist](https://clonepartner.com/blog/blog/the-ultimate-knowledge-base-migration-checklist-a-zero-downtime-plan).

## Why version history gets lost during migration

**Version history loss** happens for two reasons: export formats strip revisions, and target APIs refuse to backdate metadata.

On the export side, standard formats are designed for content portability, not revision fidelity. A Confluence XML export contains the current page body. A Zendesk CSV contains the latest article HTML. A Notion markdown export contains the live block content. None include previous revisions, diff data, or per-version author metadata.

On the import side, target platforms enforce system-generated metadata. When you create a document via API, the platform records the `created_at` timestamp as the moment the API call was processed and the `author_id` as the user whose token authenticated the request. There is no mechanism to override these fields with historical values.

The incompatibility runs deeper than timestamps. Each platform stores revisions using a fundamentally different model:

- **Confluence** stores each save as a numbered version with full XHTML body snapshots, tracking macro state changes across versions.
- **Notion** captures snapshots roughly every ten minutes during editing, with retention tied to plan tier — 7 days on Free, 30 on Plus, 90 on Business, unlimited on Enterprise. ([notion.com](https://www.notion.com/help/duplicate-delete-and-restore-content?utm_source=openai))
- **SharePoint** versions list items and documents independently, with admin-configurable retention limits.
- **Document360** separates major "versions" (published milestones) from minor "revisions" (edits and drafts).
- **Zendesk Guide** separates "revisions" (title and body changes) from "article history" (publishing events, section moves, label updates).
- **Guru** tracks version history at the card level with content snapshots per version.

Because there is no universal standard for document history, a 1:1 migration of revision data across ecosystems is rarely possible.

The one exception: **same-ecosystem migrations**. Atlassian documents page-history migration inside the Confluence Cloud Migration Assistant, and Microsoft documents version-history preservation inside SPMT. If your move stays within a vendor ecosystem, native history preservation can be realistic. Once you cross ecosystems, assume you need a separate preservation strategy until a pilot proves otherwise. ([support.atlassian.com](https://support.atlassian.com/migration/docs/what-migrates-with-the-confluence-cloud-migration-assistant/?utm_source=openai))

## Which platforms expose version history via API?

This is the first question to answer before you plan anything. If the source platform doesn't expose revision data programmatically, your options narrow immediately.

### Confluence: full version history via API

Confluence is the most migration-friendly source for version history. <cite index="5-3,5-6">Confluence Cloud provides an endpoint that returns all versions: `/wiki/rest/api/content/{id}/version`.</cite> You can expand the response to include the body content of each version, giving you a full snapshot of the page at every save point. <cite index="1-8">The "Get content version" endpoint returns metadata including the user who made the change and the timestamp.</cite> To get the actual body of a historical version, you request it per version number — it doesn't come by default.

<cite index="5-1,5-4">On Confluence Server/Data Center, the `/rest/api/content/{id}/history` endpoint is more limited: it returns the current version, previous version, next version, and last updated.</cite> <cite index="3-9">An experimental endpoint at `/rest/experimental/content/{pageId}/version` can return all versions in a single call</cite>, but availability varies by Server version.

Atlassian changed `body-format` version-listing calls on June 1, 2026 to a maximum of 50 results per request, so long-lived pages need pagination. ([developer.atlassian.com](https://developer.atlassian.com/cloud/confluence/changelog/?utm_source=openai))

**Bottom line:** You can script a full extraction of every version of every page — body content, author, and timestamp. Cloud is well-supported; Server/Data Center requires more care.

### SharePoint: version history available but admin-scoped

<cite index="21-3,21-4">SharePoint can be configured to retain version history for list items, with retention periods depending on admin settings that may be unique per user or location.</cite> The Microsoft Graph API exposes version data via <cite index="21-10">`GET /sites/{site-id}/lists/{list-id}/items/{item-id}/versions`</cite>, and Graph v1.0 lists drive item versions for files. ([learn.microsoft.com](https://learn.microsoft.com/en-us/graph/api/driveitem-list-versions?view=graph-rest-1.0))

<cite index="22-1">The API returns the value of all fields for each version, along with created date, created by, modified date, modified by, version label, version ID, and a boolean flag indicating whether the version is current.</cite> The catch: <cite index="19-5,19-6">pages that moved from a published state to a draft or checked-out state present challenges, as retrieving the last published state through the API isn't straightforward.</cite> Rate limits are aggressive when iterating through thousands of historical list items.

Microsoft says SPMT can migrate the latest file version, all versions, or a selected number when staying within the Microsoft ecosystem.

**Bottom line:** SharePoint exposes good version data for list items and documents, but page content versioning through the Graph API has gaps. Check your admin-configured version limits before assuming the full history exists.

### Document360: full revision history via API

<cite index="43-1">Document360 provides a dedicated endpoint: `GET /v2/Articles/{articleId}/{langCode}/versions`</cite> that returns all article versions. <cite index="37-12,37-13,37-14,37-15">Revision history in Document360 lets you track, compare, and manage every version of an article. When a published article is edited, a new unpublished version is created automatically, while the previous version remains live until the new version is published.</cite>

Rate limits are plan-based: 60 requests per minute per token on Professional and Business, 100 on Enterprise and Trial. <cite index="41-5">API v3 is a ground-up rebuild of Document360's public REST API</cite> that expands automation capabilities further.

**Bottom line:** Document360 is one of the better platforms for version-history extraction. Full revision data is API-accessible with version numbering, timestamps, and contributor info.

### Guru: version history via API

Guru documents `GET /api/v1/cards/{cardId}/versions` and `GET /api/v1/cards/{cardId}/versions/{version}`, and the historical response includes the card's past content. ([developer.getguru.com](https://developer.getguru.com/docs/historical-card-versions?utm_source=openai))

**Bottom line:** Guru is one of the cleaner source systems for revision export. The API returns historical card content, making automated extraction feasible.

### Notion: no API access to page history

<cite index="14-1">You can view and restore past versions of any Notion page going back 30 days on a Personal or Team Plan, and indefinitely on an Enterprise Plan.</cite> <cite index="14-9">A new version is captured every ten minutes while you're making changes and two minutes after you stop.</cite>

But the Notion API does not expose page revision history. <cite index="55-1,55-2">Users trying to retrieve page revision history using the Notion API have found no endpoint available.</cite> The API returns only the current state of blocks and pages. For enterprise customers, the Audit Log API provides workspace-level events ("User A edited Page B"), but it does not return the actual content of the edit.

Notion's help center also notes that version history "shows the main highlights" and "won't capture every single change." Safe for rollback is not the same as safe for compliance. ([notion.com](https://www.notion.com/help/duplicate-delete-and-restore-content?utm_source=openai))

**Bottom line:** If you're migrating out of Notion and need version history, the API can't help. Your options are the native workspace export (which generates HTML/PDFs of versions), keeping the Notion workspace alive as a read-only archive, or accepting the loss.

### Zendesk Guide: no API access to revisions

<cite index="46-3,46-4">Zendesk Guide separates revisions (body and title changes) from article history (publishing events, author changes, label updates, section moves).</cite> Both are visible in the UI. Neither is available via API.

<cite index="47-2,47-3">Users have requested that article revision history be available in the API</cite>, but as of mid-2026, no such endpoint exists. <cite index="53-1">The API only retrieves the latest version of a Guide article.</cite> If content blocks are enabled, the API flattens them to inline text on GET and PUT. ([support.zendesk.com](https://support.zendesk.com/hc/en-us/articles/4408829321498-Viewing-article-revisions-and-restoring-a-previous-version?page=2&sort_by=created_at&sort_order=desc&utm_source=openai))

**Bottom line:** Zendesk Guide is one of the hardest platforms to extract version history from. If revision history matters, plan around its absence before decommissioning. For more on what you can and can't get out of Zendesk Guide, see our [export methods guide](https://clonepartner.com/blog/blog/how-to-export-data-from-zendesk-guide-methods-limits-formats).

> [!WARNING]
> **Check your tier limits.** Many platforms restrict version history retention based on pricing tier. Notion Free limits history to 7 days; Enterprise offers unlimited. Document360 separates major versions from minor revisions. If you upgrade specifically for a migration, you cannot recover history that was already purged under your previous tier's retention policy.

## The three strategies for handling version history

Every knowledge base migration involving version history comes down to one of three approaches. The right choice depends on compliance requirements, the source API's capabilities, and how long you can keep the old system running.

### Strategy 1: Flatten and archive the source

**Migrate only the current version of each article into the new platform.** Preserve the source as a read-only archive, an offline export, or both.

This is the right default when history is useful but not regulated. You get a clean migration without fighting version-format incompatibilities, and the new knowledge base stays performant.

**How to execute:**

1. Take a full export of the source platform in its native format (XML, JSON, HTML backup).
2. Store that export in durable storage — an S3 bucket, a shared drive, or a document management system.
3. Migrate only current/published articles to the new platform.
4. Document the archive location and access procedure in your migration runbook.
5. Keep the export for at least as long as your retention policy requires.

Be careful with what "export" means. Confluence page export only includes the published version. Confluence HTML export omits page comments. Notion says exported workspaces cannot be instantly recreated by re-uploading the export. ([support.atlassian.com](https://support.atlassian.com/confluence-cloud/docs/export-content-to-word-pdf-html-and-xml/)) Treat these packages as archives of evidence, not as perfect recovery points.

**When this works:** Internal wikis, product documentation, support articles — anything where the primary need is "what does this say now" rather than "who changed this paragraph six months ago."

**When it doesn't:** Regulated environments where auditors need the full edit trail, SOPs tied to quality management systems, or any context where "show me the version that was live on this date" is a real business requirement.

At ClonePartner, we recommend this approach for the majority of IT teams. It satisfies standard audit requirements without over-engineering the migration.

### Strategy 2: Export each revision as a separate artifact

**Use the source API to pull every version of every article, store each revision as a discrete file, and organize them to preserve the relationship between revisions.** This is the heaviest-lift option, but it's the only one that gives you portable, platform-independent version data.

It only works when the source API exposes revision content — realistic for Confluence, SharePoint, Guru, and Document360, and infeasible for Notion and Zendesk Guide.

**How to execute:**

1. Enumerate all content items in the source (pages, articles, cards).
2. For each item, call the version-listing endpoint to get all revision numbers.
3. For each revision, extract the full body content, author, timestamp, and version metadata.
4. Store each revision as a file: `{article-id}/v{version-number}.html` (or `.json`).
5. Generate a manifest file mapping article IDs to revision lists with metadata.
6. Migrate the final version as the active text in the new knowledge base.
7. Upload or link the revision archive from the live article.

A simplified extraction for Confluence Cloud:

```python
import requests

BASE = "https://your-domain.atlassian.net/wiki/rest/api"
AUTH = ("user@example.com", "api-token")

def extract_all_versions(page_id):
    versions_url = f"{BASE}/content/{page_id}/version"
    resp = requests.get(versions_url, auth=AUTH)
    versions = resp.json()["results"]
    
    for v in versions:
        v_num = v["number"]
        content_url = f"{BASE}/content/{page_id}?version={v_num}&expand=body.storage,version"
        content = requests.get(content_url, auth=AUTH).json()
        yield {
            "version": v_num,
            "author": content["version"]["by"]["displayName"],
            "when": content["version"]["when"],
            "body": content["body"]["storage"]["value"]
        }
```

A revision archive works better when it's manifest-driven rather than ad hoc. A minimal manifest:

```yaml
source_system: confluence
source_page_id: 12345
source_path: /spaces/IT/pages/12345/VPN+Guide
target_article_id: kb-441
history_strategy: revision-archive
revisions:
  - revision: 1
    captured_at: 2024-02-14T12:34:56Z
    author: jane@example.com
    body_file: revisions/0001.html
  - revision: 2
    captured_at: 2024-03-01T09:10:11Z
    author: alex@example.com
    body_file: revisions/0002.html
checksums:
  0001.html: sha256:...
  0002.html: sha256:...
```

> [!WARNING]
> **Budget for scale.** A 500-page Confluence space averaging 15 versions per page means 7,500 API calls for body content alone. Confluence Cloud throttles to roughly 5–10 requests/second depending on your tier. Document360 caps at 60 requests per minute on Professional/Business, 100 on Enterprise. Plan for a multi-hour extraction window.

> [!NOTE]
> **Handle inline images in historical artifacts.** If you render historical versions as HTML files, ensure any inline images referenced in that HTML are downloaded and base64-encoded or re-hosted. If you leave `src` attributes pointing at the old platform, images break the moment you decommission the source system.

This approach is strong for auditability but weak for editor ergonomics. Writers cannot click "restore version 14" inside the new KB — what you preserved is the evidence and content of prior revisions, not the source platform's editorial workflow.

**When this works:** Compliance-driven migrations where you need a durable, auditable archive. Teams decommissioning a platform they cannot keep alive.

**When it doesn't:** When the source API doesn't expose version history (Notion, Zendesk Guide). When revision volume makes extraction impractical within your migration timeline. When a document with 50 minor edits would generate 50 PDF attachments and blow up storage costs.

### Strategy 3: Keep the old system read-only as the system of record

**Instead of extracting version history, leave the old platform running in a read-only state.** It becomes the system of record for all historical revisions; the new platform is the system of record going forward.

This is the pragmatic middle ground. You avoid the complexity of extracting and reformatting version data while maintaining access to historical revisions through the original UI — including native diff views, approval comments, publish states, and macro rendering that export packages rarely preserve cleanly.

**How to execute:**

1. Migrate current content to the new platform.
2. Downgrade the old platform to the cheapest plan that supports read-only access (or convert all users to viewer-only roles).
3. Remove all write permissions. Disable new account creation.
4. Preserve SSO access for a small admin or compliance group.
5. Record source page IDs on target articles so users can navigate between systems.
6. Set a calendar reminder to evaluate ongoing cost vs. value at 6-month intervals.

For on-premise systems like Confluence Server, this means locking the instance behind a VPN rather than paying for a SaaS subscription.

**The cost question:** Keeping a second platform running is not free. But for many SaaS knowledge bases, the cost of the lowest read-only tier is significantly less than the engineering effort to extract, store, and index every historical revision. Run the math for your specific situation — teams are often surprised that retaining a limited-access source environment is cheaper than engineering a synthetic audit trail.

**When this works:** Migrations from platforms with no version-history API (Notion, Zendesk Guide). Organizations that need occasional access to historical edits but don't need to hand an auditor a portable file. Massive enterprise instances where extracting terabytes of revision data would cost more than years of read-only licensing.

**When it doesn't:** When the vendor is sunsetting the product or you're contractually obligated to decommission. When "keep paying for two platforms" is a non-starter politically or financially. When retention requirements extend 7+ years and the carry cost becomes untenable.

## How compliance requirements change the answer

Compliance doesn't just influence the strategy — it often eliminates options entirely. Your migration strategy cannot be decided by IT alone; it must be cleared by compliance and legal teams.

Different frameworks impose different retention periods and levels of proof regarding document history:

| Compliance regime | Retention period | Impact on version-history strategy |
|---|---|---|
| **SOX** | 7 years | If documentation supports financial reporting, version history is part of the audit trail. Strategy 1 is acceptable only if the archive is durable and searchable. Strategy 3 works only if you commit to 7 years of subscription costs. |
| **HIPAA** | 6 years | Policies, procedures, and compliance documentation must be retained with version trails. Strategy 2 is the safest path for portability. |
| **FDA 21 CFR Part 11** | Varies by record type | Requires secure, computer-generated, time-stamped audit trails that independently record operator entries and actions. If you are migrating SOPs governed by Part 11, Strategy 3 is often the safest route, as proving the integrity of extracted JSON payloads to an FDA auditor is expensive. ([govinfo.gov](https://www.govinfo.gov/content/pkg/CFR-2023-title21-vol1/pdf/CFR-2023-title21-vol1-sec11-10.pdf?utm_source=openai)) |
| **PCI DSS 4.0** | 12 months (3 months hot) | Change logs for security-related documentation must be accessible. Strategy 1 is usually sufficient. |
| **ISO 27001** | No mandated period | Auditors expect evidence of policy versioning. Any strategy works if you can demonstrate change tracking. Flattening history into PDF artifacts (Strategy 2) is effective for ISO audit walkthroughs. |
| **SOC 2 (CC8.1)** | No mandated period | Requires proof that changes to security policies were authorized. Strategy 1 is usually sufficient, provided the archive clearly shows author IDs and timestamps. |

<cite index="71-2,71-3">Regulatory investigators require historical documentation to verify compliance during the time an alleged breach or violation occurred. Failure to produce historical security policies or assessments can lead to immediate audit failures and significant financial penalties.</cite>

> [!CAUTION]
> If your knowledge base contains SOPs, security policies, or compliance documentation, do not assume that "we exported the articles" satisfies retention requirements. Your compliance team or legal counsel needs to confirm whether edit history is in scope. Ask this question before the migration, not after you've decommissioned the old platform.

Remember that source-platform history may itself be incomplete. Notion says version history "shows the main highlights" but won't capture every single change. Zendesk says inline CSS changes are not tracked in article revision history. When someone says "the source has history, so we're safe," verify what that history actually contains.

## What metadata to preserve even when you flatten

Even when you accept the flattening, preserve enough metadata to reconstruct provenance later. A flat article with no source identifiers is not archived — it is orphaned.

At minimum, capture:

- **Source page ID** and **source URL or path**
- **Source workspace, space, or site**
- **Current source version number** and **total revision count** (if available)
- **Last modified timestamp** and **last modified by**
- **Locale or language**
- **Visibility and permission model**
- **Attachment inventory** and rewritten asset paths
- **Archive package location** and **checksum/hash** for the exported package
- **User map** if authorship may matter later

That small manifest turns a future audit request from a scavenger hunt into a lookup operation. It also gives you something concrete to validate during UAT.

## Most target platforms cannot import version history

Even if you successfully extract every revision from the source, the target knowledge base almost certainly won't let you import them as native version history. This is the uncomfortable truth that shapes every strategy.

- **Confluence** is the closest exception — you can programmatically create a page and then issue sequential updates to build a version chain. But each update gets stamped with the import time, not the original edit time, and original authors won't map unless you impersonate users via the API.
- **SharePoint** supports versioning on list items and documents, but bulk-importing versions with original metadata is a non-trivial admin task.
- **Notion, Zendesk Guide, Document360, Guru** — none of these support importing article version history via their APIs. You get the current version, period.

This is why Strategy 2 produces an archive, not a live version chain in the target. The extracted revisions live in blob storage, Git, or a document management system — accessible for reference and compliance, but not inside the new knowledge base UI.

Do not sell Strategy 2 internally as "history preserved in the new KB." Say what it really is: **current content migrated, source history archived and linked**.

## How to decide before you start

The version-history question must be answered in the planning phase, not discovered mid-migration when someone asks "where did all our old revisions go?" By UAT, teams have usually written extraction scripts for current content, started decommissioning the legacy tool, and scoped testing around formatting, links, and permissions. That is exactly when someone notices that Notion exports aren't re-importable, Confluence page exports only include published versions, or Zendesk content blocks were flattened on API retrieval. Every late request to also preserve history lands on mapping, storage, permissions, QA, and sign-off at the same time. It is one of the most expensive late changes you can make in a knowledge base migration.

Use this decision sequence:

1. **Inventory your content for version-history requirements.** Not all content needs an edit trail. Tag which articles fall under regulatory retention — SOPs, policies, compliance records. For most teams, it's 10–20% of total articles.

2. **Check whether the source API exposes version data.** Confluence, Document360, SharePoint, and Guru expose revision content. Notion and Zendesk Guide do not. If the source API doesn't support extraction, your realistic choices narrow to Strategy 1 or Strategy 3.

3. **Calculate the artifact volume.** Query a sample of 100 documents. If the average document has 40 revisions and you have 10,000 documents, Strategy 2 will generate 400,000 artifacts. If your target charges per GB of storage, this may blow up your budget.

4. **Check whether the target platform can ingest version data.** Most import pathways create a single new article with no version history. If the target can't accept historical versions, extracted data goes into an archive, not the new knowledge base.

5. **Define the cutoff date.** Does legal actually need history from 2016? Many teams agree to a compromise: migrate the current state, archive the last 2–3 years of history, and permanently delete anything older per data retention policies.

6. **Get sign-off from compliance and legal.** Get written answers: Does your retention policy cover edit history or just the final published version? How long must revisions be retained? Does the archive need to be searchable, or just retrievable? Can you satisfy requirements by keeping the old platform on a read-only plan?

7. **Document the decision in your migration runbook.** Record which strategy you chose, why, what content categories are affected, where the archive lives, and who owns ongoing access. This is your paper trail if an auditor asks why version history is missing from the new system.

### A practical decision tree

Before you start build work, walk through this:

1. **Does any of your content fall under a regulatory retention requirement?**
   - No → Strategy 1. Migrate current content, archive the source export, move on.
   - Yes → Continue.

2. **Does the source platform expose version history via API?**
   - Yes (Confluence, Document360, SharePoint, Guru) → Strategy 2 is feasible. Extract all revisions to portable storage.
   - No (Notion, Zendesk Guide) → Strategy 3. Keep the old platform alive in read-only mode until the retention period expires.

3. **Can you commit to paying for the old platform for the full retention period?**
   - Yes → Strategy 3 is the lowest-effort path.
   - No → Strategy 2 (if the API supports it) or negotiate with the vendor on data export options.

4. **Is the old platform being sunset or decommissioned by the vendor?**
   - Yes → Strategy 2 is your only option. Extract everything now, while you still can.
   - No → Strategy 3 buys you time while you build the extraction tooling if needed.

> [!WARNING]
> If a migration proposal says it preserves version history, ask for one sample page with 20+ revisions, mapped timestamps, and a restore test in the destination. If they cannot show that, they are preserving current content or archived evidence — not native history.

## Plan for history before you migrate

Version history is one of those migration requirements that teams discover too late. By the time someone asks "can we see who edited this policy last year," the old platform is already gone, the export only contains current content, and the answer is "no."

The fix is straightforward: inventory your content, check your compliance obligations, and test the source API's version endpoints before you write a single line of migration code. The right strategy depends entirely on your regulatory context, source API capabilities, and platform pair — there is no universal answer.

What we can say from running migrations across Confluence, SharePoint, Zendesk Guide, Notion, Document360, and Guru: the teams that plan for version history up front never regret it. The ones that don't always do. For the broader cutover workflow, use our [knowledge base migration checklist](https://clonepartner.com/blog/blog/the-ultimate-knowledge-base-migration-checklist-a-zero-downtime-plan). For extraction logic, replay testing, and sign-off patterns, see [How to Build a Data Migration Playbook](https://clonepartner.com/blog/blog/how-to-build-a-data-migration-playbook-tools-validation-tests).

> Migrating a knowledge base and need to preserve version history for compliance? We've handled this across Confluence, SharePoint, Zendesk Guide, Notion, Document360, and more. Book a 30-minute call and we'll map out the right strategy for your platform pair and regulatory requirements.
>
> [Talk to us](https://clonepartner.com/talk-to-us?duration=30&utm_source=blog&utm_medium=button&utm_campaign=demo_bookings&utm_content=cta_click&utm_term=demo_button_click)

## Frequently asked questions

### Can you import version history directly into a new knowledge base?

Almost never. Most knowledge base APIs do not allow you to backdate timestamps or assign historical author IDs. When you create content via API, the target platform stamps the current date and the API token owner as the author. Confluence is the closest exception — you can replay sequential updates to build a version chain — but you still lose original timestamps and author mappings.

### Does the Zendesk Guide API support exporting article revision history?

No. Zendesk Guide tracks revisions and article history in the UI, but no API endpoint exists to retrieve previous versions. The API only returns the current published version. If revision history matters, keep the old Zendesk instance alive in read-only mode or accept the loss.

### Does the Notion API expose page revision history?

No. Notion stores page history in the UI (30 days on Team plans, unlimited on Enterprise), but the API only returns the current state of blocks and pages. There is no endpoint to retrieve previous revisions programmatically.

### What is the best way to preserve version history during a knowledge base migration?

It depends on your source platform and compliance requirements. If the source API exposes version history (Confluence, Document360, SharePoint, Guru), extract every revision to portable storage. If it doesn't (Notion, Zendesk Guide), keep the old platform alive in read-only mode. If you have no regulatory obligation, migrate current content only and archive the source export.

### How long do you need to keep document version history for SOX compliance?

SOX requires seven-year retention for audit-related records. If your knowledge base articles include SOPs, policies, or documentation supporting financial reporting, version history may be considered part of the audit trail and subject to the same retention period.