← All playbooks
Knowledge migration

Google Docs → Obsidian

Move documents, hierarchy, links, attachments, structured data, comments, permissions, search, templates, and integrations from Google Docs into Obsidian with an explicit exception ledger and evidence-based cutover.

Typical timeline10–25 business days45–90 hours active work
Statusneeds review
Source testedGoogle Docs documentation reviewed 2026-07-19
Destination testedObsidian documentation reviewed 2026-07-19
Last reviewed2026-07-19
Sources2
Before you migrate

Should you make this move?

Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.

Current platform

Google Docs

Reasons to stay
  • Frictionless real-time editing and comments make collaborative writing universal
  • Flexible documents make it easy to capture and organize team knowledge
Reasons to leave
  • Large knowledge systems lack durable structure, backlinks, and local file ownership
  • Structure, links, permissions, and rich blocks often degrade during export
New platform

Obsidian

What gets better
  • Local Markdown files, backlinks, and plugins provide durable personal knowledge ownership
  • Flexible documents make it easy to capture and organize team knowledge
What gets worse
  • Real-time collaboration, permissions, and managed team administration are limited
  • Structure, links, permissions, and rich blocks often degrade during export
Best of the move

Obsidian: Local Markdown files, backlinks, and plugins provide durable personal knowledge ownership. This removes a major source-side concern: Large knowledge systems lack durable structure, backlinks, and local file ownership.

Worst of the move

What you lose: Frictionless real-time editing and comments make collaborative writing universal. What you inherit: Real-time collaboration, permissions, and managed team administration are limited.

01At a glance

Know the shape of the move.

Transfer outcome12 features audited
Transfer outcome distributionClean transfer: 0, Partial transfer: 8, Manual rebuild: 2, Not transferred: 2.
Clean0
Partial8
Manual2
Lost2
Mapping route9 of 9 fields have a destination path

This timeline assumes

  • Up to 100,000 documents, 500 users, and 250 GB of attachments
  • A content owner approves the destination information architecture.
  • The source remains available until assets, links, search, and access checks pass.
  • A representative space, notebook, or folder is imported before the full corpus.
  • The migration team records evidence for every blocking verification check.
02Loss matrix

What survives the move.

“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.

ItemOutcomeImpactWhat happensMitigation
Documents, headings, links, images, tables, and folder contextpartialcriticalCore documents, headings, links, images, tables, and folder context can move, but Google Docs and Obsidian use different models, limits, identifiers, and import behavior.Pilot every feature class, preserve source IDs, and reconcile accepted, transformed, rejected, and excluded items.
Comments, suggestions, sharing, version history, smart chips, and live embedslostcriticalGoogle’s real-time collaboration and cloud-native document features are not preserved in local Markdown.Inventory every active dependency, approve its destination disposition, and test the replacement before source writes stop.
Pages, documents, and notespartialcriticalCore text can move while rich blocks, layout, and embedded applications change.Compare every content class and a stratified page sample.
Hierarchy and navigationpartialhighSpaces, folders, notebooks, pages, and databases have different nesting rules.Create a destination information architecture before import.
Links, anchors, and backlinkspartialhighInternal IDs and anchor formats change during conversion.Build a link registry and require zero unexplained critical broken links.
Images, files, and embedspartialcriticalSome assets copy while remote, large, or authenticated resources remain source-dependent.Copy required binaries and test them with ordinary-user access.
Tables and databasespartialcriticalStatic table values can move more easily than relations, views, formulas, and rollups.Classify each structure as content, data, or application before migration.
Comments and mentionspartialhighCoverage, threads, resolutions, and user attribution vary by importer.Resolve active discussions and archive complete source evidence.
Permissions and external sharingmanualcriticalAccess inheritance, guests, public links, and restrictions use different models.Apply and test a signed destination access matrix.
Version and audit historylosthighCurrent content can move without becoming native destination revision history.Keep immutable exports and source access for the retention period.
Templates and reusable blocksmanualmediumSource templates and synchronized content do not execute on the destination.Rebuild only approved templates after content verification.
Search metadata and OCRpartialhighIndexes, OCR text, aliases, and ranking do not transfer as identical search behavior.Run known-result queries and retain OCR text where required.
03Field and feature mapping

Where each thing goes.

