Knowledge Management on ServiceNow: How Higher Ed Consolidates Multiple KBs on ServiceNow

TLDRUnified knowledge management on ServiceNow is the move that turns the higher ed KB from "where articles go to die" into "the first place faculty and staff actually look." R1 institutions typically run three to five fragmented knowledge bases across Confluence, SharePoint, Notion, legacy Knowledge15, and shared drives. The institutions that fix this do not just migrate articles. They migrate the ownership model along with the content. This playbook covers the five-phase migration sequence, the sub-KB ownership architecture that prevents drift, and the political work that makes Phase 2 the hardest phase to run.

Unified knowledge management on ServiceNow is the move that turns the higher ed KB from where articles go to die into the first place faculty and staff actually look. R1 institutions typically run three to five fragmented knowledge bases. Confluence in central IT. SharePoint as the official institutional KB that nobody uses. Notion in one team. The legacy ServiceNow Knowledge15 articles that were never migrated to the modern KB module. And the inevitable Google Doc that nobody owns but everyone has bookmarked.

Faculty Google for the answer instead of opening a ticket because they cannot find the article that exists.

The KB is invisible to the user it was built for. The ServiceNow consolidation is the move that fixes that.

But the migration is not a content move. It is a content-plus-ownership move. The institutions that get this right migrate the ownership model along with the content, which is what makes the unified KB sustainable instead of immediately drifting back into fragmentation.

Bettera is the only ServiceNow consulting partner exclusively focused on higher education, and the patterns below come from R1 knowledge management engagements we have run.

Why higher ed ends up with five knowledge bases

R1 universities accumulate knowledge bases the same way they accumulate service desks: by inheritance and by tooling drift. Naming each pattern honestly is the first move that earns trust with the owners who will be asked to migrate their content.

Confluence in central IT. Usually the most-used and best-maintained KB at the institution. Owned by the IT service management lead. Contains the operational articles the help desk uses. The migration target for most institutions because the structure is the closest to ServiceNow Knowledge's native model.

SharePoint as the official institutional KB. Mandated by IT governance. Used by approximately nobody. The articles that exist are stale by years. The owners moved on or the owners are technically "everyone" which means functionally no one. The first KB readers think to consolidate, and the one that produces the least value when consolidated.

Notion in one team. The team that adopted Notion three years ago and built a good KB inside it. Active, well-maintained, but invisible to everyone outside that team. The migration is technically straightforward (Notion exports cleanly), but the political work requires confirming the owning team agrees with the move.

The legacy ServiceNow Knowledge articles. Sitting in the same ServiceNow instance the institution is currently using, but in the old KB module that was deprecated several versions ago. Nobody migrated them when the modern KB module shipped. They are findable through search and look exactly like current articles, but they are read-only and stale.

The shared drives. Department-specific. Each has a folder structure that made sense to the original creator. The original creator left the institution two years ago. The folder is still there. The articles are still there. Nobody is updating them.

And then the Google Doc nobody owns but everyone has bookmarked. The single most-used "KB article" at the institution is often a Google Doc that started as a one-time email reply and got passed around for years. It is not in any official KB. It has no owner. It is also, somehow, more accurate than 80 percent of the official KBs.

The institutions that succeed at unified knowledge name each of these patterns explicitly in the discovery phase and decide what to do with each. Pretending the Google Doc does not exist does not make it stop being the source of truth.

What unified knowledge management should mean

The most common reason knowledge consolidation projects fail is that "unified" gets defined as "central IT owns everything now." The federated content owners hear "we are taking your content and your authority," dig in, and the migration stalls.

The institutions that succeed apply the same platform-layer / service-layer distinction we use for service desk consolidation, but to the knowledge layer.

The platform layer. What gets unified:

• A single knowledge base instance on ServiceNow

• One taxonomy that accommodates the existing content variation

• One search interface that surfaces articles across all sub-KBs

• Aligned article lifecycle (draft, review, published, retired)

