Quip to SharePoint Migration: The Complete Technical Guide

There is no native migration path from Quip to SharePoint. No import wizard, no connector, no "Move to SharePoint" button. Salesforce has announced the full retirement of all Quip products — subscriptions cannot be renewed after March 1, 2027 — and once your subscription expires, your data enters a countdown toward permanent deletion. If you are planning a Quip to SharePoint migration, the clock is running.

This guide covers the real extraction methods, the architectural mismatches between the two platforms, the specific data types that break during migration, and a step-by-step technical workflow using the Quip Automation API and Microsoft Graph API.

The Quip to SharePoint Migration Challenge

Quip and SharePoint store content in fundamentally different ways. Understanding these differences before you write a single script is the difference between a clean migration and weeks of post-migration cleanup.

Quip stores everything as threads — a single content object that can be a document, a spreadsheet, or a chat. Each thread has a permanent 11-character alphanumeric ID (e.g., AbCdEfGhIjK) and an expirable secret-path URL. A thread contains rich text (HTML), embedded spreadsheet grids, inline images stored as blobs, a conversation pane with comments, and optionally Live Apps like Salesforce Record embeds or Kanban boards. A Quip spreadsheet has a recommended ceiling of 30,000 cells for performance.

SharePoint Online stores content in Document Libraries as files (DOCX, XLSX, PDF), on Site Pages as .aspx files built from Web Part JSON structures, and in Lists as typed columns with managed metadata taxonomies, content types, and granular permission inheritance — none of which exist in Quip.

The gap is wide. Every migration from Quip to SharePoint requires extraction, transformation, and loading — there is no shortcut.

Quip Folders vs. SharePoint Document Libraries

The biggest structural trap in a Quip to SharePoint migration is folder resolution.

In Quip, folders act like tags. A single document can exist in multiple folders simultaneously. There is no canonical "parent folder" — a document might appear in Sales/Q4 Plans and Executive/Reviews at the same time. Quip's API returns a list of folder IDs for each thread but does not designate a primary location.

SharePoint Document Libraries enforce a strict hierarchy. A file lives in exactly one location: /sites/Sales/Shared Documents/Q4 Plans/doc.docx. There are no symbolic links, no multi-parent folders.

If you skip canonical folder resolution and mirror every folder membership, you will either duplicate files across multiple libraries (inflating storage and creating version-control chaos) or silently drop secondary folder associations.

How to Resolve Canonical Folders

1. Export the full folder tree using the Quip Admin API's Get Folder and Get Folders (bulk) endpoints.
2. Build a thread-to-folders mapping — for each thread ID, collect all parent folder IDs.
3. Apply a canonical rule: choose the deepest (most specific) folder path, use an explicit mapping file maintained by content owners, or prefer a shared folder over a private one. Document the rule and apply it consistently.
4. Log secondary associations as SharePoint metadata columns (e.g., a multi-value "Quip Folders" text field) so the information is preserved without creating duplicate files.

For guidance on designing your target SharePoint structure, see our guide on SharePoint Information Architecture: Content Types, Metadata & Lists. If you are still deciding between hub sites and subsites, read Modern SharePoint Architecture: Hubs vs. Subsites.

Choose the Right SharePoint Target Before You Export

A Quip to SharePoint migration is a three-lane migration, not a one-click export. There are three viable end states, and the right choice can differ by folder — not just by workspace:

• Archive-first: Export DOCX, XLSX, PDF, or HTML and store them as files in Document Libraries. Best for finalized documents, contracts, and design exports.
• Experience-first: Use HTML plus message and blob extraction to rebuild article-style content as SharePoint Site Pages. Best for SOPs, knowledge articles, and frequently browsed content.
• Data-first: Reshape spreadsheet content into SharePoint Lists when the source is truly tabular. Best for trackers, registers, and structured metadata.

Site Pages are created via POST /sites/{site-id}/pages using the Microsoft Graph API. Pages must be published before they are visible, and if the site uses an approval flow, publication waits for that flow to complete. Graph page creation only supports documented standard web parts — unsupported pieces fail or require manual rebuild. (learn.microsoft.com)

Document Libraries accept standard file formats. Graph supports one-call uploads up to 250 MB and upload sessions for larger files. (learn.microsoft.com)

