When I came to work for my employer, all websites and applications were equipped with an October CMS content management system. The first thing you learned was how October CMS works. Because October CMS was used on a large scale throughout the organisation, this was a very pleasant workflow.
After half a year I became responsible for the "aftercare" department. All customers enter this department after the development of their website or application has been completed. In the years that followed my vision regarding the method with October CMS has changed considerably.
When I started in the "aftercare" department, I quickly noticed that there was a big difference from the versions of October CMS used. In fact, this turned out to be a major problem for the staff, causing much frustration. The versions differed so much that when estimating new extensions for the website or application it was first considered whether it was possible within that version of the CMS. The knowledge of the old content management systems became smaller due to the departure of old staff and the arrival of new staff. This gave the "aftercare" department a Senior / Junior structure based purely on the different versions of October CMS.
I remember well that my first question was, why don't you update these versions? And in doing so I got a lot of frustrations in my direction. In short, there was no budget for that. The company does not want to invest in old customers and the customer is not waiting for a big bill to update an old October CMS. So my real job had started here :)
Start at the begin of the pipeline
If you want to change something within an organisation, you have to start at the beginning of the flow. In our case, this is when the first quote is made. From that moment on, the customer must already know that after delivery, costs will have to be incurred for updating October CMS. We have included in the quotation that we will invoice the costs on a monthly basis in addition to the hosting.
We have made a proposal to the current customers of the "aftercare" department. The organisation is willing to pay for the October CMS update but after this there will be charged monthly fees. If the customer does not want this, then he is no longer entitled to support. At the moment we had no other choice.
At the start of this year, our organisation stopped using October CMS and we moved to Spinub. Spinub offers the same functionalities as October CMS, but it works as a SaaS system from the cloud. As a result, the updates and maintenance are carried out by Spinub itself. The costs of using Spinub are a lot lower than the costs we incurred for maintaining October CMS. Spinub is an ideal alternative to October CMS and fits in perfectly with the method of today.
Some other benefits of Spinub vs October CMS
· We don't have to have a login for every CMS, we can easily switch projects with one user account in Spinub
· We no longer need to arrange hosting for the October CMS instances
· The configuration is a lot easier what is a great relief for new employees
· We can configure Spinub to upload files to a fileserver instead of the server where the application is hosted. For October CMS we had to use a separate plugin for this