Migrating BuildMaster to a New Server
  • 31 May 2021
  • 4 Minutes to read
  • Dark
  • PDF

Migrating BuildMaster to a New Server

  • Dark
  • PDF

It may be necessary to move all or part of an existing BuildMaster instance to a different server.

Migrating an Entire Instance

We strongly recommend using the same version on both servers. Although you can upgrade at the same time, it can make the move process much more complicated.

Back-up from Old Server

You will first need to back up a few things from your original server:

  1. Back up your database (you should do this even if you are not moving your SQL server).
  2. Back up your encryption key.
    • Your encryption key is stored in your shared config. This is typically stored at %PROGRAMDATA%\Inedo\SharedConfig\BuildMaster.config.
    • If you are not using a shared config file, you will need to get the encryption key from your Web_appSettings.config and the App_appSettings.config files found in your BuildMaster installation folder which should be installed to C:\Program Files\BuildMaster or C:\BuildMaster.
    • If you are not using the shared config on the old server, the new server will install using the shared config. You can copy your encryption key into the shared config on the new server.
    • Your database connection string is also stored in these files if you need to find it.
  3. Back up your artifact files.
    • You can find these by looking in the Advanced Settings for the key Artifacts.BasePath.
  4. If you want your exact extensions and versions, then also back up your extensions directory.
    • You can find this in the Advanced Settings and looking for the key Extensions.ExtensionsPath.

Prepare New Server

Install BuildMaster on the new server. We recommend installing the same version as the one installed on your old server.

Perform Migration

  1. Stop all of your BuildMaster services and Agents on all servers.
  2. If you are changing to a new database server, restore the database to your new database server.
    • If your database name or SQL server name is different from what you installed with on the new server, you will need to update your connection string to point to that database in the shared config.
    • You may need to re-add the user to the database that your website and service use to access the database.
  3. Copy your artifacts to the new server. You should copy these to the exact same directory paththat the old server used.
    • If your new server has a different path in Artifacts.BasePath, then update Artifacts.BasePath to point to the restored directory path.
    • If this is different than the directory that BuildMaster was installed with, you will need to make sure that the user used by your web application and service have read/write/delete access to that folder.
    • If you have configured BuildMaster to use a Raft Repository, refer to our Raft Repository documentation for properly moving and configuring it.
  4. If you backed up your extensions, copy them to the folder set in Extensions.ExtensionsPath from Advanced Settings.
  5. On the new server, update the EncryptionKey in your shared config to the old value you backed up in step 1.
  6. Restart your application pool in IIS, and start your BuildMaster service(s) and/or Agent(s).

Migrating Application-by-Application

If you aren't happy with the way you're using BuildMaster, or need to use legacy features in BuildMaster 6.1, you can migrate application-by-application. This does not require the same version of BuildMaster to be installed on both servers.

BuildMaster 6.1 Note

When upgrading from BuildMaster 6.1, make sure to learn the new version first: review the getting started guide, run through the tutorial, and take a look at some of the example application templates. You may discover a new and better way to use BuildMaster in your organization than the way you were using. In this case, it may work better for you to simply "start over" or to manually copy bits of existing plans as needed.

Individual Application Import

Export a single application from BuildMaster at a time into a universal package, and import that package into your new BuildMaster instance. This will give you a good opportunity to discover any issues and to gradually migrate your applications to the new instance as you are able.

Generally, this approach will work best if you have a large number of applications, and some of them rely on legacy features that have been removed. This way, you can bring over applications as the legacy dependencies are removed to take advantage of new features and capabilities, while still retaining the original instance for risk mitigation.

Multiple Application Import

Once you're happy with how individual applications have been imported, you can export all remaining applications from your BuildMaster, and import them all into the new BuildMaster instance.

Additional Migration Notes

  • Consider exporting your infrastructure from the original instance and importing into the new one before doing anything else. This will prevent you from having to recreate servers, roles, and environments in the new instance. Of course, if you really want to start fresh, you may want to skip this.
  • Upgrade your Inedo Agents to the latest version, and set the Agents.InstanceId advanced configuration setting to a unique value in your new BuildMaster instance. This will allow your second instance to reuse the same agents without any interference.
  • Consider enabling CEIP. This data is very valuable in case you experience any bugs or performance issues.
  • Don't forget about permissions! Make sure you copy over any required permissions, or start from scratch if your original list has gotten too complicated.

Was this article helpful?