Challenge: Data centre relocation

When all IT systems must be relocated to another data centre, this often is a particular challenge for the affected IT departments due to today‘s complex IT structures. The effort in relocating a complete data centre while maintaining the agreed upon service levels is enormous. Most often, no or only little experience with such a relocation exists. The amount of work often exceeds the available personnel resources. Typically, to conquer this task, external know-how is purchased or the whole data centre relocation may even be handed over to a competent service provider.

In the beginning is the documentation

Nevertheless, a lot of work still remains to be done in-house. The foundation of a relocation initially always is the existing documentation. The quality of the documentation is the linchpin of the whole relocation, and therefore the capturing of the status quo, meaning the thorough capturing of all applications, systems, infrastructures, their interfaces, and – if possible – also their dependencies, is of the utmost importance. It constitutes the foundation for the relocation planning. If systems are missed or select dependencies ignored, this will typically backfire with service failures or service restrictions while the relocation is being carried out.

Optimise everything prior to the relocation?

Typically, an effort is made to optimise in the planning of the new data centre everything that could not be optimised in the current situation for various reasons. But often the desire to optimise leads to a situation where even more dependencies have to be taken into consideration in the relocation planning that did already exist anyway. And not all that seldom the result is that a lot of things that one would like to get resolved in connection with the relocation do not work afterwards.

Computerwoche, the German edition of Computerworld, called it a „deadly sin“ once, 2 years ago, to combine a relocation with other projects. Experience shows that this is fundamentally correct. However, the further developments, in particular at large data centres, often cannot be delayed as long as a relocation takes. Therefore, the „freezing“ of a data centre is not possible and as a result it is important to establish a process that continuously captures the constant changes and integrates them into the relocation planning. Only this way it is ensured that the foundation of the relocation planning is correct at any point in time.

Concurrent changes make a smooth relocation more difficult

Nothing is more bothersome than when at the relocation date, for example, hours need to be spent on searching for a system that has been uninstalled several days prior. Fundamentally, it should be avoided to perform a data centre relocation in parallel to other large planned changes in the IT landscape. In addition to the high frequency of changes and the re-planning efforts associated therewith, additional requirements are also posed to the relocation planning and therewith may cause scheduling restrictions and/or dependencies. Thereby, the coordination and control effort increases significantly.

Detailed relocation plans for sub-systems reduce the complexity

Once the „what“ and „where-to“ have been clarified, the next question is „how“. In addition to the technical options, aspects such as time needed, costs, and security also must be taken into consideration. Depending on the framework conditions and the functional dependencies, the point in time and the technical approach of the relocation are specified for each individual system. From the technically simple removal/installation and transport of a system to a laborious parallel setup of the whole IT environment, everything is a possibility here. In principle, it applies that the higher the requirements regarding availability and security are, the more complex and expensive a relocation will be. Here, maintenance windows aligned with the relocation can help to significantly reduce the costs. For this reason, it should not only be taken into consideration what is technically feasible and has been contractually agreed upon, but it must also be checked what, in addition, may be possible to agree upon with the customers, where applicable.

Test phase and troubleshooting must be planned for, too

Typically, the time slot is large enough for the planned measures but most of the time no or no large time buffer remains for troubleshooting. Therefore, all preparations must be subject to a high degree of quality assurance.  For this, the testability must be taken into consideration already in the planning and conceptualisation phase in the definition of the measures/alternation, and comprehensive test plans must be prepared. Measures that offer no or only limited options for test are to be avoided. However, where nothing else is technically feasible or only with a lot of effort, the execution must be assessed by means of a risk assessment in individual cases. 

If then, after a whole lot of work for the preparation and planning, the day of the relocation has come, it will become apparent how well everything was prepared. Controlled by a central coordination unit and based on the prepared flow plans for this relocation day, all measures are processed by the teams and reported back. Upon completion of the relocation activities, the operability of the new data centre and of the relocated IT is confirmed through final tests. Therewith, the new data now has officially gone operational.