Is it possible to change GUID of an instance?

By looking at the code of the InstanceGUID method in the %SYS.System class we can see where it's stored:

/// Returns instance GUID.
/// <br>
/// An instance GUID is a 16 byte (128 bit) globally unique identifier, assigned per instance of Cache installation.
ClassMethod InstanceGUID() As %String
{
    s ns="^^"_$zu(12)
    if ('$d(^[ns]SYS("INSTANCEGUID"))) Set ^[ns]SYS("INSTANCEGUID")=$system.Util.CreateGUID()
    Q ^[ns]SYS("INSTANCEGUID")
}

It's in ^SYS("INSTANCEGUID") in the CACHESYS database.

USER>w ##class(%SYS.System).InstanceGUID()
C59DD3E8-8474-4045-B252-1AF1A0D94F3C
USER>w ^|"%SYS"|SYS("INSTANCEGUID")
C59DD3E8-8474-4045-B252-1AF1A0D94F3C
USER>w $zv
Cache for Windows (x86-32) 2016.2.1 (Build 803U) Wed Oct 26 2016 13:33:05 EDT
USER>

However I don't know what might happen if you change it. Best check with InterSystems.

I think the idea of changing the ID of the instance is never a good idea whether it is ID or GUID.

While it's easy to change GUID following John's hint (if you understood the code, you already know which global node to kill, and it will be recreated on the next call), I wonder why do you want it? It seems that your instanse have migrated to another host, hense you may want to save all its requisites (including GUID) untouched. This GUID is not used by Cache itself, but may be used in some app data fields, so you may loose app level integrity.

PS. If you didn't understand the code, or are cautious to change system globals, you'd better deinstall Cache and re-install it into the same folder. System DBs would be totally rewritten while your app DBs as well as cache.cpf would be left as is.

The system that I work on used to use InterSystems' Object Synchronization feature quite heavily to keep multiple servers around the world in sync. There was one main server with about 5 "satellite" servers. The InstanceGUID of the main server was used to support Object Synchronization. When we had to clone the main server, in order to maintain proper syncing with the "satellite" servers, we reset the cloned instance with the instance GUID of the original system.

To quote a colleague at ISC:

<quote>

The instance guid is used for more than one purpose but
it is supposed to be unique to the instance. Its probably best
after cloning an instance to set this to a new value (assuming the
cloned instance isn't supposed to replace the old instance). 

</quote>

Since our clone was replacing the old one, we used the steps below to set the instanceGUID of the new instance with the GUID of the old one (and retired the old system).

<another quote>

The original purpose of this document was to list the steps to create an exact copy of the original Hermes machine, including its role as the object-synchronization partner with other servers  around the world. In order to fill this role, some additional steps were needed and these are listed here:

1. Get the unique “InstanceGUID” of the LEGACY instance of Caché by running the following command on LEGACY. Save the GUID that results from the command; it will be used later:

• HERMES>w ##class(%SYS.System).InstanceGUID()
• 34411A13-6CF9-4511-AC7D-49C2CEC6DB5B

2. Assign this value to the new Hermes instance on NEW by issuing the following commands in the Caché Terminal on NEW:
   • s ns = “^^”_$zu(12)
   • s ^[ns]SYS(“INSTANCEGUID”)=”<Guid from Step 3 above>”
   • w ##class(%SYS.system).InstanceGUID()

</another quote>

Note that this is  something that should be done unless really necessary, but it is possible.

My apologies, I realize that I answered the wrong question. 

When we created a system from a backup and wanted the new instance to have a different instanceGUID from the original system, we used the following command to give a copy of the system a new instanceGUID:

%SYS>s ^SYS("INSTANCEGUID")=##class(%SYSTEM.Util).CreateGUID()