--- title: "SharePoint to ServiceNow Knowledge Base Migration, Step by Step" description: "A migration plan for moving SharePoint pages, document libraries, and wikis into ServiceNow Knowledge Management, covering inventory, the four export routes, the field mapping, the approval workflow, and the cleanup that decides whether the new knowledge base is usable." canonical: https://ocho.bot/blog/sharepoint-to-servicenow-knowledge-base-migration last_updated: 2026-09-12 --- # SharePoint to ServiceNow Knowledge Base Migration, Step by Step > A migration plan for moving SharePoint pages, document libraries, and wikis into ServiceNow Knowledge Management, covering inventory, the four export routes, the field mapping, the approval workflow, and the cleanup that decides whether the new knowledge base is usable. Published: 2026-09-12 SharePoint holds knowledge in four shapes: site pages, wiki pages, documents in libraries, and lists. ServiceNow Knowledge Management holds it in one: HTML articles in knowledge bases, organized by category, owned by a group, and moved through a Draft, Review, Published lifecycle. A migration is the work of turning the first into the second without carrying over ten years of duplication. This guide is the plan we use, with the ServiceNow mechanics verified against the current documentation. ## Step 1: Inventory what SharePoint holds Before choosing tools, count. For each site: how many pages, how many documents by type (Word, PDF, Excel, PowerPoint), when each was last modified, and who owns it. SharePoint's site contents and the Microsoft Graph API both give you this. The numbers decide everything downstream. Expect three findings. A large share of items have not been modified in years. Several items cover the same procedure with small differences. And a meaningful share of "knowledge" is not article-shaped: it is a form, a spreadsheet, a slide deck, or a policy PDF that must stay a PDF. Decide the fate of each class now. Retire what is dead, keep the file-shaped items as attachments, and treat the rest as article candidates. ## Step 2: Design the target ServiceNow lets you have several knowledge bases, each with its own workflow, categories, and managers. Map the SharePoint structure onto it deliberately rather than copying the site tree. - **Knowledge bases**: one per audience or owning team, such as IT, HR, Facilities. Each gets a workflow: Instant Publish for low-risk content, Approval Publish where a knowledge manager or ownership group must sign off. - **Categories**: a flat or two-level list per knowledge base. SharePoint's nested folders do not map one-to-one, and most of the nesting was never meaningful to readers. - **Ownership groups**: available with Knowledge Management Advanced. Assigning one per category gives every migrated article an approver and a place for feedback tasks. - **Validity**: set the knowledge base's article validity so that migrated articles get a review date instead of the default of 1 January 2100. Write the mapping down as a table: SharePoint site or library, target knowledge base, target category, owner, workflow. Every later step reads from it. ## Step 3: Choose an export route per content type There is no SharePoint-to-ServiceNow migration button. The community's long-running threads on the subject settle on a mix of four routes. **Word documents.** Use ServiceNow's Import Articles feature, which accepts .doc and .docx and creates one article per file with images as attachments. Good for tens of documents, not hundreds. Details in [How to import Word documents into a ServiceNow knowledge base](/blog/import-word-documents-into-servicenow-knowledge-base). **Site pages and wiki pages.** Export the page HTML with the Graph API or a PowerShell script, strip SharePoint's page wrapper (navigation, web part markup, inline styles), and load the cleaned HTML through Import Sets or the Table API. Rewrite internal links to point at the new article numbers, which means importing in an order where link targets exist first, or a second pass that fixes links after all articles have sys_ids. **PDFs and other files that stay files.** Create a summarizing article and attach the file, or embed it with the Document Viewer. The methods are compared in [How to convert PDFs into ServiceNow knowledge articles](/blog/convert-pdfs-to-servicenow-knowledge-articles). **Lists.** Lists are data, not articles. If a list is a lookup that articles reference, move it to a custom table or leave it in SharePoint and link to it. For the bulk routes, the three loaders and their tradeoffs are covered in [How to bulk import knowledge articles into ServiceNow](/blog/bulk-import-knowledge-articles-into-servicenow). The short version: Easy Import for a spreadsheet of text-only articles, Import Sets when you will run the load more than once, and the Table API for anything scripted. Two integration options deserve a mention because they come up in every search. The IntegrationHub Microsoft SharePoint Online spoke gives Flow Designer actions for files, folders, sites, lists, and search, and it can attach a SharePoint file to a ServiceNow record. It requires an IntegrationHub subscription and an Azure app registration, and it is a building block for a custom flow rather than a migration tool. The ServiceNow Graph connector goes the other direction: it indexes ServiceNow knowledge articles so they appear in Microsoft Search. Neither converts pages into articles. ## Step 4: Run the load into Draft Whatever the route, every article should be created in Draft. That gives you the review step, keeps versioning consistent, and means a bad batch can be deleted without touching anything readers see. - Load in small batches. ServiceNow's own guidance is small batches to avoid request timeouts. - Coalesce on the SharePoint item id, stored in a custom field, so re-runs update rather than duplicate. - Keep a log of source id to ServiceNow sys_id. The link rewrite pass needs it, and so does the audit trail. - Attach the original file to the article where a reader might want it, using the Attachment API for scripted loads. ## Step 5: Review, approve, publish Route each draft through the knowledge base's workflow. With Approval Publish, the knowledge manager or ownership group approves; with Instant Publish, the contributor publishes directly. For a migration, Approval Publish on at least the first pass catches the conversion errors that scripts miss: a table that lost its structure, a heading that lost its number, a link that still points at SharePoint. Retire in SharePoint as you publish in ServiceNow. Leave a redirect or a stub page pointing at the new article for the period readers still search the old place. ## Step 6: Keep it clean after cutover The day after cutover, someone creates a new page in SharePoint. Decide before then how new content reaches ServiceNow, who reviews it, and what happens to the old site. Set the knowledge base's article validity so every migrated article comes up for review, and give ownership groups the feedback tasks that Knowledge Management Advanced generates. ## The step most migrations skip The community write-up of a migration that moved more than 10,000 SharePoint articles into ServiceNow describes the export and load as the small part. The large part was deciding, page by page, what to keep. That decision is the same for every route above, and it is manual unless something reads every page. Ocho does that reading. It connects to SharePoint, file shares, and Confluence as they are, with no cleanup beforehand, and AI agents read every page and build a knowledge graph of the estate: what is current, what is duplicated, what is dead, and which of the nine copies is newest. Every page gets a verdict, keep, archive, or duplicate, with a logged reason an auditor can read. Duplicates collapse into one drafted ServiceNow article with citations back to the source pages. Your experts approve each draft, Ocho publishes the approved ones to ServiceNow, and after cutover new content is triaged automatically. The engagement is run by a forward deployed engineer, starts with a two-week, fixed-price triage of up to 10,000 pages, and the triage report is yours whether or not you continue. It is built for estates of thousands of pages; a team with one site of forty pages does not need it. The offer is described on the [SharePoint to ServiceNow migration page](/leave-sharepoint). ## Questions ### Can I connect SharePoint to ServiceNow instead of migrating? Yes, in two directions. The ServiceNow Graph connector surfaces ServiceNow knowledge in Microsoft Search. The SharePoint Online spoke lets ServiceNow flows work with SharePoint files. Neither gives help desk agents a single knowledge base with a single lifecycle, which is usually why the migration is on the roadmap. ### Should SharePoint pages become one article each? Often not. Long pages that cover several procedures should become several articles, and several short pages that cover one procedure should become one. That is a content decision, and it is the reason to read before you load. ### What happens to page permissions? They do not migrate. ServiceNow controls access with user criteria on knowledge bases and articles. Map SharePoint permission groups to user criteria as part of the target design. ## Sources and how we checked Checked on 2026-09-12 against ServiceNow documentation and community write-ups. - ServiceNow community: [Migrating an Intranet from SharePoint to ServiceNow: Conversion of Knowledge Articles](https://www.servicenow.com/community/ex-platform-for-the-modern/migrating-an-intranet-from-sharepoint-to-servicenow-conversion/ba-p/2342455) - ServiceNow docs: [Microsoft SharePoint Online spoke](https://www.servicenow.com/docs/bundle/zurich-integrate-applications/page/administer/integrationhub-store-spokes/concept/sharepoint-online-spoke.html) - ServiceNow docs: [Import Word documents](https://www.servicenow.com/docs/bundle/zurich-servicenow-platform/page/product/knowledge-management/task/import-word-platform.html), [Table API](https://www.servicenow.com/docs/r/api-reference/rest-apis/c_TableAPI.html), [Attachment API](https://www.servicenow.com/docs/r/api-reference/rest-apis/c_AttachmentAPI.html) - ServiceNow docs: [Knowledge workflows](https://www.servicenow.com/docs/bundle/washingtondc-servicenow-platform/page/product/knowledge-management/reference/r_KnowledgeWorkflows.html), [Ownership groups](https://www.servicenow.com/docs/bundle/washingtondc-servicenow-platform/page/product/knowledge-management/concept/enable-ownership-group.html), [Knowledge article states](https://www.servicenow.com/docs/bundle/xanadu-servicenow-platform/page/product/knowledge-management/concept/knowledge-article-states.html) - ServiceNow community: [Options for importing external articles into ServiceNow](https://www.servicenow.com/community/knowledge-management-articles/options-for-importing-external-articles-into-servicenow/ta-p/2673388) --- Ocho — AI knowledge orchestration · [Home](https://ocho.bot/) · [Docs](https://ocho.bot/docs) · [Blog](https://ocho.bot/blog) · [About](https://ocho.bot/about) · [Developers](https://ocho.bot/developers) · [Contact](https://ocho.bot/contact) · [llms.txt](https://ocho.bot/llms.txt)