Does the following story sound familiar?

“Hello, it’s Steve in Product Management.”

“Hi Steve, it’s Ian in Sales.  I’m looking at the price book and there’s a different license part number for every version of the product. I see dozens of them.  My customer wants to use various versions of the product across teams.  Can I just put the latest version on the quote and tell them they can use the licenses with older versions too?”

“I’m not sure. You will have to ask Legal.”

“I need to get this quote out now. Why is it like this?”

“I’m not sure about that either. You’ll have to ask Operations.”

Including product versions as attributes of your license part numbers may seem like the obvious right thing to do.  In many cases it works perfectly well. But before going down that path, you should think through a few factors.

While each company is different, it is common for software vendors offer license part numbers that are not associated with a specific software version.  That is, of course, unless the vendor wants to sell a specific version of the product and not entitle the consumer to a newer revision of the product when it becomes available.

The common practice is to keep the license part number “versionless” and fulfill the order with the latest shipping version of the product. In addition, these companies will typically develop and publish a version entitlement/support policy which would say something to the effect of the purchase of a license entitles the customer to the current shipping version plus X number of releases in arrears.

The thinking in this type of model is that the customer is really purchasing a product or set of capabilities and they should be able to use whatever version of that product makes sense for them within reason.

Another benefit from this model is entitlement clarity. The license part number should be the clear governing entity in the vendor’s entitlement system as ownership of the license part number grants the customer permission to use the software. If the license part number is constrained to a version, it becomes unclear what happens when the vendor releases a new version of the product.

Let’s look at an example where a customer buys a license of part number 1111 defined as “PRODUCT XYZ VERSION 7.0”. In this case, it is not clear what should happen if this customer needs to outfit a user with version 6.0 of the product.  At face value, it appears as though the customer would not be entitled to do so.  The same mystery applies with new versions.  When the vendor ships product XYX v8.0, is this customer entitled to use it?  If so, it’s certainly not intuitive.  The vendor should either publish the upward entitlement policy somewhere (effectively rendering the version in the part number irrelevant) or migrate the customer’s entitlement in its database from license part number 1111 PRODUCT XYZ VERSION 7.0 to part number 1112 PRODUCT XYZ VERSION 8.0.  Data migration exercises are typically not without a great deal of effort or friction.

Lastly, license part numbers without versions tend to make things easy on sales teams when creating customer quotes and orders as there is little debate over which part number to use and fewer part numbers to filter through.  On the operations side of the house, having to create new license part number for each product release can be a nontrivial exercise.


  • License part numbers with versions (e.g. PRODUCT XYZ VERSION 7.0) can indeed work well for companies whose policy is to entitle and constrain a customer to a specific version of the software and sell new versions as a separate revenue event.
  • License part numbers with versions tend to be problematic for vendors whose policy is to allow the customer to use previous and newer versions of the product. The problems revolve around uncertainty of version entitlement.  Uncertainty in the area of entitlement leads to questions of whether or not the company is in compliance.
  • License part numbers without versions tend give the customer latitude to use versions in accordance with the company’s versioning policy.

There is no single right answer for all cases but keeping the side-effects in mind can help guide you to a model that best fits your business.