Moving to ServiceNow Knowledge Management: Migration Considerations

Migrating to ServiceNow Knowledge Management means moving articles from their current platform into ServiceNow. The work starts with an audit of article count, age, update frequency and owners, then covers field mapping, version and image decisions, role-based access and cutover strategy.

Evaluating Your Current Knowledge Base Inventory

Before moving to ServiceNow Knowledge Management, conduct a thorough audit of your existing knowledge base. Examine every platform you currently use—whether it’s Confluence, SharePoint, a custom wiki, or disconnected documentation scattered across email and file systems. Record the total number of articles, their age, frequency of updates, and current access patterns. Understanding your knowledge assets prevents losing critical information during migration and identifies redundant or outdated content worth removing.

Classify articles by category: troubleshooting procedures, configuration guides, business process documentation, FAQ collections, and reference material. Some organisations discover that content spread across systems contains overlapping or contradictory information. Identify these conflicts now rather than after migration. Assign an owner to each article category and establish a baseline quality score—whether articles include screenshots, are searchable, have defined owners, or include useful metadata.

Data Structure and Mapping Strategy

ServiceNow Knowledge Management stores articles in the kb_knowledge table, with knowledge bases and categories held in their own tables.. Your current knowledge base likely has a different structure. Map each existing article field to ServiceNow’s article structure: short_description, text (article body), category and subcategory hierarchies, workflow_state, and meta_data fields. If your current platform uses tags, categorise them into ServiceNow’s category structure or custom fields depending on your taxonomy complexity.

Decide whether to preserve article versions and audit trails from your previous platform or start with a clean slate. For critical procedures, version history can be important; for general documentation, historical versions may add clutter. Plan how you will handle images embedded in articles—ServiceNow expects images as attachments with proper reference in the HTML body. Test your data mapping with a sample of high-value articles to verify formatting, image placement, and metadata accuracy before running a full migration.

Consider whether your current knowledge base supports role-based access controls. If your existing KB is organisation-wide but Knowledge Management will serve specific IT Service Management groups initially, plan how to manage permissions and visibility during cutover. ServiceNow uses knowledge_category_access and knowledge_base records to restrict content.

Cutover Options and Phasing

Three primary cutover strategies exist: big-bang (migrate everything simultaneously), phased (migrate by category or business process over weeks), or parallel (run both systems for a period). Big-bang migrations are fastest but highest-risk; phased migrations allow users to validate content progressively and reduce change burden. Parallel operations let users cross-reference the old and new systems but require synchronisation overhead if either system continues to receive updates.

Most organisations choose a hybrid: migrate high-priority content immediately (troubleshooting guides for Incident Management staff, IT asset information for Hardware Asset Management, HR process documentation for Employee Service Management), then schedule secondary content over subsequent weeks. This approach builds confidence in the system through early wins while deferring lower-priority documentation. Define success criteria for each phase—for example, a troubleshooting category phase is complete when most support staff have used Knowledge Management to resolve at least two tickets.

Plan decommissioning of the legacy system carefully. Set a hard cutoff date to prevent the knowledge base from diverging. After cutover, disable editing in the old system and redirect users through a transitional page explaining where to find articles now.

Common Risks and Validation

The most common migration failure is broken internal cross-references—old KB articles link to each other, and links must be updated in the ServiceNow format. Automated link mapping helps but requires manual verification of target article accuracy. Broken images are another frequent issue; verify every image renders correctly after migration and adjust HTML formatting if needed.

Content quality often degrades during migration. Duplicate articles may be discovered and require consolidation. Articles with stale information need immediate review and archival. Establish a post-migration review period where knowledge owners audit their content within the first week and fix obvious errors or formatting issues. Include this review cycle in your project timeline and resource planning.

Validate that the ServiceNow search functionality returns expected results. Configure search to use article title, short description, and body text appropriately. Test searches for common troubleshooting terms from your current usage logs and ensure articles appear in expected rank order. Perform user acceptance testing with a sample group from each audience (IT staff, business users, managers) to confirm findability meets expectations. Missing or poorly-ranked results often indicate that article metadata or categorisation requires adjustment.

Stakeholder Preparation and Knowledge Roles

Knowledge Management depends on ongoing contribution from knowledge owners, subject-matter experts, and IT staff. Before migration, identify who approves new articles, who can edit existing articles, and who can only view content. Create knowledge_user roles for each audience. Assign at least one knowledge_manager to oversee the category structure and approve new categories as business needs evolve. Train knowledge contributors on the ServiceNow article template and editing workflow before content goes live.

Communication during migration is critical. Announce the new system several weeks in advance, explain why Knowledge Management improves the current state, and demonstrate the search interface in staff meetings. Publish a quick-start guide showing how to find troubleshooting articles, subscribe to category updates, and provide feedback. Expect the first weeks to reveal usability issues or gaps in content; set up a feedback loop to capture these insights and prioritise fixes or new article creation accordingly.

