--- title: "Data center migration and relocation" description: "Data center consolidation, relocation and exit, with discovery, dependency mapping, move groups, physical moves and cloud migration planned as one program." url: https://www.expandware.com/services/data-centers/data-center-migration/ section: "Services" topics: ["Data Centers and Infrastructure", "Dependency mapping", "Chain of custody", "ITIL 4 change enablement", "AWS Application Migration Service"] publisher: "Expandware Private Limited" --- # Data center migration and relocation Data center consolidation, relocation and exit, with discovery, dependency mapping, move groups, physical moves and cloud migration planned as one program. Move the data center without moving the risk. A data center move combines everything that can go wrong in infrastructure into one weekend. We take the risk out by planning it as a program: every application and dependency discovered, move groups designed so dependent systems travel together, physical moves and network cutovers rehearsed, and a rollback defined for each step. Some workloads move to a new facility, some to the cloud and some are retired, each decided on purpose. Where it usually starts: - A data center lease ends on a date that cannot move. - Several sites are being consolidated into one. - The facility can no longer provide the power or resilience the business needs. - Nobody is sure which applications depend on which servers. What is included: - Discovery: Applications, servers, storage, network and dependencies inventoried. - Disposition: Each workload assigned to move, migrate to the cloud, be replaced or be retired. - Move group design: Dependent systems grouped so that they move together. - Physical relocation: Shutdown, packing, transport, racking and power-on with chain of custody. - Network cutover: Addressing, routing and connectivity moved with a tested fallback. - Validation: Application testing with business owners after every move. Where it sits: Migration belongs to the operate and retire layer of the data center architecture: it moves racks, servers and workloads out of one facility and into another, or into the cloud. Decisions to settle early: - New facility or cloud. Some workloads belong in another facility, others in the cloud, some nowhere. The disposition is decided per workload. - Move hardware or rebuild. Moving hardware is quicker; rebuilding at the destination reduces risk and refreshes ageing equipment. Age and support decide. - One move or many. Fewer, larger moves shorten the program but raise the stakes of each. Move groups follow dependencies. How the work runs: Discover, Applications and dependencies. Plan, Move groups, dates and rollback. Move, Physical and logical moves. Validate, Testing with business owners. How it is bought: - A fixed-fee assessment: We discover applications, servers and dependencies and assess what is worth moving. You receive the inventory, a disposition for each workload and a fixed price for the migration program. - A fixed-price build: Move group design, rehearsals, physical moves and network cutovers are priced before the program starts, with rollback defined for each move. - Running it afterwards: Retired hardware passes to decommissioning, and the new estate can be run by your team or under our managed services. Worked example, a lease that ends on a fixed date. Say a media company must leave its data center when the lease runs out, with no option to extend. The estate has grown over many years, its dependencies were never mapped, and some systems may not be worth moving. - Discover: We map applications, servers and network dependencies with discovery tools and interviews, and find services nobody had listed. - Decide: Each workload is assigned to move, go to the cloud, be replaced or be retired, which leaves less to carry. - Plan: Dependent systems are grouped to move together, and each move is rehearsed with its rollback point agreed. - Move: Physical moves run under chain of custody and network cutovers with a tested fallback, and owners test their applications after each one. At the end, the company is out of the old facility on time, some systems have been retired rather than moved, and every application has been signed off by its owner. (An illustration, not a client account.) What you have at the end: - Application and dependency inventory: Every application, the servers and storage it runs on and what it talks to, confirmed with its owner. - A disposition decision for every workload: Whether each workload moves, goes to the cloud, is replaced or is retired, and the reason. - Move group plan and schedule: Dependent systems grouped to travel together, with the dates and windows for each group. - Runbooks with rollback for each move: Shutdown, transport, startup and network steps for each move, and the point at which it is rolled back. - Validation sign-off records: Confirmation from each business owner that their applications work after the move. Standards and platforms worked with: Dependency mapping, Chain of custody, ITIL 4 change enablement, AWS Application Migration Service, Azure Migrate, VMware HCX. Where it goes wrong, and what we design out: - Moving what should be retired. Carrying systems nobody uses adds cost and risk. Every workload is decided before it moves. - Dependencies found on the night. A missed dependency breaks an application after the move. Discovery runs long enough to catch rare connections. - No way back. A move without a rollback point is a gamble. Each one has a defined point of return. What it changes: - No surprises on move day. Dependencies are known, so nothing breaks because its partner moved without it. - Every step reversible. Each move has a rollback plan and a decision point. - A smaller estate afterwards. Workloads that are no longer needed are retired rather than moved. How you will know it is working: - The facility is exited by the required date. - Every application is signed off by its owner after the move. - No rollback was needed, though each was ready. - Fewer systems arrive than left, because some were retired. Who you work with: - Migration lead. Owns the plan, the move groups and the schedule. - Infrastructure engineers. Run discovery, network cutovers and physical moves. - Application coordinator. Works with application owners on testing and sign-off. What we need from you: - Access to the estate for discovery tools. - Application owners who can test after each move. - Lease dates and contractual obligations. - Maintenance windows agreed with the business. Common questions: Q: How long does a data center migration take? A: Months rather than weeks for most estates, with discovery and planning taking as long as the moves themselves. A fixed lease end date is planned backwards from, with contingency built in. Q: Should we move to another facility or to the cloud? A: Usually some of each. Each workload is assessed on its own: steady, latency-sensitive or regulated systems often move to colocation, while others suit cloud migration or retirement. Q: How is hardware protected in transit? A: With specialist transport, packing to the manufacturer's guidance, chain of custody records and backups verified before anything leaves the building. Q: Can applications stay online during the move? A: Many can, through replication and staged cutovers; others need a short outage window. The plan states which is which, agreed with the business owners in advance. Q: What is a move group? A: A set of systems that depend on each other closely enough to move together, such as an application, its database and the services it calls. Designing move groups from real dependencies is what stops a move breaking something that was left behind. Q: How do you find dependencies nobody documented? A: With network flow analysis and discovery tools that record which systems actually talk to each other over time, combined with interviews with application owners. Infrequent connections, such as month end jobs, are the ones most often missed, so discovery runs long enough to catch them. Q: Is it cheaper to move our hardware or buy new? A: It depends on the hardware's age, its remaining support, the cost and risk of moving it and the workloads it runs. Hardware near the end of its life is often better replaced at the new site, with workloads migrated over the network, and the business case compares both. Q: Who confirms that applications work after a move? A: The business owner of each application, using test scripts agreed before the move. Technical checks confirm that servers and services are up; the owner confirms the application does what the business needs. A move is complete only when that sign-off is recorded. Often paired with: Cloud strategy and migration, Colocation, remote and smart hands, Decommissioning and IT asset disposition. --- Canonical page: https://www.expandware.com/services/data-centers/data-center-migration/ Site index for machines: https://www.expandware.com/llms.txt Full site text: https://www.expandware.com/llms-full.txt Expandware Private Limited. Inquiries: solutions@expandware.com, +92 (333) 32 11011.