In assessing how hard or easy a migration programme will be, experience shows that size isn’t everything. The number of physical/virtual servers is not as important as the relative complexity of the infrastructure in terms of how easy or hard it is to standardise on a set of agreed images and builds. Why is this important? Because an estate of 1,000 servers with few images that need to be migrated is less complex and risky than a heavily mixed estate of 200 servers with a large number of widely differing builds and few common user group profiles.
At Trilogy, our approach is a broad assessment and categorisation phase applied to all of the server estate (physical and virtual) followed by a repeating programme of migrations for groups of servers. This iterative tactic promotes consistency, mitigates risk, provides some flexibility if unexpected issues are encountered and allow the sequence to be reconfigured “in flight” to match changing business priorities. Essentially groups of servers are sequenced together based on agreed application, service and database migration programmes. The objective is that the target upgraded server platforms are ready at the right time for the sequential planned migration of the server applications.
Typically a set of standardised test environments, based on common server configuration builds are put in place. These are used prior to live migration to allow testing of the migrated applications. Once the applications have been tested against the appropriate common standard build servers then the migration of the Production / Test/Dev/DR servers can take place in sequence with the live application deployment. The actual migration approach used (for example “swing methodology”) is ideally the same for most groups of servers allowing common quality and delivery experiences for users and also to allow the sequence to be amended during the life of the project should business or other operational circumstances change. This modular approach lowers the risk of the project and allows great flexibility without impacting on the overall programme.
The main phases for the infrastructure project streams are
- Assess the full server estate at a holistic level
- Categorise physical and virtual servers
- Perform a virtualisation optimisation assessment
- Determine the target physical environment based on the above
- Determine whether any existing physical hardware can be re-purposed or should be retired
When performing a migration, Trilogy recommends the use of a standard operating environment (SOE) wherever practical. This provides a defined, common, standard configuration and “build” against which to migrate. The SOE should incorporate a standard agreed implementation of the core operating system and middleware components needed, usually including the base operating system, custom configurations, software updates, and service packs as well as agreed hardening.
The SOE configuration is tuned to combine technical and business requirements. This approach reduces deployment time, simplifies maintenance post migration, increases stability, and reduces support and management overheads both during and after the migration project.
And where information regarding the infrastructure may not be 100% up-to-date or accurate, then consider using tools to assist in the process, an area where Trilogy has developed processes and methodologies.
In all of this above, do be aware that any migration programme at an O/S level should be considered in the context of the application and database work-streams that will be and not simply on workload, geography or other aspects.