SourceDestinationMethodNotes
Google Docs space, notebook, or top-level areaObsidian workspace, space, teamspace, or foldermanualDesign access and hierarchy before content.
Page, document, or noteDestination page or filetransformPreserve source ID and original URL.
Heading and rich textDestination blocks or MarkdowntransformReview unsupported formatting.
Child page or folderDestination child page or foldertransformRespect destination nesting limits.
Tag, label, or propertyDestination property, tag, or labeltransformNormalize names and option values.
Internal linkDestination page linktransformResolve after all destination IDs exist.
Attachment or imageDestination filetransformCopy the binary and preserve alt text.
Comment or mentionDestination comment or archived evidencetransformPreserve authorship where the importer supports it.
Permission or shareDestination access rulemanualApply from the approved access matrix.
04Before you begin

Make the move recoverable.

Backup procedure

Create the source-of-truth backup

Preserve Google Docs data, configuration, and operating evidence before any destination write.

  1. Export all available Google Docs content, attachments, users, comments, and settings.
  2. Crawl or index page hierarchy, links, permissions, public shares, templates, and integrations.
  3. Record counts by space, folder, content type, owner, and access class.
  4. Hash raw exports and transform working copies only.

Proof to capture: A signed manifest reconciles every scoped record class, runtime dependency, export file, count, and hash.

Transformation · Crawler and migration workbook

Information architecture and link registry

Preserve hierarchy, ownership, and navigation.

  1. Inventory source values and exceptions.
  2. Define explicit destination mappings.
  3. Reject unmapped critical records.

Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.

Transformation · Importer, Markdown/HTML transformer, and checksum tool

Content and asset transformer

Create valid destination pages with durable files and links.

  1. Normalize encoding, dates, identifiers, and blanks.
  2. Run a representative pilot.
  3. Reconcile accepted, rejected, and transformed rows.

Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.

05Handle with care

The things most likely to hurt.

These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.

Import

Content imports but application behavior disappears

criticalpossible likelihood

Pages render while formulas, embeds, buttons, or integrations no longer work.

Consequence
Readers see incomplete or misleading procedures.
Mitigation
Classify runtime blocks and replace critical behavior first.

Stop if: A critical page depends on an unsupported action.

Permissions

Restricted knowledge becomes public

criticalpossible likelihood

Imported pages inherit broader access than their source.

Consequence
Confidential information is exposed.
Mitigation
Apply and test the access matrix before publication.

Stop if: An unauthorized test user can open restricted content.

Cleanup

Links or assets still depend on the source

highpossible likelihood

Destination pages reference authenticated or soon-to-close source URLs.

Consequence
Knowledge breaks after source shutdown.
Mitigation
Rewrite links and copy required assets before cleanup.

Stop if: A critical page or file requires source access.

06Precise timeline

Do the work in this order.

Estimate forUp to 100,000 documents, 500 users, and 250 GB of attachments
Total elapsed10–25 business days
Active work45–90 hours
BufferAdd time for large exports, unsupported Google Docs features, destination limits, identity exceptions, regulated data, or strict downtime requirements.
01
Days 1–3Inventory and decisions2–3 days
02
Days 3–5Backup and reconcile1–3 days
03
Days 5–12Map and pilot3–8 days
04
Days 10–20Final delta and switch1–5 days
05
Days 12–40Observe and close3–10 days
  1. Days 1–3 · inventory

    Inventory and decisions

    6–12 hours active2–3 days elapsedOwner review waiting
    • Inventory Google Docs data, features, users, domains, and integrations.
    • Approve scope, owners, mappings, and exclusions.

    Depends on: Google Docs and Obsidian administrator access

    Stop / go checkpoint

    Export?

    Go when: Every critical item has an owner and disposition.

    Stop when: Consent, billing, access, or system ownership is unclear.

  2. Days 3–5 · backup

    Backup and reconcile

    5–10 hours active1–3 days elapsedExport processing waiting
    • Create immutable exports and configuration evidence.
    • Reconcile counts, totals, and hashes.

    Depends on: Approved inventory

    Stop / go checkpoint

    Transform?

    Go when: Source totals and export manifests agree.

    Stop when: Any critical dataset or configuration is absent.

  3. Days 5–12 · pilot

    Map and pilot

    10–35 hours active3–8 days elapsedDestination processing and review waiting
    • Configure Obsidian and transform representative data.
    • Run a pilot containing normal records and every critical edge case.

    Depends on: Verified backup

    Stop / go checkpoint

    Scale?

    Go when: Pilot mappings, behavior, access, and evidence pass.

    Stop when: Any critical check fails or produces unexplained variance.

  4. Days 10–20 · cutover

    Final delta and switch

    5–25 hours active1–5 days elapsedDNS, import, or sync propagation waiting
    • Freeze production writes in Google Docs.
    • Apply the final delta, switch ownership, and run blocking checks.

    Depends on: Passed pilot and approved rollback

    Stop / go checkpoint

    Open production?

    Go when: Counts reconcile and one destination system owns production.

    Stop when: A source writer remains active or a blocking check fails.

  5. Days 12–40 · observe

    Observe and close

    3–18 hours active3–10 days elapsedOperating-cycle evidence waiting
    • Monitor one complete operating cycle.
    • Sign the verification report and close rollback only after stability.

    Depends on: Verified cutover

    Stop / go checkpoint

    Close rollback?

    Go when: No trigger occurs during the agreed observation period.

    Stop when: Data, access, delivery, routing, or business results regress.

