BMS virtual machines migration
Project role: Project Manager
Project intro: The business unit (BU) site wished to be connected to the centrally managed Product Supply Network – a central network for all manufacturing IT accross the company. Moreover, the BU wanted to outsource all its data center operations to another global department called Manufacturing IT. The BU already had its own data centers where only two systems were hosted. These two were Building Management Systems (BMS) – one GxP and the other non-GxP – used by the BU for managing its facilities at four pilot plats. Each system consisted of three Virtual Machines (VM) hosted at the BU’s data center. To facilitate the connection to the central network, the VMs had to be migrated to Manufacturing IT who would then be able to take over the BU’s data center network.
Business case: The benefits of connection the BU to central network and for outsourcing their data center operations were:
- Allowing future IT deployments at the BU to be integrated into the Product Supply network and thus benefiting from many centrally managed IT services
- Releasing the BU’s IT resources from operating data centers and allowing them to work on future IT deployments
- Standardizing the BU’s IT operations and ensuring that global procedures can be followed.
Technical setup – the legacy and the new:
The BMS applications were using Desigo Insight, a Siemens solution, in combination with another alarm routing product for sending all BMS alarms to a central surveillance system. The Desigo Insight application server was interfaced with a number of controllers spread throughout the pilot plant for controlling the various HVAC units and other utilities. All these were recently qualified systems and there was no wish to make any changes to them during the migration.
Therefore, in the new setup, the two systems simply had to be migrated to a new data center with minimum downtime and no changes visible to the end users. Due to licensing protocols of the applications, it was unfortunately not possible to do a virtual-to-virtual migration or restore a VM from a snapshot. Therefore, the VMs had to be reconstructed in the new data center and the applications recovered from application backups.
- Deploy VMs on the new data center and get them ready for application restore. (eg. ensuring firewall openings between the application and the central surveillance system, deploying new agents for antivirus, backup, monitoring, etc.)
- Backup applications and data on the old setup (on the migration day),
- Take snapshots of the old VM (on the migration day)
Migration day phases:
- Initiate the network migration – this was the part which ensured that the BU’s network became an extended part of the Product Supply Network. At this point, the communication to the old VMs was lost and established for the new VMs in the new data center
- Restoring the Desigo Insight project on the new VMs from the application specific backup
- Ensure that there is connectivity between the recovered application and the controllers at the pilot plants
- Test the data integrity across all interfaces
- Release for use
The entire migration was a 1-day activity including testing and release.
Project Management: Prior to commencing the project, it was essential to demonstrate that the business case was worth it and that the benefits could be realized. This required the creation of a Service Level of Agreement between the BU and Manufacturing IT where all the IT operations, roles & responsibilities, pricing and conditions were outlined. As soon as both parties were satisfied with the SLA there was a Go for initiating the migration planning. This demonstrated the strategic fit of the new setup and laid the foundation for the new IT governance at the BU, making many central IT services available for future deployments.
This was categorized as fast track project. The BU’s connection to the Production Supply Network was a dependency for many other manufacturing IT deployments on site. Therefore, other projects were dependent on the migration.
The traditional model of conceptual design -> detailed design -> execution -> handover was not used since all these phases could not be accommodated for this fast operation. Furthermore, the budget was also small and therefore the project did not meet the criteria for following the traditional project execution model.
Project governance was ensured via the project sponsor which was the head of the technical department for that BU. This allowed for quick go/no-go decisions and for fast access to resources via a committed Team Lead.
The plan was carefully considered with the local team, the Manufacturing IT department and Siemens – the supplier of the BMS solution. The most effort was used in validating all the steps of the migration plan to ensure that all the prerequisites are met on the closing window day.
As the migration implied a closing window, this had to be aligned with the heads of the four pilot plants to find a timing which would not affect production or other local projects.