The Zurich release has arrived! Interested in new features and functionalities? Click here for more

Tips on Moving a Knowledge Base

DavidBReynolds
Mega Guru

Hello,

My company is modernizing our instance of ServiceNow, moving from an older, customized version to one that is more "out of the box." When we make the move, the knowledge bases will be given the "lift and shift" treatment.

If have gone through something similar, then:

  • What do you do before moving content? For example, did you retire old Draft articles?
  • What do suggest a knowledge author do to make the process easier and smoother for the people moving the content?
  • What issues did you have either during or after the process?
  • If you could go back, what steps would you take before moving knowledge bases from one instance to another?

We are currently using Xanadu. I'm not sure if the new instance will be Xanadu or Yokohama. I'm guessing that I have until early October or later so I have time now.

 

Any comments, ideas, thoughts or suggestions are greatly appreciated. 

Thank-you

>>Dave Reynolds

1 REPLY 1

kaushal_snow
Mega Sage

Hi @DavidBReynolds ,

 

Key Steps Before Moving KB Content........

 

** Clean Up Unnecessary or Outdated Content: Retire old draft or outdated articles to keep only relevant, published content. Use ServiceNow retirement workflows for this. Conduct a content audit to identify redundant information.

 

**Prepare the Target Instance: Ensure that the Knowledge Bases (kb_knowledge_base) and any Categories (kb_category) exist in the target environment, ideally with the same sys_id, or you'll need to adjust references later.

 

** Migrate Using Export Sets 

 

  • Use System Export Sets:
  • First export the kb_knowledge_base records.
  • Then export the kb_knowledge articles.
  • Import them into the target instance via Import Sets.


** Handle Dependencies and Attachments: KB migrations often require transferring data from related tables such as: kb_uc_can_read_mtom_list, sysapproval_approver_list, sys_domain, kb_feedback, kb_use, kb_version, sys_attachment, m2m_kb_task. Reference these dependencies to ensure links, approvals, categories, and version histories remain intact.


Please Note: What Knowledge Authors Can Do to Smooth the Process (important) ...................

 

** Perform a Content Review: Flag and retire old drafts or irrelevant versions to save migration effort.

** Consolidate Metadata: Align author names, categories, and user criteria to prevent mismatches post migration.

** Coordinate Workflow States: Object synchronizations between instances e.g., retire vs publish states and ensure workflows align.

** Document Dependencies: Communicate with your migration team about workflows, approvals, and ACLs tied to KB items.


Common Issues to Watch Out post upgrade:

 

** Missing Reference Data: Without identical sys_ids (for KBs, categories), references may break post import.Lost Version Histories: If KB articles use versioning (kb_version table), you may miss older versions unless they're explicitly migrated.

 

** Missing Attachments or Metadata: Ensure all associated files, feedback, and approvals are included during export.

 

**Broken Workflows or Approval Logic: Migrated articles might lack proper workflow linkage unless workflow and wf_context tables are also moved.

 

If you found my response helpful, please mark it as ‘Accept as Solution’ and ‘Helpful’. This helps other community members find the right answer more easily and supports the community.

 

 

 

Thanks and Regards,
Kaushal Kumar Jha - ServiceNow Consultant - Lets connect on Linkedin: https://www.linkedin.com/in/kaushalkrjha/