During a recent recent CMS vendor selection exericise I took a step back and realised how much time and effort was being spent on getting a firm price on the cost of each CMS product. CMS licensing is complicated as it depends on so many variables e.g. number of users, sites, servers, cpu’s, environments etc.  CMSWire posted on twitter


To help me write this article I enlisted the help of the folks on twitter, so why is CMS licensing so complicated?

Twitter feedback

Jon Marks (@mcBoof)  has written an excellent article titled When CMS Licensing Shafts Architecture , where comprises have to be made to the CMS solution architecture due to how products are licensed. Jon’s article states that a CMS may be licensed :

  • A per site or domain cost – the vendor should clarify about what constitutes a “site”
  • A per machine / CPU cost – some vendors which will charge extra for each server a particular product is deployed.
  • A cost for each named CMS user or editor or a concurrent user limit .
  • A cost depending on the environment e.g. development, test, staging, production and disaster recovery.

Useful replies from @scrump & @proops below :


One size does not fit all


twitter post regarding Modules and maintenance



When buying a CMS what are you buying ?

To try to answer why it is complicated let’s look at what you are actually purchasing :

Product Description
Core product This is usually the CMS server. As above the price of the core product will depend on the number of sites, users, servers etc.You will want to ensure that as many of your requirements as possible are covered in the core product.If you need additional functions then you will need to look at the availble modules.
Modules Any number of modules may be required to meet your requirements, this is an area where you could very quickly blow your budget! Possible modules include: Personalisation, dynamic delivery, social media tools, digital asset management, e-commerce catalogues, integration with third party products like Sharepoint, CRM systems etc.Modules may be licensed similarly to the core product and will attract additional costs on for each environment as well as ongoing support.
Databases & Application servers This will need to include licenses for Oracle/SQL Server database and applications servers etc.
Hardware Architecture You have to factor in the architecture as the number of Servers & CPU’s may affect the final price.It can be difficult to establish the architecture at the outset as with a dynamic CMS it depends on how the CMS has been implemented and how it will scale. Usually a sizing exercise is required which looks at the traffic levels now and into the future before a recommended architecture can be arrived at
Non production Environment licenses Non production environments also attract a cost though this is usually at a fraction of the full price. These could include Test, development and disaster recovery environments.
Maintenance & Support This is an annual subscription cost which is usually around 18-20% of the list price, and not 20% of the discounted price you may have managed to negotiate!

In summary :

Buying a CMS is fairly complicated as it involves buying software as well the hardware, hosting and support. Having a complex model may be necessary because:

  • One size doesn’t fit all. Why should you pay for functions that you will never use? You will not have the same numbers of users or sites as the next client.
  • Modules provide the flexibility of including additional functionality at a later time. This allows clients with a lower initial cost to get started. However modules can significantly increase the CMS license cost as they may also be licensed by site and users, there is also the additional support & environments costs to be considered.

What I would like to see is:

  • Openess and transparency in pricing. A fixed price list, with same prices for all customers. I regularly see quotes provided to more than one client at the same time, and know what is each
  • Simplified pricing. As above a standard price list so that clients know how much each and module costs, and what would happen if they changed X. We all know the price of an 60 GB Ipod classic.
  • A definition of what is a site. Clients may need to implement microsites for marketing campaigns under specific domains, are these sites? Even if they are shortlived ? What about subdomains?
  • Serious thought given to CMS scalability and performance as part of CMS selection & licensing, how will the architecture scale to cater for additional content and site visitors? Architectural changes further down the line could impact on the licensing e.g. additional servers and CPU’s usually mean additional license costs.

What I would welcome the end of :

  • Highly inflated “optimistic” list prices which are then heavily discounted.
  • Pricing by
    • CPU core, dual core are now more expensive the quad core.
    • Registered public user
    • CPU Megahertz (I think this practice may be dead, but is related to CPU cores).
    • Content Editor, concurrent editors make more sense.
  • Additional costs for commodity functions such as blogs, forums, surveys, polls, accessibility checking, link checking etc. Clients expect do not pay extra for these functions.

What has your experience been when pricing CMS systems, has it been straightforward or are you having to go back to the vendor every time a change is needed?