Move Data Archive to a new computer and change FQDN

If the target Data Archive has a fully-qualified domain name (FQDN) different from the source Data Archive, you must perform the tasks in this topic, in addition to the tasks in Phase 2a: Move a single server.

Important: Changing the FQDN interrupts data collection and buffering from the time you stop the source Data Archive until the time you start the target Data Archive.

Follow these steps in order to avoid data loss, client connection failures, and configuration issues:

1. Stop buffering and interfaces

   While the source and target Data Archives are down, shut down the buffering process and interfaces on all interface nodes.

   Optionally, retarget the interface node to the new FQDN and restart buffering to reduce data loss.

   For questions about changing the FQDN of a Data Archive, see the Customer Portal.

2. Reconfigure buffering and interfaces

   Configure the buffering process and the startup command file for each interface to point to the target Data Archive using the new FQDN.

   For more information, see the Knowledge Base article: KB00181 - What steps to take when changing the PI Server Host name.

3. Update PI Module Database references

   Bring the target Data Archive online and update any references to the old server name.

   • If you use the legacy PI Module Database (MDB):

     Use piconfig to export MDB tables (for example, Modules and Aliases), replace the old server name with the new one in the exported file, and then import the updated data into the target Data Archive.

     Note: The PI Module Database Builder add-in for Excel is no longer supported.

   • If you use AF:

     Confirm and update references in AF as needed. MDB migration is not required for AF-based configurations.

4. Edit the PI SDK Known Servers Table (KST)

   Update the PI SDK Known Servers Table on computers where PI SDK client applications (for example, PI DataLink) are used. Keep the old entry in the KST and change the path to the network node so that it points to the new target server.

   Note: For AF SDK clients (AF Client 2024 and later), the KST is file-based. During upgrade, the KST Migration Tool copies entries from the registry to the file automatically. Do not attempt to sync from file to registry by using the tool.

5. Preserve ServerID

   All Data Archives are identified by the server hostname that is stored in ServerID in the PIServer database table. When Data Archive is moved to a machine with a different hostname, it is automatically given a new entry in the PIServer table the first time it runs.

   To transfer the ServerID from the existing server to the target server, use piconfig to locate the existing ServerID, and then edit the ServerID on the target server. This approach allows you to transfer the ServerID without creating a new entry and thereby avoid client application connection problems.

Example: piconfig commands

If oldname is the name of the source Data Archive and newname is the name of the target Data Archive, enter the following commands:

* (Ls - ) PIconfig> @tabl piserver
*(Ls - PISERVER) PIconfig> @ostr name,ServerID
*(Ls - PISERVER) PIconfig> @sele name=oldname
*(Ls - PISERVER) PIconfig> @ends
oldname,9166a4b4-7600-4fd8-8557-f20693fff729
*(Ls - PISERVER) PIconfig> @mode ed
*(Ed - PISERVER) PIconfig> @istr name,ServerID
*(Ed - PISERVER) PIconfig> oldname,0
*> oldname,0
*(Ed - PISERVER) PIconfig> newname,9166a4b4-7600-4fd8-8557-f20693fff729
*> newname,9166a4b4-7600-4fd8-8557-f20693fff729