Migrating infrastructure between data centers is one of the more demanding tasks in IT and infrastructure outsourcing — it calls for a precise plan, deep knowledge of the client's environment, and close coordination with connectivity providers. Below, we describe step by step how we moved our client's entire production network and server environment while keeping their services running.
The brief
A long-standing client, for whom we provide a range of comprehensive services, asked us to migrate their entire production network and server infrastructure from a geo-redundant site to their main location. On a day-to-day basis, we provide them with, among others:
– comprehensive IT support,
– administration of server and network infrastructure, both on-site and in the cloud,
– configuration and maintenance of firewalls and VPN concentrators.
Knowing the current state of their network infrastructure and the direction of its future growth, we moved swiftly to deliver the project.
Assessment
We began by taking inventory of the hardware and how it was laid out across the racks. We identified 24 production server devices (virtualization hosts and disk arrays) and 14 network devices — switches, BGP routers, a DMZ router, firewalls, and VPN concentrators.
Next, we verified which devices and links had to be included in the migration, and made an initial check of how much space was available for additional hardware in the target data center (DC1). The following step was to plan precisely where each device should be placed in the racks.
Preparation
At first, the server room in DC1 did not have much free space for additional hardware, but once we cleared several racks of old equipment, space was no longer an issue. We created a project document covering all the key aspects:
– the order in which services would be migrated,
– the layout of devices in the racks,
– the wiring of network and power outlets — aimed at the greatest possible physical separation of services within the same room and across two independent power lines.
We presented the plan to the client together with timelines, potential risks, and every step involved — including post-work testing carried out jointly with the telecommunications providers. It was their responsibility to ensure that the access links to the services (MPLS, BGP, Internet, etc.) were transferred. The entire migration was planned for 4 days and split into 4 stages.
Configuration
The first stage was preparing the configuration in the server room for the new devices, based on the project document we had drawn up. Because this part of the work did not touch the live, fully production-critical infrastructure, we carried it out during normal working hours, with no impact on the running services.
Migration
The second stage was migrating the critical servers between virtualization hosts — from DC2 to DC1.
The third stage was the physical relocation of the server hardware, carried out with the help of a professional transport company. Given the nature of the services running on it, this took place on a Sunday. We moved the hardware from the racks in DC2 to the prepared racks in DC1. This stage went without any major issues, and we completed every task within the assumed time windows.
The final, fourth stage — relocating the network devices — was largely a formality. Our network engineers arrived on site in the morning, alongside staff from the telecommunications operator. We dismantled the network hardware in DC2, transported it to DC1, and installed it there.
After physically connecting the devices and verifying the ports, the operation of the services, and the failover mechanisms, we considered the entire project a success. None of the critical services suffered a single second of unplanned downtime during the migration. The only interruption we observed occurred while testing one of the failover mechanisms — it lasted 21 pings and stayed within the accepted, planned test scenarios. From the perspective of users and 24/7 services, nothing was noticeable beyond a planned interruption of a dozen or so seconds.