Hi Team.
Our clients decided to create a fully new BigFix instance. Later, we want to migrate all clients to new BigFix instance.
(for some reasons we can’t “migrate” the server. We need fully new instance).
So the question.
Can I reuse BESLicenseAuthorization to create a new BigFix instance?
How the “licensing” process working?
Can I just create a new BigFix Server by reusing BESLicenseAuthorization file?
Or I need to buy a new license?
Hi Anton,
Yes, you could reuse the same license file under certain conditions:
the new BigFix server will have to leverage the same DNS name/alias or IP address that is specified in the masthead/license
Have a look at the migration documentation; even if you want to install the server from scratch, you are going to “migrate” the license: https://help.hcltechsw.com/bigfix/10.0/platform/Platform/Config/t_mgrt_rootapp_server.html
No need to say, only one BigFix Server with the same license can be running.
Hi Daniele.
Thank you for your answer.
As far as I understand, If I want new IP and DNS - I need new license (or communicate with HCL to swap IP and DNS. What sound not very promising).
We have being trying to convince our clients just to migrate the server or just perform OS and SQL upgrades to comply with Security team Policies, but if they want to spend extra $… This is their choise 
Yes, correct. You need to request a new license that will replace the old one.
You need a new License Authorization File, but that doesn’t mean you have to purchase new licenses.
You can log in the Licensing Center site, and reduce your allocation of licenses under the old masthead, and create a new License authorization file using the freed licenses.
After you install the new server, as you move clients from the old masthead to the new one, just keep moving licenses in the License Center site.
It might be an idea to consider creating the new licnese to a CNAME for your new server if not already. This makes re-using the existing masthead for future new builds or server migrations much easier as you can have a totally new FQDN for the root server but still control what server endpoints will connect to via DNS record changes. This made it much easier for us when moving from 8.2 to a new build 9.1…which was admitedly many years ago, but also subsequent occations when we have migrated to new hardware
Hi Jason.
That sounds great. I will also put this solution on my boss table.