• Common quality metrics and stewardship rhythm

• One set of access and visibility rules

  
  

The service layer. What stays federated, by design:

• Sub-KB ownership (each federated owner maintains their content)

• Article authoring authority (the medical campus IT lead owns medical campus articles, not central IT)

• Local content rhythms (the library KB might update on the academic calendar)

• Editorial voice for department-specific content

• The user-facing experience under each sub-KB's brand where appropriate

  
  

This sub-KB ownership architecture is what makes the unified KB sustainable. The college IT lead who hears "we are not taking your content and your authority, we are giving you a better platform" responds completely differently from the one who hears "we are merging your KB into central IT."

The same orchestration framing our Pillar 1 piece on orchestration makes for the institution as a whole applies to the knowledge layer specifically.

The five-phase KM migration sequence

Bettera's five-phase KM migration sequence is the operational pattern we have seen work at R1 institutions running knowledge consolidation engagements.

Phase 1: Content audit (3 to 5 weeks). Inventory every article from every source. Article count by source. Last-updated dates. Duplicate content. Stale content (anything not updated in 12 months gets flagged). Orphaned content (anything with no clear owner or department). Typically 30 to 50 percent of articles get archived rather than migrated. The audit produces the single document that tells the institution what is worth migrating and what is not.

Phase 2: Ownership assignment (4 to 8 weeks). Where most KM projects stall. Every article that gets migrated needs a named owner. Not a team. A person. The political work is matching each article to a current subject-matter expert who will commit to maintaining it, identifying truly orphaned content that needs new ownership, and negotiating ownership for cross-departmental articles where multiple parties have stake.

This is the phase where the unified KB either becomes sustainable or starts the slow drift toward fragmentation. If a meaningful percentage of articles end the phase without a named owner who has agreed, the unified KB will look fragmented within twelve months regardless of how cleanly Phase 4 executes.

Phase 3: Taxonomy alignment (3 to 5 weeks). The technical-political work. Build the sub-KB hierarchy that accommodates the existing content variation. Define the common category model that lets articles from different sub-KBs coexist cleanly. Establish visibility and access rules (which articles federated sub-KBs share, which stay local). Define the article lifecycle states. Build the search ranking model. The taxonomy is built with federated owners, not handed to them.

Phase 4: Migration (4 to 8 weeks). The technical content move. Source-by-source content transfer to ServiceNow. Confluence to ServiceNow is the most common pattern and has well-understood paths. SharePoint requires more manual mapping. Notion exports and transforms cleanly with some scripting. Knowledge15 has a direct upgrade path within ServiceNow itself. Owners review their migrated content before cutover — this review step is what catches the migrations that lost formatting, broke links, or stripped attachments.

Phase 5: Legacy retirement (4 to 6 weeks). The decommission phase. Without it, drift begins on day one. Redirect old URLs. Disable edit access to the legacy systems. Establish an archive read-only window (typically 90 days) during which old content remains visible. Decommission the legacy systems entirely. Communications plan to faculty and staff about the change. The temptation to preserve old systems "just in case" is the most common reason unified KB programs end up rebuilding the fragmented state they were supposed to fix.

A typical R1 with three to five source KBs runs the full migration in 6 to 9 months.

The ownership model that prevents drift

The artifact that distinguishes a unified KB that lasts from one that drifts is the sub-KB ownership matrix. Every article has a named owner. Every sub-KB has a named lead. Every quarter, the named owners review their content.

The three components of the model:

The sub-KB ownership matrix. A document maintained in the unified KB itself that maps every sub-KB to its named lead, every article category to its named subject-matter expert owner, and every cross-departmental article to its agreed ownership. The matrix is reviewed at the quarterly content stewardship session.

Content stewardship rhythms. Quarterly review by each sub-KB owner. Articles past their review-by date get a flag in the KB interface. Stale articles (12+ months without update) trigger an automated owner notification. Annual archive pass that retires articles below a usefulness threshold. The rhythm is built into the platform, not run on calendar reminders.

