New knowledgebase setup create directly in production or in a lower environment and promote upward.

[JulietChicago]

Hello,

As a best practice do people create the  knowledgebase in a lower environment and then move it to production? 

I don't mean the articles just the knowledgebase structure (mostly what is on a knowledbase record).  I thought  we should create it in a lower environment and then move it to production but I have heard we should just create them in production directly . 

[Laveena-Agarwal]

Hi @JulietChicago 

I couldn’t find any official documentation; this response is based on my personal experience: -

For Knowledge Bases, the environment of creation doesn’t matter much. Even if you create a Knowledge Base directly in production, you’ll still need one in lower environments to support UAT and future testing scenarios.

 Knowledge Articles

• Always authored, reviewed, and published in Production only (they’re content, not configuration).

• Lower environments might have sample/dummy articles for testing only.

[Jessica Spates]

You would want to create your structure in the lower environment. Determine from the start your approval process, review cadence and how you want to be notified, and who will oversee of knowledge as a whole. I have seen this done many ways, and those without a knowledge manager tend to see the whole thing fall apart. The idea of everyone managing their own stuff seems great, until nobody knows what they are doing and get too busy to care that the article is 2 years of out date and people stop using the system and go back to Sharpoint. You want a system of truth, so plan for success. Content owners is a better approach in that case, but you do need someone to oversee the full catalog of knowledge and keep it organized, be a point of contact, and reach out to teams when they see a need for instructional guides through your ticketing system reporting.  So get that set up first. Then determine your internal vs external knowledge and branding to your company at large. Nobody will use your knowledge base if it does not look professional and well maintained. Document how you will manage your knowledge base, then practice with it in Dev. with a few articles. Once you are happy with the results, launch to your prod environment and upload your articles, videos.. etc. 

This is more than what you were asking for, I know, but I agree there is little guidance on this topic and want to see you succeed! 🙂 Best of luck! 

[Dave Littlejohn]

I think both are valid but for different reasons.

What I have done in the past:
When first implementing knowledge management with IT, start in lower environment so that all knowledge bases, categories, workflows, approvals, etc. are built out, tested and validated, and then able to be trained to IT before going live in production.

When a new knowledge base was needed for IT due to restrictions needed (via user criteria), that was created in production as the process has already been established and tested.

When there was a new module that will be leveraging knowledge (e.g. HR), we started once again in the lower environments so the knowledge bases, categories, workflows, approvals, etc. are built out, tested and validated, and then HR trained before going live in production.

[Eoghan Sinnott]

Hi, 

I think it depends on what stage of your Knowledge Management journey you are on. We have quite a mature Knowledge management process, and as part of our services we offer teams the ability to store their internal procedures in their own Knowledge base with User Criteria applied that they can manage themselves. For these types of requests we create them directly in Production. It's something we've done dozens of times and don't feel the need to have it tested in the lower environments and be brought up. We do clone backs a couple of times a year as part of our platform upgrades so it will eventually be added to the lower environments as part of this.

If it's for something brand new that we feel requires testing, like new Approval or Retire workflows, utilising new functionality that has come as part of an upgrade or anything else that we think needs verifying before going "live", then we would create it sub prod and move it up.

Regards,

Eoghan

🌟 ServiceNow Rising Star 2025

If you found my reply helpful, please consider clicking Helpful or Accept as Solution to assist others in the community!