Problem:

Enable migration out of the current Document Management solution, if it makes sense from a fiscal and labor perspective -


Description:

The document management solution that we had was "big," it cost a lot of money, and we didn't have a need to leverage more than ~40% of its capability. We often found ourselves questioning why we continued use it... Oh yeah, we were "locked in."

We wanted to find a solution which cost less, was fairly simple to use, had version control, integrated with our existing systems, and could be used for runbooks and other knowledge articles in response to alerts from our monitoring systems; bonus points if it was able to be directly linked from alerts or notifications.

Check it out:

Demo

What did we do?

I looked at several other document management systems, and while nearly all of them were cheaper, they all still required more complexity than I thought we needed to achieve the goal.

Then I started thinking... GitHub has version control, it's accessible via API, you can run queries against it, and the only different in document formatting was a move to Markdown, which most of us were already embracing with code documentation. And the best part? It's a solution we're already paying for... so, it was essentially "free."

So, I searched a bit for a snazzy front-end to put on it (docsy-jeckyll), modified the backend code to fit our document structure, and setup a pilot.


What was the outcome?

The pilot was an immense success!
  1. - We were able to send alerts with variable direct links to runbooks, or send variable links that would perform searches for runbooks
  2. - The cost was $0 and the savings of not renewing our other document solution was tens of thousands
  3. - It was simple to use, since we already used Markdown
  4. - It is version controlled
  5. - We can easily integrate it with other solutions since it lives in GitHub


Any lessons learned?

Sometimes the simplest answers are the best ones.