Migrating SharePoint to Guru requires converting pages to HTML Cards via API, flattening deep folder hierarchies, and translating item-level permissions to Collection-level access — Guru's native sync is not a migration.
Migrating from SharePoint to Guru is a content-architecture translation, not a file copy, as the two platforms have fundamentally different data models: SharePoint's item-level permissions, unlimited folder nesting, and web-part-based page canvas have no direct equivalents in Guru's Collection → Folder → Card hierarchy with Group-level access control. Guru's native SharePoint integration is a read-only sync that surfaces content in search but does not create editable Guru Cards, so a true structural migration requires custom ETL via the Microsoft Graph API and Guru REST API. Significant custom work is needed to convert modern page JSON to Guru-compatible HTML, flatten deep folder structures to Guru's three-level maximum, re-host inline images, rewrite internal links, and consolidate SharePoint's granular permission inheritance into Guru's Collection-and-Group access model.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Quick Answer: The Reality of Migrating SharePoint to Guru
Migrating from SharePoint to Guru is a medium-to-high complexity knowledge base migration, not a file copy. It typically takes 2–3 weeks for organizations with 500–2,000 pages, and 3–5 weeks for 5,000+ pages with complex permissions. The single biggest risk is permission misalignment: SharePoint's item-level broken inheritance has no 1:1 equivalent in Guru's Collection-and-Group access model. Version history, SharePoint web parts, and folder nesting beyond three levels cannot be migrated directly. Guru's native SharePoint integration is a sync, not a structural migration — it does not create native Guru Cards. Teams under 200 pages with flat permissions can handle this in-house with scripting; above that, or with complex permissions, a managed migration service significantly reduces re-work.
Do not design a new migration around legacy Boards documentation
With the recent updates to hierarchy within Guru, they have switched from Boards to Folders. Older API docs or scripts referencing boardId will fail — use folderIds instead.
Guru's API has no bulk Card creation endpoint
Every Card, attachment, and tag assignment is an individual HTTP request. At 2–3 Cards/second sustained throughput:
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Decide what content deserves to move before you plan how to move it.
Objective A content inventory with a keep/rewrite/retire decision on every article and an agreed URL strategy.
Keep these open
-
Inventory all content in SharePoint
Count articles, categories, attachments, images and embedded media, and pull page views and last-updated dates for each article. Usage data is what makes the next decision defensible rather than political.
Data Profiler Get real record counts instead of estimating from memory -
Make a keep, rewrite or retire call on every article
Most knowledge bases are half stale. Migrating everything imports the staleness and doubles the work; use views and last-updated to triage, and get the owning team to confirm. This usually removes 30-50% of scope.
Migrating stale content is the most common knowledge-base migration mistake — it costs effort and actively degrades the new site.
-
Agree the URL and redirect strategy
Decide the Guru URL structure and whether you can serve 301 redirects from the old paths. Public help centres carry real search traffic and inbound links; losing it is a measurable commercial impact.
Without 301 redirects from old article URLs you lose accumulated search ranking and every external link and bookmark breaks.
-
Map the information architecture
Document the current category tree and design the target one, checking whether Guru supports your nesting depth. Deeply nested hierarchies frequently have to be flattened, which changes navigation for everyone.
-
Confirm permissions, audiences and localisation scope
Establish which content is public, internal or restricted, and how Guru models that. Then confirm how many locales you have and whether translation relationships between articles survive the move.
SharePoint → Guru specifics
- AI-powered knowledge delivery
- Guru's search surfaces verified answers inside Slack, Teams, and browser extensions. SharePoint search requires users to navigate to a separate portal, adding context-switching overhead in support and sales workflows where response time matters.
- Lower information architecture overhead
- SharePoint requires ongoing admin effort to maintain sites, content types, metadata columns, term stores, and permission inheritance. Guru's flatter hierarchy (Collection → up to 3 Folder levels → Card) reduces structural maintenance for teams under 10,000 articles.
- In-context access
- Guru operates where support agents and engineers work (Slack, browser extensions, Chrome/Edge), reducing the portal-switching that SharePoint requires for non-admin users.
Don't move on until
- Full content inventory with page views and last-updated dates
- Keep / rewrite / retire decision recorded per article
- URL and redirect strategy agreed with whoever owns SEO
02 Data Audit Audit the markup, the links and the assets — that is where KB migrations break.
Objective A content export with markup, internal links and every embedded asset accounted for.
Keep these open
-
Export content and assess markup fidelity
Export articles in the richest format available and inspect what survived: tables, code blocks, callouts, nested lists, anchors and embedded video. Rich formatting is where fidelity is lost, and it is lost quietly.
HTML-to-Markdown conversion routinely mangles nested lists, tables and code blocks. Inspect the output rather than trusting the converter.
Data Profiler Profile the SharePoint export for nulls, outliers and type drift -
Inventory every internal link and cross-reference
Extract all internal links, anchor links and article cross-references. These break by default: the target URL structure differs, so every internal link needs rewriting as part of the load, not afterwards.
Internal links left pointing at old URLs turn the new knowledge base into a maze of 404s on day one.
-
Inventory images, attachments and embedded media
List every asset with its URL, size and type, and confirm each still resolves. Assets hosted on the old platform's CDN will 404 the moment you decommission it, so they must be rehosted, not referenced.
Images referenced from the source platform's CDN break when the old account closes. Download and rehost every asset.
-
Find and fix broken links and orphans
Crawl for existing broken internal and external links, and find articles no category links to. Fix them before migrating — a migration is a bad time to discover pre-existing rot.
-
Check for PII and internal information in public content
Scan for customer names, internal hostnames, credentials in code samples and screenshots containing real data. Republishing these on a public help centre is a disclosure, and screenshots are the usual culprit.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Normalise metadata
Standardise authors, tags, timestamps to UTC, and locale codes. Author mapping needs a decision for people who have left — attribution to a deleted user usually fails the import.
-
Extract text content
Pull innerHTML from textWebPart sections. This is already HTML but contains SharePoint-specific CSS classes and data-sp-* attributes that should be stripped.
-
Clean HTML
Remove empty <div> wrappers, normalize heading levels (SharePoint pages often start at <h2>), and ensure all <a> tags have valid href attributes.
Data Cleaner Strip empty rows, stray whitespace and dead columns
SharePoint → Guru specifics
- Site discovery
- GET /sites or GET /sites?search={query} — returns all sites the authenticated user/app can access.
- Lists and libraries
- GET /sites/{site-id}/lists — filter by list.template to distinguish Document Libraries (documentLibrary) from generic lists.
- Library folder/file traversal
- GET /sites/{site-id}/drive/items/{item-id}/children with $select, $expand, and $skipToken for pagination.
- File content download
- GET /sites/{site-id}/drive/items/{item-id}/content — returns the raw binary stream.
- Modern pages
- GET /sites/{site-id}/pages/microsoft.graph.sitePage — requires Sites.Read.All permission scope.
Don't move on until
- Content exported with markup fidelity assessed
- Every internal link and asset reference inventoried
- Broken links and missing assets fixed or logged
03 Field Mapping Map structure, metadata, permissions and — above all — URLs.
Objective A mapping covering article fields, taxonomy, permissions and a complete old-to-new URL map.
Keep these open
-
Map the article schema
Map title, body, excerpt, author, dates, status, tags, SEO metadata and any custom properties. Confirm which fields Guru lets you set on import versus which it computes — computed dates are a common surprise.
Schema Mapper Opens pre-loaded with the SharePoint → Guru field pair -
Map the taxonomy and hierarchy
Map categories, sections and tags to the target structure, resolving any nesting-depth limit explicitly. If you must flatten, decide how the lost level is preserved — usually as a tag or a title prefix.
JSON to CSV Converter Flatten nested API responses into a reviewable sheet -
Map permissions and audience segmentation
Map public, logged-in, and role-restricted visibility to Guru's model. Verify the mapping deliberately: internal content accidentally published publicly is the highest-severity failure in this whole category.
Permission mapping errors publish internal documentation to the open web. Verify visibility on every restricted article after load.
-
Build the complete old-to-new URL map
Produce a row per article mapping the old URL to the new one, then confirm exactly where the 301s will be served — Guru, a CDN, or your own web layer. Without this artifact the redirect step cannot be executed at all.
-
Define the markup conversion and link-rewrite rules
Specify how each markup construct converts and how internal links are rewritten using the URL map. Write it as a repeatable transform, not manual edits — you will run it more than once.
Data Format Converter Reshape the export into the format Guru's importer expects -
Plan localisation and freeze the spec
Confirm how translated articles link to their source language in Guru, then version and sign off the mapping spec.
-
Handle images
imageWebPart sections contain serverRelativeUrl references. Download each image, upload to Guru's attachment endpoint, and replace the src URL in the HTML.
-
Flatten multi-column layouts
SharePoint sections can have 1, 2, or 3 columns. Guru Cards do not support multi-column layouts. Merge columns top-to-bottom in left-to-right order.
SharePoint → Guru specifics
- Strip unsupported web parts
- Remove heroWebPart, quickLinksWebPart, embedWebPart, powerBIWebPart, and any custom web parts. Log each removal for manual review.
Don't move on until
- Article schema and taxonomy mapped
- Permission and audience model mapped to target equivalents
- Complete URL map produced and redirect method confirmed
04 Test Migration Pilot the hardest articles, then read them.
Objective A pilot load whose formatting, links, assets and search all hold up under human review.
Keep these open
-
Configure Guru with the agreed structure
Create the category tree, permission groups, locales and branding before loading. Articles loaded before their categories exist land uncategorised and have to be moved by hand.
-
Pick the most difficult articles as the pilot
Choose 20-50 articles for difficulty: the longest, the most heavily formatted, ones with tables and code blocks, deep internal linking, many images, embedded video, restricted visibility, and non-Latin scripts. Easy articles prove nothing.
-
Run the conversion and load with link rewriting
Apply the markup conversion, rewrite internal links from the URL map, upload and re-reference assets, then load. Log every conversion warning rather than suppressing it.
-
Read every pilot article side by side
Open source and target together and compare rendering. This step is manual on purpose: no automated check catches a table that collapsed into a paragraph or a code block that lost its indentation.
-
Click every link and load every asset
Verify each internal link resolves, each image loads from the new host, each attachment downloads and each embed plays. Assets still served from the old CDN are the defect that surfaces only after decommissioning.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Test search and permissions
Search for known terms and confirm the right articles rank, then verify every restricted pilot article is invisible to an anonymous browser. Test permissions from a logged-out session, not an admin one.
SharePoint → Guru specifics
- Field-level spot check
- Sample 10–15% of Cards (minimum 20 Cards for small migrations). Verify: title accuracy, HTML rendering (no raw HTML tags visible), image display (no broken image icons), correct Collection/Folder placement, Tag assignment, and Verifier assignment.
- Link integrity scan
- Crawl all Card HTML for URLs. Flag: (a) remaining SharePoint URLs that should have been rewritten, (b) broken <img> src URLs pointing to expired SharePoint auth tokens, (c) links to migrated pages that were excluded and have no Guru equivalent.
- UAT with content owners
- Have 3–5 subject-matter experts review their sections end-to-end before go-live. Provide a structured review template: "Is the content accurate? Are images rendering? Is the Verifier correct? Are any pages missing?"
Don't move on until
- Complex articles render correctly with formatting intact
- Every internal link and asset in the pilot resolves
- Search returns sensible results for the pilot content
05 Cutover Publish, redirect, and keep the search traffic.
Objective All in-scope content live in Guru with redirects serving and search engines informed.
Keep these open
-
Load the full content set ahead of the switch
Run the full conversion and load into Guru, unpublished or on a staging domain. Content migration differs from data migration here: you can stage the whole thing before anyone sees it.
-
Publish the runbook with the redirect step first-class
Sequence the freeze, final delta, publish, redirect activation, sitemap submission and link updates, with owners for each. Redirect activation is the step with lasting commercial consequences, so it gets explicit ownership.
-
Freeze editing and migrate the delta
Stop editing in SharePoint, then convert and load anything changed since the full load. Announce the freeze to every team that publishes — content teams are used to editing whenever they like.
-
Publish and verify permissions live
Publish the content set, then immediately verify restricted articles are not publicly reachable using an anonymous session. Do this before announcing the new site, not after.
Verify restricted content from a logged-out browser. An admin session will show you everything and tell you nothing.
Migration Validation Tool Confirm the final delta landed before you reopen -
Activate 301 redirects and submit the sitemap
Turn on the redirects from the URL map, then spot-check a sample of high-traffic old URLs and confirm each returns 301 to the right article. Submit the new sitemap and keep the old one reachable until search engines have recrawled.
Redirect chains and redirect loops both leak ranking. Verify each redirect resolves in a single hop.
-
Repoint in-product and support links
Update help links embedded in your product, in support macros, in email templates and in onboarding material. These are the links your existing customers actually use, and they are easy to forget.
-
Archive or delete Guru Collections
Use DELETE /api/v1/collections/{id} to remove migrated Collections. This deletes all Cards and Folders within them. Alternatively, restrict Collection access to admins only while you investigate.
-
Fix and re-run
Correct the transformation or mapping logic and re-run from Step 4 onward (the extraction cache from Step 3 is still valid).
SharePoint → Guru specifics
- Revert SharePoint to read-write
- Remove the site lock (Set-SPOSite -Identity <URL> -LockState Unlock).
- Communicate to users
- Send a brief notification that Guru is temporarily unavailable and SharePoint is the active knowledge base.
- Diagnose root cause
- Use your source-to-target ledger to identify which Cards have issues. Common root causes: HTML transformation errors, missing attachment re-hosting, permission mapping errors.
- Rollback readiness
- Confirm SharePoint is still accessible in read-only mode. Verify your source-to-target ledger is complete and backed up. Test the DELETE /api/v1/collections/{id} endpoint on a test Collection to confirm rollback mechanics work.
Don't move on until
- All content loaded, categorised and correctly permissioned
- 301 redirects live and verified from a sample of old URLs
- Sitemap submitted and support links repointed
06 Validation Watch traffic, links and search rankings for weeks, not hours.
Objective Verified content completeness, healthy redirects, and search traffic recovered to baseline.
Keep these open
-
Reconcile content counts and assets
Compare article counts by category and status, plus asset counts, against source. Confirm every article in the keep list is present and every retired one genuinely is not.
Migration Validation Tool Reconcile SharePoint and Guru record-for-record -
Crawl the new site for broken links and assets
Run a full crawl for 404s, broken images and missing attachments, and fix everything it finds. Repeat the crawl after the fixes rather than assuming they worked.
-
Verify the redirects at scale
Test every mapped old URL for a single-hop 301 to the right destination. Chains and loops both leak ranking and are invisible unless you check the whole map, not a sample.
-
Monitor organic traffic and rankings for four to eight weeks
Track organic sessions, impressions and rankings for your top articles against baseline. A dip in the first two weeks is normal; one that has not recovered by week six is a redirect or indexing problem to investigate.
Do not decommission the old platform until search traffic has recovered — you may still need the old URLs to diagnose a ranking loss.
-
Verify search, permissions and feedback loops
Confirm on-site search returns good results for real queries, re-verify restricted content from a logged-out session, and check article feedback and analytics are collecting.
-
Sign off and decommission on a delay
Get acceptance against the Discovery criteria, keep SharePoint available read-only until traffic has recovered, take a final export, and only then close the account.
-
Record-count reconciliation
Total Cards in Guru must equal total migrated pages from SharePoint, minus explicitly excluded items (archived pages, system pages, duplicates removed). Automate this check: GET /api/v1/collections/{id}/cards and compare counts by Collection against your extraction ledger.
SharePoint → Guru specifics
- Verification workflows
- Guru's built-in Verifier system assigns subject-matter experts to Cards on a configurable recurring interval (e.g., 30, 60, 90, or 180 days). SharePoint has no native equivalent — content review depends on manual processes, SharePoint Designer workflows, or Power Automate flows that must be built and maintained separately.
- Product knowledge, feature docs
- 90–120 days (aligned with release cycles)
- Verification dashboard review
- Guru admins should review the "Unverified Cards" dashboard weekly for the first 30 days, then monthly. Set a team OKR for verification compliance (target: >90% of Cards verified within their interval).
- New content creation process
- Define where new knowledge is created (Guru, not SharePoint). Disable write access to the old SharePoint site after 30 days.
- Ongoing content ingestion
- For content that continues to originate in SharePoint (e.g., from teams not yet migrated), use Guru's native sync for read-only visibility or build a lightweight scheduled script that checks for new/modified SharePoint pages and creates corresponding Guru Cards.
Don't move on until
- Article counts reconciled and no broken links remain
- Redirects returning 301 with no chains or loops
- Organic traffic recovered to within tolerance of baseline
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
SharePoint Objects Guru Cards
| SharePoint field | Guru field | Notes |
|---|---|---|
| Site | Collection | One Collection per SharePoint Site is the cleanest mapping. Hub Sites may need multiple Collections. |
| Document Library / Folder | Folder | Guru supports max 3 levels of Folder nesting. Deeper SharePoint structures must be flattened. |
| Modern Page / Wiki Page | Card | Page content must be converted from canvas layout JSON or legacy HTML to Guru-compatible HTML. |
| Document (PDF, DOCX, XLSX) | Card with Attachment | Binary files are uploaded via POST /api/v1/attachments/upload and referenced in Card HTML. Guru does not extract searchable text from PDFs. |
| List | Card (or external link) | SharePoint Lists have no native Guru equivalent. Convert to tabular Card content or link externally. |
| Metadata Columns | Tags | SharePoint columns (choice, managed metadata) map to Guru Tags. Free-text columns have no clean mapping. |
| Page Author / Modified By | Card Owner / Verifier | Map SharePoint createdBy or lastModifiedBy to Guru Verifier to preserve accountability. |
| Item-level Permissions | Group-level access on Collection | No 1:1 mapping. Items with broken inheritance must be regrouped into separate Collections or accepted as broader access. |
| Version History | Not migrated | Guru tracks Card revision history natively, but SharePoint's file version history (timestamps, authors, diffs) cannot be imported. |
| Web Parts (Hero, Quick Links, Embed, Power BI) | Not supported | Web part functionality has no Guru equivalent. Content must be manually simplified to static HTML or linked externally. |
| SharePoint Workflows / Power Automate | Not migrated | Guru has no workflow engine. Rebuild in external tools if needed. |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Modern Pages / Wiki Pages | medium | Page content requires conversion from SharePoint's canvas layout JSON or legacy HTML to Guru-compatible HTML, which is achievable programmatically but requires careful handling of embedded media and formatting. |
| Item-Level Permissions | high | SharePoint's granular broken-inheritance permissions have no 1:1 mapping in Guru's Collection-and-Group model, requiring a full permission audit and content restructuring that risks either over-broadening or fragmenting access. |
| Folder Structure / Hierarchy | high | SharePoint's unlimited nesting depth must be flattened to Guru's three-level Folder maximum, which can cause significant information architecture redesign and potential content discoverability regressions. |
| Documents (PDF, DOCX, XLSX) | medium | Binary files can be uploaded as Card attachments via the Guru API, but Guru does not extract searchable text from PDFs, reducing discoverability compared to SharePoint's indexed search. |
| SharePoint Lists | high | Lists have no native Guru equivalent, and all migration paths (row-to-Card conversion, static HTML tables, or external linking) sacrifice the interactivity, filtering, and structured data capabilities of the original. |
| Metadata Columns / Tags | medium | Choice and managed metadata columns map reasonably well to Guru Tags via the API, but free-text columns and complex term store hierarchies have no clean mapping and require manual decisions. |
| Version History | high | SharePoint's full version history including timestamps, authors, and content diffs cannot be imported into Guru at all, resulting in permanent loss of historical audit trail data. |
| Web Parts (Hero, Quick Links, Power BI) | high | Web part functionality has no Guru equivalent, requiring manual simplification to static HTML or external links, which loses interactive and dynamic content capabilities entirely. |
| Page Authors / Verifiers | low | SharePoint's createdBy and lastModifiedBy fields map cleanly to Guru's Card Owner and Verifier assignments, preserving content accountability with minimal transformation effort. |
| Workflows / Power Automate Flows | medium | Guru has no workflow engine, so any SharePoint Designer workflows or Power Automate flows tied to content lifecycle must be completely rebuilt in external tools if the functionality is still required. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Permission Model Misalignment
SharePoint supports item-level broken inheritance with up to 50,000 unique permission entries per library, while Guru only controls access at the Collection and Group level with no individual Card-level permissions, requiring a complete audit and restructuring of access patterns.
Content Format Conversion
SharePoint modern pages use a web-part-based canvas layout serialized as JSON via the Microsoft Graph API, and every page must be converted to Guru-compatible HTML with SharePoint-specific CSS classes, data attributes, and unsupported web parts stripped or rebuilt.
Hierarchy Depth Flattening
SharePoint allows unlimited site and folder nesting, but Guru supports a maximum of three levels of Folder nesting within a Collection, forcing deep SharePoint structures to be redesigned and flattened before loading.
SharePoint Lists Have No Equivalent
SharePoint Lists are structured tabular data with typed columns, calculated fields, and views, but Guru has no database or list object, leaving only suboptimal workarounds like converting rows to individual Cards or embedding static HTML tables.
Version History Loss
SharePoint's file version history including timestamps, authors, and diffs cannot be imported into Guru, meaning historical revision context is permanently lost during migration even though Guru tracks its own Card revision history natively.
Image and Attachment Re-hosting
Inline images and binary file attachments referenced in SharePoint pages must be extracted, re-uploaded via Guru's attachment API, and re-linked within Card HTML, as original SharePoint-hosted URLs will break after migration.
What breaks
Known failure modes. Have a recovery plan for each before you cut over.
The 5,000-item list view threshold
If you filter or sort a SharePoint document library containing over 5,000 items via the Graph API without indexed columns, the query will fail or return throttled responses. Partition by folder-scoped requests, indexed column $filter expressions, or $skipToken pagination.
Item-level broken inheritance
Guru does not support Card-level permissions. A Card inherits its Collection's access settings. If different SharePoint pages within the same library have different access requirements, they must be split across separate Guru Collections — each with its own Group assignments.
Unsupported web parts
SharePoint pages containing dynamic web parts (Power BI dashboards, Hero sections, Quick Links carousels, Embed/iframe, Yammer feeds, Stream video) will not migrate as functional elements. Content must be simplified to static HTML, screenshots with alt text, or external links.
Guru's editor is simpler than SharePoint's
Guru's Card editor allows you to format content for clarity and readability. The editor supports Markdown, and allows embedding of images, files, videos, and more. However, complex layouts, multi-column sections, collapsible sections, tabs, and interactive elements are not supported. Guru Cards are designed to be short, focused knowledge units — not long-form documents.
SharePoint Group ACLs in native sync
Guru's native SharePoint integration documents that the Graph API cannot retrieve SharePoint Group memberships, so ACLs won't sync for sites that rely exclusively on SharePoint groups (as opposed to Microsoft 365 groups or Azure AD security groups).
Large files in Source sync
Guru applies a 50 MB file-size limit across connected sources. Files exceeding this limit are silently excluded.
PDF text extraction
Guru does not extract searchable text from PDF attachments. PDFs are stored as downloadable files. If PDF content needs to be searchable, extract the text during transformation and include it in the Card body.
No built-in deduplication
If your SharePoint environment has duplicate pages across multiple sites (common with hub sites and content rollups), you will create duplicate Cards unless you deduplicate during the transform phase. Use content hashing (MD5/SHA256 of normalized HTML) or URL-based dedup rules.
Large attachment volumes
Guru's attachment upload is per-file with no batch endpoint. A library with 2,000 PDFs averaging 2 MB each takes approximately 45–90 minutes to upload at sustained throughput, depending on network and rate limits.
Deep folder trees
Guru supports up to 3 nested folder levels. Anything deeper must be flattened, merged, or split into multiple Collections before migration. Use Tags to preserve the former hierarchy path for searchability.
Card content size limits
Guru does not publicly document a maximum Card content size, but empirically, Cards exceeding ~100 KB of HTML content may experience editor performance issues. Long SharePoint pages should be split into multiple Cards.
Managed metadata term store
SharePoint's managed metadata (term store) supports hierarchical, multilingual term sets. Guru Tags are flat (no hierarchy). Multi-level term sets must be flattened to leaf-node Tags or concatenated (e.g., "Region > EMEA > UK" becomes the Tag "Region-EMEA-UK").
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can I migrate SharePoint to Guru without losing data?
Page content, titles, tags, and author information can be fully migrated to Guru Cards. However, SharePoint version history, web part interactivity, item-level permissions, and Power Automate workflows cannot be replicated in Guru. Binary file attachments can be re-hosted but remain as Card attachments, not a document management system.
Does Guru have a native SharePoint import tool?
No. Guru offers a native SharePoint sync integration that surfaces SharePoint content in Guru's search, but it does not create editable native Guru Cards. For a structural migration where content lives natively in Guru, you need the Guru REST API, manual recreation, or a managed migration service.
How long does a SharePoint to Guru migration take?
For 500–2,000 pages with a dedicated engineer: 2–3 weeks including audit, script development, migration, and validation. Under 200 pages with simple formatting: 5–7 days. For 5,000+ pages with complex permissions: 3–5 weeks.
What data cannot be migrated from SharePoint to Guru?
SharePoint version history, Power Automate workflows, web part functionality (Hero, Quick Links, Embed, Power BI), item-level broken permission inheritance, list views, and calculated columns have no equivalent in Guru. These must be simplified, linked externally, or dropped.
Is there a downside to migrating SharePoint to Guru?
Yes. You lose SharePoint's document management capabilities (versioning, co-authoring, complex metadata views, Power Automate integration). Guru's editor is simpler — teams used to rich SharePoint page layouts may find it constraining. Item-level permission granularity is also lost since Guru flattens permissions to the Collection level.