Lists work for row-based spreadsheet data. SharePoint can create a list from Excel or CSV, but Excel imports require the source to be a formatted table and support up to 5,000 rows. For repeatable or higher-volume loads, use Graph list item APIs. (support.microsoft.com)

Methods to Export Data from Quip

There are four realistic extraction methods. None of them are complete on their own.

Manual GUI Export

Quip's web UI lets you export individual documents to DOCX or PDF and spreadsheets to XLSX. There is no bulk export button — you repeat this for every single document. It silently drops inline comments and Salesforce Data Mentions. This works for a handful of files and nothing more.

For a comprehensive breakdown of Quip's native export capabilities, see How to Export Data from Quip: Methods, API Limits & Migration Prep.

Open-Source CLI: quip-export

The sonnenkern/quip-export tool is a Node.js CLI that recursively exports Quip folders to a local directory. It supports HTML and DOCX output and can optionally include embedded images, inline styles, and comments.

The critical limitation: the --comments, --embedded-images, and --embedded-styles flags do not work when exporting to MS-Office format (--docx). If you export to DOCX, you get the document body only — no comments, no embedded images, no custom styles. This is explicitly documented in the tool's README. (github.com)

npx quip-export \
  --token "YOUR_QUIP_ACCESS_TOKEN" \
  --destination "./quip-output" \
  --folders "bGG333444111" \
  --embedded-images \
  --comments

This exports to HTML with comments and images. For SharePoint migration, HTML is the better intermediate format — it preserves more structure than DOCX and is easier to parse programmatically.

Quip Automation API (Custom Scripts)

The Quip Automation API gives you the most control. Key endpoints for migration:

• Get Thread (/1/threads/{thread_id}) — returns the document body as HTML, plus metadata (title, author, creation time, last modified, folder IDs)
• Export Document to DOCX (/1/threads/{thread_id}/export/docx) — returns a DOCX file
• Export Spreadsheet to XLSX (/1/threads/{thread_id}/export/xlsx) — returns an XLSX file
• Create Bulk Export Request (/1/threads/export/bulk) — asynchronous export of multiple documents; the include_conversations option only applies to DOCX and XLSX exports
• Get Recent Messages (/1/messages/{thread_id}) — returns the 25 most recent comments per call, supports cursor-based pagination
• Get Blob (/1/blob/{thread_id}/{blob_id}) — downloads an inline image or attachment

Rate limits are hard. The Bulk Export API has a per-company limit of 36,000 documents exported per hour. The general Automation API enforces approximately 100 requests per minute per user and 600 requests per minute per company. API responses include X-Documentbulkexport-RateLimit-Remaining and X-Documentbulkexport-Retry-After headers — your script must read these and implement backoffs. When bulk export limits are hit, Quip returns an HTTP 503 error, not a standard 429. (quip.com)

import requests
import time
 
QUIP_BASE = "https://platform.quip.com"
HEADERS = {"Authorization": "Bearer YOUR_ACCESS_TOKEN"}
 
def export_thread_html(thread_id):
    """Fetch thread HTML with rate-limit awareness."""
    resp = requests.get(
        f"{QUIP_BASE}/1/threads/{thread_id}",
        headers=HEADERS
    )
    remaining = int(resp.headers.get("X-Ratelimit-Remaining", 100))
    if remaining < 10:
        retry_after = int(resp.headers.get("X-Ratelimit-Reset", 60)) - int(time.time())
        time.sleep(max(retry_after, 1))
    return resp.json()

iPaaS Tools (Zapier / Make)

Zapier offers a Quip-to-SharePoint integration, but the available triggers are event-driven — things like "New Folder" or "New Document." These triggers cannot recursively paginate through historical documents, extract nested folder structures, or pull comment threads. SharePoint file triggers on Zapier return a maximum of 100 files per poll and do not process subfolders. (zapier.com)

Quip's July 18, 2025 release notes indicate that legacy out-of-the-box integrations such as Zapier are being retired, making this path even less viable.

iPaaS tools can be useful for ongoing sync after migration (e.g., routing new Quip documents to SharePoint during a transition period) but are not viable for bulk historical migration.

Microsoft Purview DataParser

