Automate secure migration of OSIsoft PI Systems from n-premises data center using AWS Application Migration Service

Large industrial enterprises in manufacturing, oil and gas, and electric transmission and distribution collect operational technology (OT) data from millions of sensors. Much of this valuable data remains unused, sitting in OSIsoft PI Historians, with 80% of the world’s largest oil and gas companies and 65% of the industrial companies in the Fortune 500 relying on the PI System in their operations. OSIsoft is a leader in industrial digital transformation with a comprehensive data infrastructure platform for data ingestion from various industrial sensors using a variety of industrial protocols. OSIsoft systems are deployed across the globe, collecting billions of data streams.

Migrating PI Systems has proven to be a challenging effort for customers. It is a time-consuming and manual process that involves manually installing the same version on the target server, moving the files to the target PI System, and changing files as necessary. Quite often, customers hire consultants and systems integrators to migrate PI System(s) that involve extensive planning and associated costs. Thus, customers are looking for a more reliable way to migrate their PI System workloads to the cloud. Now with AWS Application Migration Service, customers can migrate their PI System workloads in parallel and cut over to the new cloud-hosted PI System in a matter of days as opposed to weeks or months.

AWS Application Migration Service is the primary migration service recommended for lift-and-shift migrations to AWS. Customers currently using CloudEndure Migration or AWS Server Migration Service (AWS SMS) are encouraged to switch to AWS Application Migration Service for future migrations. Application Migration Service allows you to quickly realize the benefits of migrating applications to the cloud without changes and with minimal downtime.

Application Migration Service minimizes time-intensive, error-prone manual processes by automatically converting your source servers from physical, virtual, or cloud infrastructure to run natively on AWS. It further simplifies your migration by enabling you to use the same automated process for a wide range of applications.

PI System migration using Application Migration Service

Overview

Figure 1 shows the overall architecture of the migration process from Industrial Plants and Factory to AWS. The architecture shows a complete PI System running on-premises integrated with Active Directory (AD) for authentication and authorization. Customers can then utilize AWS Application Migration Service to migrate the components securely to AWS. An AD Connector facilitates the active directory sync with the on-premises AD for the PI Interfaces to send the data to AWS hosted PI System.

Figure 1: PI System migration from Industrial Plants and Factory to AWS

Here we have the on-premises domain controller and the PI System stack that is composed of the PI Data Archive, PI Asset Framework (PI AF), Microsoft SQL Server, and PI Interfaces that connect to data sources using the many industrial protocols supported by AVEVA. The objective is to keep the PI Interfaces closer to the edge and migrate the PI System to the cloud. The PI Interfaces securely connect to the PI Data Archive in the cloud via AWS Direct Connect link or VPN connection. For the migration of the PI System to the cloud, you can use Application Migration Service to orchestrate and automate the whole process. When you are ready to cut over to the PI System in the AWS Cloud, AWS AD Connector is configured to sync with the on-premises domain controller. Users can then log on to the AWS-hosted PI System using the same domain credentials. This also allows PI Interfaces to automatically resume connection to the PI System running in the AWS Cloud. This process has been used by many AWS customers to migrate their PI Systems.

Application Migration Service replication process

To get started, first ensure your staging area in AWS meets the Application Migration Service network requirements and then create a replication template in the Application Migration Service console. This template defines how data replication will execute for each source server and specifies critical information such as migration staging subnets, replication server instance type, and EBS volume type. Once your template is created, you can begin to add source servers by installing the AWS Replication Agent on each server.

Once the Agent is installed onto a server, it will automatically register the server into your Application Migration Service console and begin a block-by-block replication. Your replicated data is compressed and encrypted in transit and at rest using EBS encryption. Application Migration Service keeps your migrated data synchronized on AWS using continuous block-level data replication. If network connectivity is temporarily lost, it will automatically attempt to reconnect and resynchronize.

Figure 2: Application Migration Service replication process

After data replication is completed for a server, you may then launch it as a new instance of your choice in a “test” mode to validate that your server functions properly in the AWS environment. As a best practice, it is advisable that users closely match the same level of hardware requirements as the on-premises environments to an AWS instance type. You may test one server at a time or simultaneously test multiple servers. Depending on your results, you may either revert testing for those source servers to terminate the running resources and revert their migration lifecycle to Ready for testing (Figure 3), or you may mark the source server(s) as ready for cutover. Once a server is marked as Ready for cutover (Figure 4), we recommend terminating launched testing instances to save cost while waiting to cut over to your migrated servers.

Figure 3: Application Migration Service replication completion

Figure 4: Pre-cutover screenshot

Once a cutover has been triggered, Application Migration Service launches a new cutover instance that reflects the most up-to-date state of the source server. After the cutover (Figure 5), data replication continues as before. Now users would be able to log in to the AWS-hosted instances and confirm that the data from industrial facility-hosted PI Interfaces is now being sent to the AWS-hosted PI data archive, as shown in Figure 6. If you encounter any issues and want to launch new cutover instances, you can revert the cutover in the Application Migration Service console. This will revert your source servers’ migration lifecycle status to Ready for cutover, indicating that these servers have not undergone cutover. During a revert, you will also have the option to delete your cutover instances for cost-saving purposes. If you are complete with your migration and have successfully cut over all of your source servers, you can finalize the cutover in Application Migration Service. Doing so will change your source servers’ migration lifecycle status to Cutover complete (Figure 5), indicating that the cutover is finalized and that the migration has been performed successfully. In addition, this will stop data replication and cause all replicated data to be discarded, with only your running cutover instances remaining. All AWS resources used for data replication will then be terminated.

Figure 5: Cutover process completion

Figure 6: Migrated AWS-hosted PI System with data flowing from Industrial Facility through PI Interfaces

Conclusion

Large enterprises are struggling to maintain aging on-premises data centers and wish to migrate their critical workloads to the cloud. OSIsoft PI System is at the heart of many industrial facilities across many industry verticals and is critical to their operations. Traditionally, these migrations take a long time and thus incur escalating migration costs to customers. AWS Application Migration Service can help customers successfully migrate these environments in a secure and scalable manner.