Licensee

Dr. Ilias Michalarias

Migrating from Legacy Licensing Solutions

One of the greatest obstacles for software vendors considering a professional licensing solutions is the migration from existing/legacy solutions. The introduction overhead of a new system might affect not only the software vendor himself, but also (and more importantly) the existing customer base.

The biggest concern in most cases is having to provide new license keys to existing customers. Ideally, the transition should be as smooth as possible, so that existing installations can continue to function seamlessly, without any manual intervention.

SLASCONE has several features facilitating the transition from legacy systems:

    • API for importing existing licenses: Existing licenses are typically identified by a unique license code or a customer number or a device id (hardware license). All 3 fields are available in SLASCONE when importing or creating new licenses.
    • API for initial activation: Initial license activation license is not only possible using  SLASCONE license keys (recommended way for projects with no legacy licenses), but also using legacy license codes or customer numbers or device ids.

 

Example of a legacy license.
An example of a license carrying a ‘Legacy Key’ facilitating the mapping to older systems.

SLASCONE thus provides a native foundation for transitioning from legacy systems.

Dr. Ilias Michalarias

On License Audits

The licensing policy of the majority of (B2B) software and device vendors falls in one of the following  categories:

  • Technical (proactive)
    • In-house licensing solution
    • External/professional licensing solution
  • Audits (reactive): no technical licensing, terms regulated on paper
  • Hybrid – combination of technical licensing and audits

The challenge for every vendor is to choose the policy that best serves both him AND his customers. After covering in-house licensing, it is now time to shed some light on the case of audits.

Audits (or contractual licensing mechanisms) are particularly common in new B2B products (startups) since vendors are justifiably more focused on sales and growth than preventing revenue leakage. In such cases, vendors retain the right to perform license audits at the customer’s site. While license auditing is a great way to technically bypass the issue, let your engineering department focus on your core, and avoid licensing headaches when installing, testing or running the software, there are aspects to be considered:

  • Resources and Growth: Auditing is a process draining valuable resources on both sides. It can become a nightmare with a growing customer base (ask Microsoft). This is one of the reasons that Software Asset Management is a big industry, with companies specializing in the field.
  • Customer Relationship: Most enterprise customers not only have no intention of cheating, but do their best to be compliant. Unfortunately, sometimes they are under-licensed without even knowing. Instead of having to react, they prefer to prevent. It is crucial for vendors to realize that auditing is a reactive solution that may catch the customer by surprise and create unnecessary tensions. Any proactive solution would have prevented any potential mess.
  • Revenue Leakage: Lack of technical licensing facilitates (if not guarantees) revenue leakage. Few vendors have the capacity to perform regular audits. Therefore, in the long term a revenue delta is almost certain.
  • Lifecycle/Dynamic Entitlement: In a time in which customers demand maximum flexibility and pay as you go models, audits will always struggle to catch up with the constantly changing requirements.
  • Analytics: Without technical licensing, vendors squander the chance of real-time access to a synced customer database, providing valuable information about the real customer landscape.

At the end of the day, the question of audit (or any other licensing policy) suitability depends on the application and the (size of the) customer base.

Dr. Ilias Michalarias

Feature Lifecycle and Existing Customers

Being responsible for our licensing, every time that a new, to be licensed feature was developed, I had to update the (master) license definition. In parallel, our engineers had to make sure that the software worked seamlessly with our licenses. While neither this process nor the subsequent generation of new licenses was a headache, existing licenses posed a real challenge:

  • Should existing customers be able to use the new feature or not?
  • Do they need a new license?

The second question is not really worth asking. ISVs cannot afford to issue new (substitute) licenses very frequently. Not only does it consume a lot of resources, but above all the end-users are not going to be particularly amused.

Similar questions arise when features are removed or bundled together. As a product manager I needed the flexibility to change things with minimal engineering effort (ideally without involving our engineers at all) and without existing end-users noticing. Otherwise, our future growth would be severely hindered by our past.

Dr. Ilias Michalarias

Automating the Licensing Process – A Blessing for the Vendor AND the Licensee

As I explained in my first post, my first acquaintance with licensing came through my analysis requirements. Since we already had an in-house solution (which experienced colleagues of mine praised, considering it superior to others) and everything seemed to work fine, I naively believed that licensing would not considerably bother me. After all, product managers are supposed to be visionaries crafting new functionality and ways to sell their product, right?

Well, not exactly… Here a (non-exhaustive) list of time consuming issues I had to cope with:

  1. Hardware Migration: One of our products was device-bound, which meant that could be activated on maximum one device. While our mechanism did function, our customers could not self-administer hardware migration. In other words, we had to manually update the license database in order to register a new server name.
  2. Peaks: Very often, clients requested peak licenses in order to tackle seasonality. Unfortunately, peak licenses were not part of our in-house solution, so I had to abuse our trial licenses, which resulted in a vicious spaghetti landscape.
  3. Trials and Renewals: I had to authorize every trial license request and (even worse) it’s in many cases renewal. Since renewals were not part of our in-house solution, renewal meant a new trial license.
  4. Partners/Resellers: It is great to have additional channels, but there are several issues to consider: how to create licenses for a partner organization and its employees. How to make sure they are not (intentionally or not) abused. How to deal with expired partner deals etc.

So, I had to learn the hard way, that the licensing could be indeed optimized. Not only in order to save internal resources, but above all in order to improve the end-user (Licensee, partner or reseller) experience.