Microsoft Purview offers a Quip DataParser connector via 17a-4 LLC. This tool converts Quip data to an email message format and imports it into user mailboxes in Microsoft 365 for compliance purposes (Litigation Hold, eDiscovery, retention). It does not import content into SharePoint Document Libraries or Site Pages. It cannot import attachments larger than 10 MB. It is an archiving tool, not a migration tool.

Data Types, Formats, and Field Mapping

Quip's documented export surface is DOCX, XLSX, HTML, and PDF, plus JSON API responses for threads, folders, messages, and blobs. If you need CSV, XML, or custom JSON manifests, those are transform-stage outputs you create after extraction. SharePoint can store those files in libraries, but only page payloads go into Site Pages and only row-and-field payloads go into Lists. (quip.com)

A practical field-mapping reference:

Store original authorship and timestamps explicitly in custom columns. Graph list item and file creation APIs set createdBy and lastModifiedBy to the account performing the upload, not the original author. If original attribution matters, you must preserve it in separate fields. (learn.microsoft.com)

What Breaks During Migration (and How to Fix It)

Every Quip to SharePoint migration has the same failure modes. Here is what breaks and the engineered fix for each.

Embedded Spreadsheets in Documents

Quip allows inline spreadsheet grids inside documents — a single thread can contain paragraphs of text, an embedded spreadsheet, and more text below it. When exported to DOCX, these embedded spreadsheets are converted to Word tables, which frequently suffer from misaligned columns and character encoding issues (e.g., < and > symbols rendering incorrectly).

Fix: Export the document as HTML via the API. Parse the HTML to separate <table> elements from surrounding content. Import the spreadsheet portion as a standalone XLSX file into a SharePoint library, and reference it from the parent document via an embed link or hyperlink.

Comments and Conversation Threads

Quip's comment system is a conversation pane attached to each thread. Comments are not part of the document body — they exist in a separate data structure. The DOCX export (both GUI and API) does not include comments. The quip-export tool's --comments flag only works for HTML output.

Fix: Use the Get Recent Messages API endpoint (/1/messages/{thread_id}) to extract comments. This returns the 25 most recent messages per call and supports pagination via cursor. Paginate through the full history for each thread. Append the extracted comments as a formatted section at the end of the migrated SharePoint document, or store them in a separate associated file or list.

Internal Quip Links