Sorting legacy content by what it is for before anything moves

Many migration plans treat the legacy estate as one pile to be carried across. A better first step is to ask what each piece of content is for and whether anyone still uses it. A document that answers a live question for a team every week deserves a place in the new base. A page that was written for a system retired years ago deserves to be archived, not migrated. Between those two extremes is a large middle group that needs rewriting before it can be trusted, and that group is often where most of the effort goes. Sorting the estate into those groups early keeps the migration budget honest.

Rewriting links and images so the reader’s trail survives

Links between old articles are where migrations tend to lose readers. A legacy page may link to a section of another page using an anchor that does not survive the move, or to a file path that no longer resolves. Build a list of every internal link from the legacy estate before migration, then decide for each one whether it should point to a new article, to a merged article, or to nothing. Do not leave a link pointing at a placeholder. A reader who clicks a dead link into a new base often assumes the new base is unreliable and stops searching it.

Images need the same attention. Screenshots tied to an interface that has changed are a common source of confusion, so decide whether each image should be replaced, removed or kept with a caption that states the interface version it shows. Confirm that the attachment or embedded image renders in every audience the article is published to, not only in the staff view.

A cutover runbook built around a delta load

The cutover itself is often the riskiest moment, because content keeps changing in the legacy estate until the new base takes over. A delta load is the mechanism that carries those late changes across. The sequence below is a workable pattern when the legacy estate can be exported in full and the new base is ready to receive it.

1. Freeze new publication in the legacy estate for the agreed window, and announce the freeze to every author in advance.
2. Run the full export, and reconcile the record count against the inventory built in the triage step. Any difference needs an explanation before the load proceeds.
3. Load the content into the new base in a staging area, and check titles, owners, categories and visibility for every migrated record.
4. Apply the link and image corrections, then run the relevance pass on the highest-demand topics using the phrases recorded from the legacy search logs.
5. Load the delta, meaning the articles changed since the full export, and repeat the reconciliation for those records only.
6. Switch the legacy estate to read-only, place a redirect notice on its home page, and record the time of the switch so that later questions can be answered from a fixed point.

When to leave content where it is

Not everything should move. Some content is better kept in its source system because the source has the right controls, such as a records system that enforces retention, or because the content is shared with a partner who will not move. Consider a hypothetical team that keeps a supplier contract library in its original document store and links to it from the knowledge base. The link is more honest than a copy that can go out of date. Make the exception list explicit, with an owner for each item, so it does not become a silent second knowledge base.

How should attachments that were never public be handled?

Check the original access rules before moving them, and do not assume that a restricted attachment should be open because its article is. Decide whether the attachment is still needed at all, and if so, set its visibility to match the new article’s audience.

Should old article identifiers be preserved?

Keep a mapping table from the old identifier to the new record, and make it available to the support team. Staff who remember an old reference will still ask for it, and the mapping saves time without requiring the new base to reproduce the legacy numbering.

What is the best way to handle duplicates from two teams?

Ask the owners to agree a single article before the move, with a named owner who can answer questions about it. Keeping both and redirecting one to the other is acceptable only if the redirect is visible and the second article is removed from search.

Next step

For reconciliation detail, see the data migration validation guide. The testing and acceptance checklist covers testing layers for the migrated base and is worth reading before the trial load.

Keeping a migrated knowledge base current without a dedicated knowledge manager

You can keep documentation current without a full-time knowledge manager by making review a small, scheduled job tied to each article’s owner, not a project someone has to remember. Every article gets one named owner, a review date and a rule for what happens when the review date passes. Articles without a live owner tend to rot, and tooling alone rarely fixes that.

Split the estate by how often each category changes. A working split that most teams can apply is:

• Fast-changing procedures, such as those tied to a release or a tool version: reviewed on each change, with the change owner named on the article.
• Stable reference material, such as policies or how-to guides: reviewed on a fixed cycle that the owner agrees to at migration.
• Historical or one-off notes: archived unless someone confirms they still answer a live question.

Let search tell you what to review first. A query that returns nothing useful, or an article that people open and then leave, is a review trigger. Read the search log every month, pick the handful of frequent queries with weak results, and give each one to a named owner. That keeps review effort on the content people are actually looking for. Teams without spare time for this loop can hand it to ongoing knowledge base upkeep.

The platform choice matters less than the ownership rules you set before the move. Whichever tool the content lands in, the rules decide whether it stays accurate. For the governance side in more depth, see the knowledge management governance model.

A concrete version looks like this. The service desk lead owns the troubleshooting category and sends each stale article to the person who last edited it. If the owner does not confirm it within an agreed window, the article moves to a holding area that the team controls, where it is kept for anyone who still needs it but is no longer treated as current guidance. Choose the window to match how fast your procedures change.