Quality metrics the federated owners commit to. Article freshness percentage (target: 80% of articles updated in the last 12 months). Article findability rate (target: 70% of agent searches surface a relevant article in the top 5 results). User feedback rate (target: 60% of articles have at least one user rating). The federated owners co-author the metrics commitment. They commit to it. The CIO commits to it. The cabinet sees it.

This ownership model is the artifact most institutions skip — and it is the reason most "unified" KBs are fragmented again within 18 months.

Frequently asked questions

How do you consolidate multiple knowledge bases at a university?

Run the five-phase KM migration sequence: content audit, ownership assignment, taxonomy alignment, migration, and legacy retirement. The hardest phase is ownership assignment — every article needs a named human owner, not a team, before migration begins. A typical R1 with three to five source KBs runs the full migration in 6 to 9 months. The pattern that prevents drift afterward is the sub-KB ownership matrix paired with quarterly content stewardship rhythms.

What is the difference between unified KB and merged KB?

A merged KB takes content from multiple sources and puts it in one place with one set of owners. A unified KB takes content from multiple sources, puts it in one platform, but preserves federated ownership through sub-KB architecture. Unified KBs are sustainable because federated owners maintain the authority they had before. Merged KBs drift because central ownership cannot keep up with the content volume.

How do you migrate Confluence to ServiceNow Knowledge?

Confluence has the most well-understood migration path of any source system. ServiceNow's native KB import handles Confluence content directly. The technical work is in Phase 4. The political work — confirming who owns each article after migration — happens in Phase 2 and is significantly harder than the technical migration itself.

What about Knowledge Centered Service (KCS)?

KCS is the industry-standard methodology for keeping a KB current through agent-driven authoring. It is compatible with the five-phase migration sequence and most institutions running serious KM programs adopt KCS principles during Phase 3 (taxonomy alignment) and Phase 5 (legacy retirement). KCS is not a substitute for the migration playbook — it is the operational practice that runs after migration completes.

What if a federated owner refuses to migrate their content?

Acknowledge it as a political signal, not a technical obstacle. Most refusals trace to one of three causes: the owner believes the migration will dilute their content authority, the owner is invested in the existing tooling, or the owner was not consulted before the program was announced. The first is solved by the sub-KB ownership architecture. The third is the most common, and the fix is to restart Phase 2 ownership conversations with the dissenting owner specifically.

How long does KB migration take in higher education?

Six to nine months for a typical R1 with three to five source KBs. The biggest variable is Phase 2 (ownership assignment), which can take 4 weeks if the political work was done well in advance or 8+ weeks if the federated owners need significant negotiation. Phase 4 (the technical migration) is the most predictable phase and rarely runs over schedule.

How do you prevent the unified KB from drifting back to fragmentation?

Three operational practices: a sub-KB ownership matrix that names a human owner for every article, quarterly content stewardship rhythms built into the KB platform (not run on calendar reminders), and quality metrics that federated owners commit to publicly. Without these three, the unified KB will look fragmented again within 18 months regardless of how cleanly the migration executed.

Where this leaves the institution

Unified knowledge is one of the most leverageable moves a higher ed CIO can make in the ServiceNow lifecycle. Done well, it changes the relationship between faculty, staff, and the IT platform — the KB stops being where articles go to die and starts being the first place users actually look. Done poorly, it produces a "unified" KB that is fragmented again within 18 months and costs the CIO political credit they will not get back.

Bettera has a productized Knowledge Impact Accelerator engagement for higher ed institutions running this work. A focused 8-to-12-week engagement that covers Phases 1 through 3 (audit, ownership, taxonomy) and equips the institution's team to run Phases 4 and 5 themselves.

Contact Bettera if you want to talk about whether the Accelerator fits your institution, or just want a working session on the migration framework.

Bettera is the only ServiceNow consulting partner exclusively focused on higher education.