Introducing a new license management solution to your back office can bring tremendous value to your business. But without proper planning, the transition from legacy system to new solution can easily go awry.
This type of system migration is not to be confused with data migration, a hugely important component in its own right. Data migration, the process of moving data from one system to another, favors a user-centric approach. It’s considered best practice to examine the use cases surrounding your end customers from all angles, as this will help you determine exactly which data sets to transfer based on your current requirements, and the impact this will have on your end customers.
Let’s take a look at some of the common factors and dependencies.
There are many reasons to choose subscription licenses over perpetual and this certainly is one of them. Subscriptions keep your licensing data fresh so you can usually enjoy a clean set of data with each subscription renewal. Expired entitlements are a gift to IT teams faced with migrating data to a new system. In most cases you can take the expired subscription entitlement set and send it off to a data warehouse.
Perpetual licenses add to the complexity of the transition and increase the data set that will need to be migrated to the new system. However, don’t assume you need to bring your entire legacy data set into the new system. There’s a good chance you can draw a reasonably safe line between the data you need to migrate and the data that can live in a data warehouse, which your Support teams can query down the line if needed.
For example, you may have customers who purchased perpetual licenses but have not been on support for years. That data set might be able to go into the warehouse, and if by chance you need it later, you can import it into the new system ad hoc.
Understand your company’s policy for providing license key services for customers not on support. In other words, if you gave a customer a license key locked to a specific piece of hardware and they chose to drop support, is the customer still entitled to come to you later for a copy of the key or a new key if the hardware has changed? If the answer is no, you could choose not to bring any customer data that falls into that category into the new system.
Upgrade Entitlement Model
Your upgrade model has a big effect on the complexity of the transition from old to new back office. The simplest case is when you require your customer to purchase an upgrade to a specific version. This model shines a spotlight on what versions of the software and keys you need the back office to support. This significantly helps you plan and make decisions.
In most models, your customer is entitled to the latest version of the software as long as they are on support. This makes it easy for your customer but adds complexity to your transition model because you have to make assumptions as to what version of the licensing you need to support.
Running Dual Systems
Running the new system in parallel with the legacy system is an idea that’s often floated about. Buyer beware: it can create more problems than it solves! The idea here is that orders placed after a certain date will flow to the new system and the old system will be used to generate keys from orders placed before that go-live date. If you sell perpetual licenses, you will probably be living with the old system for a long time. Your licensing data will live in two places and the value of your new system will be greatly diminished.
It’s also common to have the new system manage licensing for only certain product lines. This can be a viable solution, but just make sure you consider the case where a customer places a single order for a product that goes to the new system and a product that goes to the old system. Will they have two separate customer experiences? That might not be ideal.
I’ve performed multiple back-office transitions in my career and as daunting as the Big Bang approach may seem, I tend to lean in that direction in most cases. While it can be the most work in the short term, the benefits of having one system, keeping your data in one place, and most importantly, delivering one customer experience ends up being worth the effort.
Customer Upgrade Slope
The rate at which your customers upgrade can also help simplify your transition. The quicker they upgrade to your product set, the smaller the data set you need to bring to the new system and, perhaps, the fewer use cases you need to support. Examples of this include virus scanners and security software where it doesn’t make sense for customers to be on old releases.
Make sure you know if your company supports partial activations. For example, if a customer placed a single order for a single line item of 100 licenses, is your customer allowed to activate a portion of 100 and then come back later and activate more? I call this partial activation vs. full activation. With full activation, you know your customer either activated a line item or they didn’t. This means the line item in the new system will either be fully activated or fully available. With partial activation, you need to make sure the new system knows not only the quantity purchased, but also the quantity activated and available.
Replacement License Files
This is a tricky one. Is your license generation model one in which you give your customer a full replacement license file per system for each license generation? In other words, if a customer received a key for Product A on system 1 and then later activates Product B for the same system, do you give them the key for just Product B, or do you give them a replacement file containing keys for Products A and B? In case of a replacement, your new licensing back office must have access to the legacy activation data so it can produce the proper license files.
With all that said, here are a few questions that might help identify your key use cases:
- Once the new system goes live, what is the workflow and experience when a customer places a new order?
- What is the customer experience when they need a key from an order placed before the new system went live?
- If the new licensing system offers a web portal where a customer can see their license activations, can they see license files generated by the old system?
- If I have a license key for Product A on system X and then I activate a license for Product B on the same system, will Products A and B run?
- What is the experience if I have a license key generated by the old system and I need to move the software to a new system?