Migrating Ignition Gateways
On projects, a fairly common task is moving Ignition gateways from one server to another. It might be because we are developing on one of our servers and need to migrate to a client’s server, or the client is upgrading their backend infrastructure and we need to migrate their gateway to a new machine.
Migrating an Ignition gateway is different than upgrading a gateway in place and has a few more steps involved.
A Real-World Ignition Gateway Migration Example
This post was inspired by a recent cutover from development to production. Corso Systems developed a new OEE Engine for a customer with an existing Ignition Gateway. We connected their gateway to a development database which was also connected to our development gateway. (As we were developing, we were working with real-time data from their system to monitor downtime.)
As part of the push to production, they wanted to migrate their Ignition gateway to a new server. All of their PLCs and databases remained the same, so we needed to import our project resources, database connection—and migrate the system to a new server.
We agreed to do the work on a Saturday morning when their facility was down for cleaning. Prior to the move, we set up the new server, installed Ignition, installed our Postgres database instance, took a backup of their existing Ignition gateway, and waited for the all clear.
Once they were ready, we de-activated the license on their old gateway and shut down the server. We restored our gateway backup to the new server, activated the license, and migrated our Postgres database backup to the new server. Their IT team updated the IP address on the new server to match the old one. This eased Ignition Vision and Perspective client connectivity. Then, we pointed Ignition at the new database.
With our approach, Ignition was only down for four minutes total: two minutes for the Ignition gateway to come up and get re-licensed, one minute for IP address changes to propagate across the network, and one final minute for everything to come back up and get verified by an operator.
Let Corso Systems Handle It!
We can quickly migrate your Ignition Gateways with an absolute minimum amount of downtime.
Schedule a short call with Cody Johnson in sales to get started today.
Or contact us with your project details.
Cutover / Downtime Considerations
When migrating Ignition Gateways, there will always be some downtime. But, with a plan and by handling most of your backend work ahead—with only the restore causing a backup, downtime will be minimal. You can further reduce the potential for excess downtime by using redundancy or a high availability architecture. Usually, we anticipate between 5 and 15 minutes of downtime depending on the system’s complexity, how long it takes the gateway to come back online, and for the comms to come back online.
For a cutover from a development environment to a production environment, it’s advisable to block out an hour or a day for downtime. This will allow time for migrating any databases and data you need from the old gateway to the new one. It will also provide a natural cut off point for data going on the old system vs. data generated on the new Ignition gateway.
Server Infrastructure and Networking
First, you’ll need a new server setup. We typically recommend using the same operating system on the new server as on the old server—ESPECIALLY if you are using Sepasoft Modules. We’ve found a few instances where an entire gatewaybackup will fail when using Sepasoft Modules when going from Linux to Windows or vice versa. In those cases, we had to manually import project components for a successful migration.
Provision your server for most feasible amount of memory and cores. We usually recommend a minimum of 16GB memory, and at least 2-4 cores. Next, verify that your new server can see any other servers on the network—as well as whether they are hosting Ignition, databases, or any other software you need to interact with. You will also need to make sure the new server can see the PLCs you will be connecting to.
We recommend verifying everything BEFORE beginning the migration. This strategy will help you avoid unnecessary headaches along the way.
Databases
If your databases are not hosted on the same server as your Ignition gateway, make sure the new server has connectivity to them.
If your databases are hosted on the same server as your Ignition gateway, you will only need to move them if you are decommissioning the old server. If this is the case—or you are moving databases to another server for any other reason—we would recommend moving the databases ahead of time to minimize impacts to the system.
If your Ignition migration is from a development to a production environment, you will likely need to re-map the connections in the Ignition gateway to the new servers, and migrate any relevant data to the new server.
PLCs
In most instances, the PLC infrastructure will remain the same and won’t cause any issues during an Ignition migration. If you are changing anything with the PLCs at the same time, this will be a more involved process and will require additional information for determining the best migration strategy.
If you are moving from development to production, and were using simulators or devices other than the actual PLCs, then you will need to re-map the OPC Tag paths, PLC devices, etc. which will require more information beyond the scope of this post.
Install Ignition
Before beginning any other migration tasks, you can install Ignition on the new server. Run it in trial mode, and it’s okay if it expires, we won’t be running anything on it yet. This will ultimately save you 10-15 minutes of downtime by installing it ahead of the migration. Verify that you’re choosing the right version, then download, install, and make sure you can login to the gateway.
Licensing
If you are migrating to a new major version of Ignition, make sure to contact Inductive Automation to refresh your license for the new version. For example, going from 7.9 to 8.1, or 8.0 to 8.1 will need a license refresh. You won’t need a license refresh if you are going from 8.1.18 to 8.1.19.
When you are ready to do the cutover, deactivate your existing license. While you aren’t REQUIRED to do this, if you use the same license key on the new server without deactivating it on the old server, you will enter Emergency Activation Mode. If this happens, you will need to contact Inductive Automation to refresh and reapply the license.
At Corso Systems, deactivating the existing license is usually the last step before we decommission the server.
To deactivate the license, go to the Gateway Config Page -> Licensing, then click the trash can icon next to the license key and follow the prompts. You may need to generate an activation token if your gateway doesn’t have internet access—if so, follow the guide on the licensing page.
Note the license key, and proceed with the activation process on the new server. Click the “Activate New License” link at the bottom of the licensing config page on the new server and follow the prompts. If your server doesn’t have internet access, you will need to complete the activation message process outlined on the page.
Backup/Restore the Ignition Gateway, Modules
If you haven’t backed up the old gateway already, go into the Gateway Config page, then Backup/Restore. To perform a backup you select the “Backup” tab and click the “Download Backup” button. Note the “…but not the modules.” note in the screenshot below. We will talk about that shortly*.
To restore the backup, go to the new server’s Config page -> “Backup/Restore”, then click the “Restore” tab. Select the file you backed up from the existing gateway and click “Restore”
One option on this page is to “Restore Disabled”. Selecting this option will basically put the gateway in “off” mode when it is restored. If this is selected, you’ll need to go through all of the projects, database connections, OPC connections, devices, tag providers, etc. and re-enable them to be able to use the gateway. This is not a hassle for small systems with a small number of devices, tag providers, and projects, but can be time consuming if there are more than a dozen items to re-enable.
Typically, we would only restore in “off” mode if we needed to have both servers online at the same time for some reason and we don’t want the new server to overwrite anything until after the cutover.
For large scale deployments, it is easier to just do the decommissioning first, then restore enabled.
The “Disable Temp Project Backup” option prevents a backup of the projects directory during the restore process. If you want to prevent a temporary backup for some reason, check the box. We usually always leave it unchecked.
Next, change the gateway name upon restore by using the “Override Gateway Name” option and entering a new name. This is most useful when going from a development environment to production when you didn’t explicitly set the gateway name on the development environment.
Once you have selected your options, click “Restore” and the gateway will restore and come back online.
*Regarding the note about the modules: you will also need to download and install any third party modules you may be using. This includes things like Sepasoft, Cirrus Link, any Module Marketplace, and custom modules you may be using. Please download and install those as needed per those module’s requirements.
Vision Clients and Perspective Sessions
If you are moving to a new server and using the same IP address as the old server—along with the same port number—your clients should reconnect with no issues. You will need to validate that clients and Perspective sessions come back up as expected. In our example at the beginning of this post, everything came up without any issues once the new server’s IP address was changed.
If you are not using the same IP address, you will need to apply the new server settings on any systems with Vision Clients to update Vision Client Launchers and Vision Client Shortcuts. Also have your users update any links or favorites for Perspective Sessions to the new server. If anyone is using the Perspective Mobile Apps, they will need to redirect their links to the new server.
Data Validation
The final step in the process is data validation. Generally, this is a smooth process. Once everything is online, databases and devices are connected, and clients are launched, everything should work as expected.
If you do find any issues, they’re likely to be related to networking. Maybe PLC might be on a different VLAN, and the new server doesn’t have access. In that case, the IT team will need to be involved to help figure out and resolve the issue.
You may also have Ignition issues if you are also upgrading versions. For example, UDT parameters might not come across properly, and can break UDT tags when upgrading to 8.0.0. If you are not upgrading versions, these types of issues will be exceedingly rare.
Once you have validated that everything is working, use the new gateway just like it was the old one and everything should be humming along nicely.
Ignition Gateway Migrations Don’t Need to Be Painful
Ignition Gateway Migrations are usually a stressful undertaking for the people who use the system or who rely on it to run their facilities. With many other SCADA platforms and business system tools, there can be a lot of headaches and hassles, however Ignition has made this process a very painless one.
You can migrate Ignition with minimal downtime, very few upsets to the operational integrity of the system, and—depending on how you set up your plant network—minimal intrusion into operations.
While migrating Ignition Gateways can seem daunting, it is one of the most common tasks we do on projects at Corso Systems. We stand behind our experiences with Ignition as one of the friendliest platforms to work with in the manufacturing world.
Get Your Project Started Today:
Corso Systems can help. Tell us about your project:
