Coming Soon Join the waitlist for 30% off your first year of Folio Docs
Folio FolioSolutions
Join Waitlist

How to migrate from Quip to Folio Docs

Quip retires in March 2027. If your team keeps account plans, close plans, or case documentation in Quip, you need a destination and a plan to get there. This is the path we recommend, in the order we recommend it.

The short version: get the content out of Quip as files, land it in a sandbox, spend your manual effort only on the documents that deserve it, then move the finished result to production in one high-fidelity step.

Step 0 — Configure Folio Docs before you move anything

Migrating content into an unconfigured org wastes the effort. Record Links can only point at objects you’ve made linkable, Live Fields can only show fields you’ve allowed, and nobody can open a Document without the right permission set. Get that in place first — you can do it over a single cup of coffee.

The Setup Checklist walks the whole thing in order, but the parts that matter most for a migration are:

  • Prerequisites — Lightning Web Security has to be enabled. It’s the one hard dependency.
  • Permissions — the Folio Docs License permission set license for everyone, then Folio Docs User for people who’ll use it and Folio Docs Administrator for whoever runs the migration.
  • Linkable Objects and Fields — decide which objects Documents can attach to and which fields Live Fields can read. This directly bounds what Step 3 can do.
  • Document Editors on record pages — put the editor where your team already works, so migrated Documents are somewhere people will actually find them.

Do this in the sandbox first, then repeat it in production before the final import. The full Help Center covers the rest.

Step 1 — Export your documents out of Quip

Start in Quip. Export your documents as .docx or Markdown — both are formats Folio Docs imports.

Before you start, read Quip’s own documentation on exporting and check what its export includes and excludes for your org. That detail belongs to Quip, it might change, and you want the most up to date answer.

Plan for Live Apps to be left behind. Quip’s Live Apps — Kanban boards, calendars, project trackers, poll widgets — are not portable. They don’t export to .docx or Markdown in any usable form, and that isn’t specific to Folio Docs; they can’t move to any other tool either. Whatever a Live App is doing today, budget for rebuilding it or leaving it out, rather than migrating it.

The good news is that most of them have a natural replacement in Folio Docs. A Quip project tracker becomes a Folio Kanban Board or Related List pointed at real Salesforce records — which is a better artifact than what you had, because it reads live from your CRM instead of being a table someone updates by hand.

Step 2 — Import into a full-copy sandbox first

Don’t import straight to production. Spin up (or refresh) a full-copy sandbox and do the work there.

In the sandbox, go to Folio Admin → Migration → Import, upload your exported files, and run the job. A few limits worth knowing before you start:

  • 500 files per job. Larger sets need to be split, and the app will tell you so at submission rather than failing halfway.
  • 5 MB per file.
  • Import is text only. Images in the source files are skipped and noted in the job log. That’s usually why a file is near the size limit in the first place — stripping images generally brings it under.

Every file becomes one Folio Document, owned by whoever ran the import. Anything the importer can’t carry across is written to the job log rather than failing the file, so one bad document never stops the batch.

Step 3 — Decide which documents deserve real work

This is the scoping step that’s easy to skip, but important not to.

An imported document is faithful text. It is not yet a Folio document — it has no Record Links, no Live Fields, no Salesforce Components. Adding those is manual, and doing it for every document you’ve ever written is neither realistic nor useful.

Triage instead. The documents worth enriching are the ones that are:

  • Still relevant or being used. If nobody has opened it in two years, it’s an archive, not a workflow.
  • Attached to a live record. Account plans, close plans, onboarding docs, open case notes.
  • Repeated. If your team writes the same document forty times a year, that’s not a document to enrich — that’s a Template to build once.

For that priority set, open each one and do the work: link it to its Salesforce record, replace the copy-pasted stage and ARR with Live Fields, swap the stale table of open cases for a Related List. Everything else can land as-is and be enriched later, or never.

Then build Templates for the repeated ones. That’s where the ongoing value is — the migration is a one-time task, but a Template pays out every time someone starts a new document.

Step 4 — Export a Folio Archive from the sandbox

Once the sandbox looks the way you want production to look, export a Folio Archive from Folio Admin → Migration → Export.

This is not lossy like exporting to Word or Markdown. A Folio Archive is high fidelity, and carries:

  • Document text and Folio formatting
  • Record Links, Live Fields, and Salesforce components
  • Record relationships and Tags
  • Comment threads
  • Version history
  • Images under 3 MB each

The output is a .zip — and inside it, more .zip files, because large exports are written in parts.

Step 5 — Import the archive into production

Unzip the outer archive. Then, in your production org, go to Folio Admin → Migration → Import and upload the inner zip files.

Folio resolves every Record Link, Live Field, and Salesforce Component as it imports — and by default it resolves them by record ID.

That’s the reason Step 2 said full-copy sandbox. A full copy carries production’s record IDs, so a document that points at an Opportunity in the sandbox points at the same Opportunity when it lands in production. Everything resolves nicely with nothing to remap.

If your IDs don’t line up — an older sandbox, a partial copy, a different org entirely — Folio Docs can resolve against a reference field instead of the record ID. That’s the right tool for a migration between orgs that were never copies of each other. See the Help Center for how to configure it.

A realistic sequence

For most teams the whole thing looks like this:

  1. Refresh a full-copy sandbox.
  2. Export from Quip, note what the Live Apps were doing.
  3. Import the files into the sandbox.
  4. Enrich the priority documents; build Templates for the repetitive ones.
  5. Export a Folio Archive.
  6. Unzip, import the inner archives into production.

The work is concentrated in Step 4 — the human judgment about which documents matter. Everything on either side of it is mechanical.

You have until March 2027, but the deadline isn’t really the point. Every month those documents stay outside your CRM is another month of context living somewhere your team doesn’t work.