Quip uses proprietary 11-character thread IDs for internal document links (e.g., https://yourcompany.quip.com/AbCdEfGhIjK). Quip also exposes expirable secret-path URLs. When documents are uploaded to SharePoint, both types of link point to a platform that will eventually cease to exist. SharePoint does not automatically remap URLs.

Fix: Build a link-mapping table during extraction — a dictionary of {old_quip_thread_id: new_sharepoint_url}. After uploading all documents to SharePoint, run a post-processing script that parses each document's HTML or DOCX XML, finds all URLs matching the Quip domain pattern, and replaces them with the corresponding SharePoint URLs.

Live Apps (Salesforce Records, Kanban Boards, Calendars)

Quip Live Apps are interactive widgets embedded in documents — Salesforce Record Cards, Kanban boards, calendars, and project trackers. These are proprietary Quip components. The Export Live App API only exports an HTML tag that functions within another Quip environment. SharePoint has no portable equivalent. New Live Apps stopped being available after March 5, 2025.

Fix: There is no automated conversion. Extract the underlying data (e.g., Salesforce record IDs, task lists) and recreate the functionality using SharePoint Lists, Power Automate flows, or embedded Power Apps. Alternatively, archive the Live App state as JSON or HTML evidence. This is manual reconstruction work.

Images and Attachments

Inline images in Quip documents are stored as blobs with unique blob IDs. The Get Blob API endpoint downloads them, but you need to handle them explicitly — they are not included in DOCX exports via the API or quip-export in Office format mode.

Fix: Parse the HTML body for <img> tags, extract the blob references, download each blob via the API, upload to the SharePoint document library or Site Assets, and rewrite the image src attributes to point to the new SharePoint URLs.

Formatting Drift

Quip's documentation notes that API exports can have minor formatting variations compared to the GUI. SharePoint Site Pages reject unsupported web parts entirely. Build test cases for tables, checklists, callouts, embeds, and very long documents before running the main load.

Step-by-Step Quip to SharePoint Migration Process

This is the technical workflow for an API-driven migration. It assumes you have admin access to both Quip and SharePoint Online, and a registered Azure AD app with Sites.ReadWrite.All permissions.

Step 1: Inventory Your Quip Workspace

Use the Admin API's List Company Threads endpoint to get every thread in your organization. This returns thread IDs, titles, types (document/spreadsheet/chat), last-modified timestamps, and owner information. Export this to a CSV — it becomes your migration manifest.

curl -H "Authorization: Bearer $ADMIN_TOKEN" \
  "https://platform.quip.com/2/admin/threads?company_id=YOUR_COMPANY_ID&count=50"

Paginate using the next_cursor field until all threads are collected. For each thread, classify it as a Site Page candidate, a library file, or a List candidate based on content type and your target architecture.

Step 2: Export the Folder Hierarchy and Resolve Canonical Paths

Use the Get Folders (bulk) endpoint to build the complete folder tree. For each folder, record its ID, name, parent folder ID, and list of child thread IDs. Build a tree structure and resolve canonical paths using the rules described in the folder resolution section above.

Step 3: Extract Document Content

For each document thread:

1. Fetch the HTML body via Get Thread — this preserves all formatting, inline images (as blob references), and table structures.
2. Fetch comments via Get Recent Messages — paginate to get the full comment history.
3. Download blobs — parse the HTML for blob references, download each via the Get Blob endpoint.
4. Log metadata — capture title, author, created_usec, updated_usec, folder associations, sharing permissions, thread ID, secret path, and original link.

For spreadsheet threads, use the Export Spreadsheet to XLSX endpoint directly.

For bulk extraction, send a bulk export request:

threads:
  - thread_id: AVN9AAeqq5w
    format: HTML
  - thread_id: UcZ9AAhvqrc
    format: XLSX
include_conversations: false

Quip returns a request_id; poll the bulk export response endpoint until each item is exported and downloadable. Respect the X-Documentbulkexport-* headers instead of hard-coding retry timing. (quip.com)

Step 4: Transform Content for SharePoint

Build a staging manifest that maps source identifiers to target types, canonical folders, target sites, and old-to-new URL placeholders. Then transform the content:

• For Document Libraries (files): Convert Quip HTML to DOCX using Pandoc or a similar converter. Rewrite image references to use relative paths. Bundle the DOCX and its images into a folder structure matching your resolved canonical paths.
• For SharePoint Lists (structured data): Parse Quip spreadsheet HTML tables into CSV or JSON. Map columns to SharePoint list fields. Handle type mismatches — Quip has no concept of managed metadata, choice fields, or person/group columns.
• For Site Pages: Map HTML content into SharePoint's canvasLayout JSON structure using text web parts. Flatten unsupported Quip constructs into text, image, or quick-links patterns. This is the most labor-intensive path and is only worth it if the content must be natively editable as a SharePoint page.

A minimal Site Page payload:

odataType: microsoft.graph.sitePage
name: launch-plan.aspx
title: Launch Plan
pageLayout: article
showComments: true
canvasLayout:
  horizontalSections:
    - columns:
        - webparts:
            - kind: text
              innerHtml: <p>Converted Quip body</p>

(learn.microsoft.com)

Step 5: Upload to SharePoint via Microsoft Graph API

For files under 250 MB, use the simple PUT endpoint:

PUT https://graph.microsoft.com/v1.0/sites/{site-id}/drive/items/root:/{folder-path}/{filename}:/content
Authorization: Bearer {ACCESS_TOKEN}
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
 
[binary file content]

For files over 250 MB, create an upload session and upload in chunks (max 60 MiB per chunk, chunk size must be divisible by 320 KiB):

POST https://graph.microsoft.com/v1.0/sites/{site-id}/drive/items/root:/{folder-path}/{filename}:/createUploadSession

For Site Pages, use the pages API and publish after creation. If approval is enabled, publication waits for the approval flow to complete.

For list items, use POST /sites/{site-id}/lists/{list-id}/items.

Step 6: Set Metadata and Permissions

After uploading, update SharePoint metadata using the Graph API's list item endpoints. Map Quip metadata to SharePoint columns per the field-mapping reference above. Pay special attention to:

• Timestamps: Convert created_usec and updated_usec from Unix microseconds. Store in custom columns since Graph sets system dates to the upload time.
• Authors: Resolve Quip user IDs to Azure AD user IDs. If resolution fails, store as text in a custom column.
• Permissions: Quip uses user-level sharing; SharePoint uses groups and permission inheritance. This mapping is manual.

Step 7: Run Link Remapping and Delta Pass

Build a mapping file during extraction:

{
  "AbCdEfGhIjK": "https://yourcompany.sharepoint.com/sites/Team/Shared Documents/Folder/Doc.docx",
  "LmNoPqRsTuV": "https://yourcompany.sharepoint.com/sites/Team/Shared Documents/Folder/Report.docx"
}

Iterate through every migrated document. For DOCX files, open the underlying XML (DOCX is a ZIP archive), search for URLs matching quip.com/{11-char-id}, and replace with the corresponding SharePoint URL. For HTML files, use an HTML parser.

Once the base load is stable, run a delta pass — a second export using threads-modified-after-usec to pick up threads modified after your baseline extraction. Reload changed items. Only then cut users over to SharePoint. This keeps the editing-freeze window short. (quip.com)

Post-Migration Validation

Migration is not done when files are uploaded. Run a hard QA pass:

• Document count: Compare the total number of migrated files against your manifest.
• Content spot-check: Open 5–10% of documents and compare against Quip originals. Check headings, tables, and images.
• Image rendering: Verify inline images load correctly in SharePoint. Broken image references are the most common silent failure.
• Internal links: Click 10–20 internal document links to confirm they resolve to the correct SharePoint target. Search migrated HTML for leftover quip.com/ links.
• Spreadsheet integrity: Open migrated XLSX files and verify formulas, cell formatting, and data accuracy. Quip spreadsheet charts are excluded from API exports.
• Comment preservation: If comments were appended, verify they appear with correct author attribution and timestamps. Verify comment counts against the messages export.
• Metadata accuracy: Spot-check Created By, Modified Date, custom columns, and Quip source keys.
• Permissions: Verify document-level and library-level permissions. Quip's sharing model does not map 1:1 to SharePoint's permission inheritance.
• Page publication: Confirm every Site Page is published and not stuck in an approval queue.

Platform Limitations Reference

Quip Limits

SharePoint Online Limits

When to Use Each Migration Approach

Why DIY Scripts Fail at Scale

Writing a script that exports one Quip document and uploads it to SharePoint is straightforward. Making that script work reliably for 10,000+ documents with comments, images, folder resolution, and link remapping is a different engineering problem.

The failure modes at scale:

• Rate-limit crashes. The 36,000-document-per-hour bulk export limit sounds generous, but each comment thread requires separate API calls (25 messages per call with pagination), and each inline image requires a blob download. One miscalculated retry loop and your script stalls — especially since Quip returns HTTP 503 for rate limits, not the standard 429.
• Partial failures with no resume. If your script fails at document 7,000 of 10,000, you need idempotent logic to resume without duplicating the first 7,000 documents.
• Silent data loss. A comment thread with exactly 25 messages looks complete — but if there are 26, you have dropped the oldest one. Images that fail to download due to transient network errors are silently replaced with broken references.
• Folder duplication. Without canonical folder resolution, multi-folder documents create duplicates that are invisible until someone discovers two versions of the same file with different edit histories.

ClonePartner's migration engine handles all of these edge cases. We read the X-Documentbulkexport-RateLimit headers to execute intelligent backoffs, resolve Quip's tag-based folders into canonical SharePoint hierarchies, extract full comment threads via paginated Messages API calls, and dynamically remap every internal Quip link to its new SharePoint URL.

Making the Right Call

Quip to SharePoint migration is not a weekend project for anything beyond a small team's documents. The combination of Quip's tag-based folders, 11-character thread IDs, embedded spreadsheets, and separate comment threads creates a transformation problem that requires careful engineering.

The Quip EOL clock is running. After your subscription expires, you get 90 days of read-only access, then logins are blocked, then your data is deleted. Every month you delay reduces your margin for error.

Start with an inventory. Count your documents, spreadsheets, and folder structures. Estimate your API call budget against the rate limits. Decide whether comments and Live App data are worth preserving. Then choose the migration method that matches your scale and risk tolerance.