07The point of change

Cut over with a way back.

Go live

Cutover

Make Obsidian the only production system without losing the final Google Docs delta.

Recommended window: A low-volume weekday morning with platform, data, DNS, and business owners available.

  1. Freeze production writes and scheduled actions in Google Docs.
  2. Export, transform, and reconcile the final delta.
  3. Apply the approved delta to Obsidian.
  4. Switch domains, forms, integrations, sending, or sync ownership as applicable.
  5. Run every blocking verification check and keep the source intact.

Proof to capture: Obsidian owns production, totals reconcile, and every blocking check has durable evidence.

Return to safety

Rollback

Return production ownership to Google Docs without losing destination-era changes.

Deadline: Within seven days and before source data, plans, credentials, domains, or billing are changed.

  1. Stop new writes and scheduled actions in Obsidian.
  2. Restore the prior Google Docs routing, forms, integrations, sending, or sync ownership.
  3. Export the Obsidian post-cutover delta.
  4. Review and apply safe destination-era changes to Google Docs.
  5. Run the same blocking checks against the restored source.

Proof to capture: Google Docs again owns production with current data and no duplicate destination action.

Rollback immediately when
  • Unexplained critical count or value variance
  • Missing or exposed critical data
  • Duplicate production action
  • Failed access, routing, delivery, or integration check
  • A critical feature has no safe destination replacement
08Verification report

Prove the migration worked.

Every blocking check must pass. Capture the evidence before cleanup begins.

0%
Interactive report preview0 / 8 checks passed
PassIDCheckMethodExpected resultEvidence
V-01BlockingContent reconciliationCompare counts by space, folder, type, owner, and access class.Every scoped item is accounted for.Content ledger.
V-02BlockingNavigation structureTraverse representative top-level and deeply nested content.Approved hierarchy and navigation are present.Navigation report.
V-03BlockingBlock and formatting parityCompare stratified pages containing every block class.Meaning and required structure are preserved.Content review.
V-04BlockingInternal and external link integrityCrawl destination links and anchors.No unexplained critical broken link.Link report.
V-05BlockingFile independenceCompare hashes and test files as ordinary users.Every required file is durable and accessible.Asset report.
V-06BlockingPermissions and public sharingTest representative internal, guest, and anonymous roles.Access matches the signed matrix.Access evidence.
V-07Known-result queriesRun approved exact and conceptual searches.Critical knowledge is discoverable.Search matrix.
V-08BlockingRuntime and ownershipTest critical embeds, automations, templates, and content ownership.Obsidian owns current knowledge safely.Operating checklist.
09Post-migration cleanup

Remove the scaffolding safely.

Safe after: One complete operating cycle, at least seven stable days, and owner sign-off on every blocking check.

  1. Create final Google Docs exports and archive verification evidence.
  2. Revoke temporary credentials, API keys, webhooks, and elevated roles.
  3. Remove obsolete embeds, forms, jobs, integrations, and DNS records.
  4. Keep the source intact through the approved retention window.
  5. Cancel paid plans only after billing, legal, and recovery review.
  6. Schedule the next Obsidian backup, access, and migration-playbook review.
Sources and maintenance

Built to be reviewed.

Tested 2026-07-19. Next scheduled review: 2026-10-19.

  1. Google Docs: official migration documentationAccessed 2026-07-19
  2. Obsidian: official migration documentationAccessed 2026-07-19