Migrating SynergyCP primary application server

Migrating SynergyCP primary application server #

Migrating SynergyCP from one server to another requires a few steps, and has some limitations.

The migration process is intended to move an installation from same version to same version. It is not intended to likewise perform a version upgrade concurrently, as the database migrations will not run after importing the database, leading to data mismatch.

We recommend upgrading your existing installation to the latest stable release, then migrating into a newly installed stable release instance.

What is transferred during this process? #

  • The contents of the primary application database (servers, users, permissions, settings, OS Reload configs etc.). This is the vast majority of data.
  • Any publicly available packages that are installed (but not custom ones).

What is NOT transferred during this process? #

  • Bandwidth graphs: these are lost completely in moves, because the data is large and difficult to backup. However the usage totals per server (e.g. “Used 1.25TB / 10TB”) stay and continue to increment correctly, so billing will not be impacted - just the graph of how we got that billing data.
  • SSL certificate: this will need to be re-issued using the new IP address.
  • Custom add-on packages: these will need to be re-uploaded.
  • If your master file server is the same server as your master SynergyCP application, custom PXE files uploaded (e.g. drivers, ISOs, custom OS reload files uploaded in /scp/pxe/file/srv)
    • These can be retained by first using the file server sync to sync them to another file server not on the master application server, then making that new file server your master file server. As long as the master file server does not live on the same server as the master SynergyCP instance, moving the master SynergyCP instance will not affect the file servers.

Migration Process #

  • Provision a new server following our required hardware guidelines.
  • Use the backups package to make a copy of your database & configuration. Follow the backup restoration process on that page to restore the database & configuration to the new server.
  • Modify your local hosts file or setup a new subdomain name in your DNS pointing to the new IP address, with 3 separate subdomains (admin, client, and api).
    • If you chose a different set of subdomains than before, update the new server to recognize those new domains using the details under Incorrect Domain Names Set on this page. You can always change these back later before going live. Test out the application in HTTP instead of HTTPS mode using the new domain names.
  • Be careful when testing anything that could affect the production status of the other SynergyCP instance, e.g. using the forwarding gateways/OS reloads, as the two SynergyCP instances will not be in sync.- When satisfied and ready to transition to the new server, change the domain names back to the old domain names using the Incorrect Domain Names Set tool, keeping a copy of the old IP in case you need to transition back.
  • Point the DNS of the old domain names to the new IP for all 3 primary sub domains.
  • Enable HTTPS on the new SynergyCP instance.
  • Finally, login to the new SynergyCP instance with HTTPS and check that everything works as intended.

If anything does not work, you always have the option to change the DNS back to the previous IP.