Francis Miers is a Director at Automation Consultants.
A data center migration can be a tough process for even a seasoned data center manager to navigate. Relocating software and hardware is not simple and requires an analysis of risk, the data center environment, compatibility, the network in general, and possible latency issues.
Good data center migration planning is based on the levels of risk you can tolerate. The principal risks being prolonged downtime and loss of data. Levels of tolerated risk will normally depend on the business importance of the apps being hosted. The extreme end would be an air traffic control operation that must be operational 24 hours a day, whereas the lower end of the risk scale includes internal company systems that can tolerate outages.
Thinking about it in terms of a mobile telecom operator you would have:
- Mission critical systems – e.g. the network itself
- Business critical systems – e.g. telecom operator’s website
- Important systems – e.g. HR, meeting room
- Brochureware systems – e.g. intranet
The risk will also affect the budget required for the migration; you may need a test environment, dedicated data center staff and additional software licenses. You may need to performance test the new environment (in an ideal world you’ll run a complete set of functional and performance tests) to ensure your applications behave correctly.
Disaster recovery is also a key consideration for mission critical systems. Such systems normally have a disaster recovery capability with active servers on another site (active/active). In a migration of a mission critical systems, any disaster recovery facility would have to be taken into consideration.
As well as establishing business and technical risks, you need to understand what the existing environment consists of and how it interacts with other systems. Over time, knowledge of the full extent of the components of an application can be lost. Some reliable applications may have worked without a significant pause for decades and the full knowledge of their components may have been lost or will be difficult to recover. Perhaps the person who designed and built them may have left the organization long ago. It is often necessary to spend time rediscovering all the components of legacy applications, including the hardware they’re installed on, or parts of the network they use. If all those components aren’t there post- migration, they might not work when you switch them on.
Network tracing tools can prove invaluable for this discovery phase. Many systems will be in contact on a daily basis, but some will communicate rarely (once a month, for example). It is important to observe your network over a sustained period of time to ensure that you don’t miss these processes in action.
Legacy apps aren’t always a good fit for a new environment. MicroVAX minicomputers, for example, ceased to be manufactured in 2005 – despite this, they still figure prominently in many facilities.
If your apps were made for MicroVAX systems or other older hardware, your migration has the additional dilemma of how to move them to modern equipment. There are two ways of dealing with this. The first is physical movement of legacy hardware: unplugging and re-racking, quite literally a "lift and shift".
The alternative is moving them to modern hardware. In some cases, emulators might ease the process considerably; in others, the apps will require a complete rewrite. As technology moves forward, systems like MicroVAX will become harder and harder to support. Adjusting applications to modern hardware may incur short-term cost but eliminates the risks of using long-outdated hardware.
Again, solid planning rules the day. Part of the planning in migrating any new app is to think about how it will fit in the new network. Considerations include: firewall settings, the domains and trusts, and latency. For systems of medium to high business importance and/or technical risk, a trial migration in a test environment is advisable, so the system can be tested in its new location before going live.
Depending on the nature of an application, latency can be important or negligible; accessing a single file may take milliseconds, but if the application needs hundreds of files in sequence, then the process could take minutes which makes it unworkable. If an application is migrated thousands of miles away in another country, latency could become an issue and additional server and virtualization resources may be required.
In any data center migration the main dangers are prolonged unplanned downtime and loss of data. The budget dedicated to the migration will reflect the damage that will be caused to the business if either of these are incurred. Good advanced planning and thorough testing (commensurating with the business importance of the application) will help the migration go smoothly.