Developers tend not to ask themselves questions in regard to licensing laws. Instead they focus more on technical issues such as the best way of handling continual updates that may jeopardize internal security. For instance, while Word applications with integrated macros mean that updates are urgently recommended for practically every edition, Cloud products are modified more frequently. Classic on-premises applications will usually receive annual or bi-annual updates. But cloud editions can be updated up to once a week.
Test environments are also built to accommodate these frequent changes. Naturally, vendors like Microsoft have adjusted to this situation as well, and now offer companies the option to decide on update cycles more or less at their own discretion. But only at a premium.
To return to the example above: At first glance, many companies may consider it sensible to use old hardware as a test environment. Because hardware that has been in use for four years is completely amortized, and new gear can then be put in.
But this leads to a frequently neglected licensing risk: Migration and isolation (for instance in Oracle databases) only work if the licensing status is included in the equation as well. Some vendors see these setups not as test, but as productive environments. And sometimes it’s minor aspects that lead to double licensing in the event of a software audit:
- Is the system installed on the same hardware infrastructure?
- Could the test environment be deployed immediately if the productive system crashes (mirrored backup)?
- Does the AD access the productive and test environment, which could make it an integrated system?