How to Relocate a Data Center: A Guide to Moving from a Server Room to Colocation

What Is Data Center Relocation?

Data center relocation is a project to transfer an organization's server, storage, network, security, and application infrastructure from its current location to a new operating environment in a controlled manner. It may involve moving physical equipment, but transferring data to new hardware or migrating virtual workloads through replication can also form part of the same project.

In a colocation model, an organization hosts its own equipment within the power, cooling, physical security, and connectivity infrastructure of a professional facility. Do not assume that operating system, application, database, and backup management automatically transfer to the facility operator. The scope of managed services must be defined separately.

This distinction prevents the same word from being used to mean different things in project meetings. A logistics company's confirmation that “delivery is complete” and a business team's approval that “the service is available” are not the same milestone.

Why Do Organizations Move from a Server Room to Colocation?

Do not base the relocation decision on rack space alone. Power and cooling capacity, physical security, maintenance responsibilities, connectivity options, growth requirements, and the future of the office location must be assessed together. Dependence on a single UPS or a single connectivity route, a building refurbishment, a consolidation decision, or the operational workload may trigger this assessment.

For GPU and high-density workloads, an available cabinet is not a sufficient acceptance criterion. The continuous power capacity, cooling method, cabinet load capacity, and equipment compatibility at the destination must be clarified in writing. Similarly, having two carrier options does not, by itself, demonstrate that the connections are physically independent.

Document the current problem and the intended improvement separately in the decision record. Instead of “not enough space,” specify the growth capacity required; instead of “the network is slow,” identify the affected application and the performance to be measured. Without a baseline, it becomes harder to determine whether the relocation has delivered the expected benefits.

Before choosing a hosting model, review our On-Premise, Colocation, and Private Cloud comparison. This guide focuses on implementation and cutover decisions after the model has been selected.

What Are the Different Data Center Relocation Models?

Choose the relocation method by starting with the requirements of the service, not the device. Assess downtime tolerance, data volume, application support, hardware condition, licensing, and rollback options together. A single project can use several different methods.

Physical relocation should not be treated as synonymous with the cloud term rehost/lift-and-shift. Rehosting means moving an application to another operating environment without major changes; it does not necessarily involve transporting a physical server. Moving to the cloud does not always require rearchitecting the application, either.

Do not retain an aging device simply because its transportation cost appears low, and do not automatically treat new hardware as risk-free. Account for the installation, testing, and support requirements of each option. Replication may be appropriate for a critical application, but the decision must be validated against the methods the application supports.

How Should You Define the Downtime Budget, RPO, and RTO?

Agree with business teams on what will count as success before setting the relocation date. In business continuity planning, priorities and recovery requirements come before technical execution steps. NIST's contingency planning framework likewise considers system functions and priorities together.^[1]

A planned maintenance window, RTO, and RPO are not the same concept. RTO concerns the target time for restoring a service after a disruption; RPO concerns the point in time to which data must be recoverable. Relate the relocation project's acceptance criteria to these objectives, but do not automatically label the maintenance period reserved in the calendar as the RTO.^[2][3]

Do not include transportation alone in the downtime budget. Stopping transaction acceptance, final data synchronization, controlled shutdown, deinstallation, site security procedures, installation, dependency startup, application testing, and business approval also belong in that budget.

Planning calculation: Latest rollback decision time = end of the maintenance window − validated rollback duration − safety margin. This calculation assumes the rollback method is still feasible at that stage. Once new data has been created at the destination, additional reconciliation and synchronization time is required.

Use our RPO and RTO guide when defining these objectives. Aiming to transfer every last confirmed transaction during a planned cutover is not the same as guaranteeing zero data loss in every failure scenario.

How Do You Plan a Data Center Relocation in Seven Steps?

The seven steps below provide an implementation framework that separates preparation from relocation-day activities. Each step should have a deliverable, an owner, and an acceptance criterion. A check that has been “planned” is not the same as one that has been completed and evidenced.

1. Assess the Target Location and Service Scope

Evaluate the destination against your own load profile, not just its marketing documentation. Usable power per cabinet, cooling, equipment dimensions, access procedures, connectivity delivery, and expansion options must all be verified together.

The carrier-neutral data center model is important when assessing connectivity options. However, the specific carrier, port, route, and delivery conditions must still be agreed separately. When reviewing Tier classifications, also check the scope of the documentation and its relationship to the facility; do not interpret a classification as an unconditional promise of uninterrupted application availability.

2. Build the Physical Inventory and Map Application Dependencies

The physical inventory should include the device model, serial number, source and target cabinet positions, ports, power connections, support status, and responsible person. Associate photographs, labels, and cabling records with the same device identifier. Keep administrative access credentials in a secure vault with authorized access, not in openly accessible inventory files.

Add service owners, users, databases, license servers, identity/DNS/time services, API connections, file shares, scheduled jobs, and external parties to the application inventory. Traffic observed during the day may not be enough; verify month-end reports, overnight jobs, and flows used only during recovery with application owners.

A dependency map is not just a diagram. Record ownership, required access, and the environment to be used during cutover for every connection. When dependent systems are assigned to different waves, test latency and access conditions between the two locations.

3. Define Migration Methods, Waves, and Rehearsals

Start with a pilot that has a low business impact but represents real network and operating conditions. The purpose is not merely to test file copying, but to exercise access, monitoring, the testing workflow, and team coordination. Do not extend the same method to critical services until the success criteria have been met.

There is no universal rule that “the most critical systems must always move last.” Shared identity, network, or storage services may need to be prepared in advance for other waves. Service dependencies, the business calendar, the ability to operate environments in parallel, and rollback capability should determine the sequence.

Define the scope, method, window, business representative, test list, and stop conditions for each wave. When an application version, network architecture, and hardware platform must change at the same time as the relocation, test those changes separately. Otherwise, it becomes harder to isolate the cause of a problem.

4. Prepare the Target Environment Before Equipment Arrives

Racks, power distribution units, cabling, network equipment, firewalls, management access, and backup destinations should be ready in advance. Placing an order for a circuit is not enough; access to the target services must be tested over the delivered connection.

Do not check A and B feeds by their labels alone. Review the actual load distribution and the capacity of the remaining path after the loss of one feed with the facility's authorized technical team. Decide separately how single-power-input devices will be supplied. Electrical connections and tests must be performed by authorized personnel under the relevant facility procedures.

Also plan independent management access for use when the production network encounters a problem. Recovery accounts, multifactor authentication, access logs, and escalation arrangements must not depend on a single server being relocated. Exercise these during the pre-relocation rehearsal.

5. Design Network and Traffic Cutover as a Separate Workstream

Create a separate cutover matrix for source and target addresses, routing, DNS records, security rules, VPNs, and external-party approvals. Every change should have an implementer, a verifier, and a reversal step. The network plan is covered in detail in the IP, BGP, and DNS cutover section.

Combining a facility relocation with a nonessential DNS provider change on the same day expands the scope. Clearly record the changes that will be made together, and consider scheduling work that can be performed independently in separate windows.

6. Manage Relocation Day with an Approved Runbook

A runbook is more than a task list. It should include starting prerequisites, expected duration, the responsible person, validation evidence, and stop criteria. Use one version of the plan and a decision log accessible to all teams; prevent different people from carrying out the same task under conflicting instructions.

The general dependency principle is to stop consuming applications in a controlled manner, then shut down the underlying services they require once the necessary work is complete. During startup, prepare the underlying dependencies first, followed by the applications that use them. Microsoft's three-tier application example similarly starts the database, middle tier, and web tier in that order. The actual sequence must be adapted to product and architecture requirements.^[4]

For example, do not treat the virtualization platform as ready before networking and storage are available, or the ERP service as available before the database and identity services have been verified. A virtual machine being “powered on” does not mean the dependency is ready for the application. For clusters and integrated systems, follow the vendor's approved shutdown and startup procedure.

During physical relocation, record serial numbers, equipment and port labels, the receiving person, and packaging checks. Use equipment-specific manufacturer instructions for packing, transportation conditions, and recommissioning. A robust transport plan considers the secure route, facility access times, suitable handling equipment, and insurance coverage together.

7. Validate, Stabilize, and Decommission the Source Environment in a Controlled Manner

Manage technical startup, service acceptance, and project closure as separate decisions. The application owner and business team should test the previously agreed transactions. Do not consider operational handover complete until monitoring, backup, and recovery connections have been verified.

Set the stabilization period around your business cycles rather than an arbitrary number of days. When an overnight job, periodic report, or external integration runs only at particular times, plan additional validation for it. Review temporary access permissions, alarms silenced during maintenance, and temporary network rules.

Decommissioning the source environment should depend on business acceptance, the end of the rollback requirement, backup and recovery validation, and retention obligations. In a physical relocation where the equipment is no longer at the original site, simply keeping the old room available does not provide a working standby environment.

How Do You Plan the Network Cutover? IP, BGP, DNS, and Connectivity

A physically operational server is not an available service without the correct network access. Treat network cutover not as a few DNS changes on relocation night, but as a separate project component covering internal access, external access, outbound addresses, and dependencies on other parties.

Will IP Addresses Stay the Same or Change?

Assess private network addresses and public internet addresses separately. Retaining internal IP addresses does not guarantee that the existing subnet will work in the same way at the new location. Review gateways, VLAN/VRF structures, routing, and address conflicts between the two environments. When a network is extended across both locations to preserve IP addresses, also assess the impact on the failure domain and operations.

Do not assume that provider-assigned public IP addresses can be used at another location. Verify the address usage conditions, the existing provider's support, and the routing design of the new environment together. An IP change can affect not only inbound traffic, but also the identity of traffic leaving the organization.

What Difference Do Portable IP Resources, an ASN, and BGP Make?

Portable address resources and appropriate routing arrangements can help preserve public IP addresses when changing providers or locations. However, possessing an IP block and an ASN is not sufficient on its own. Agree in advance on the prefixes accepted by the new carrier, announcement authorization, route filters, required registrations, and the cutover sequence. Not every organization needs to operate BGP using its own ASN; the architecture should be selected with the provider.^[5]

For an address block using RPKI, a ROA defines which autonomous system is authorized to originate which prefixes. When the originating ASN or prefix length changes, check that the authorization matches the new configuration. Do not leave this check until the cutover itself.^[6]

When announcements will be made simultaneously from both locations, test where traffic terminates, how the return path is formed, and how stateful security devices behave. Use access tests from different external networks and real transaction results as acceptance evidence, rather than a record stating only that “BGP is up.”

How Should DNS and TTL Be Managed?

TTL affects how long DNS responses can be used from a cache. Lowering the TTL immediately before cutover does not retroactively change responses already cached with the previous, longer TTL. Plan the reduction in advance and allow enough time for the previous TTL's effect to expire. AWS's DNS migration guide likewise treats lowering the TTL and waiting for the previous TTL to expire as separate steps.^[7]

For example, when the previous TTL is 86,400 seconds, reducing it to 300 seconds five minutes before cutover does not mean every client will switch to the new destination within five minutes. These numbers are illustrative examples of caching behavior; appropriate values depend on the DNS service and application requirements.

TTL is not a precise global cutover timer, either. When authoritative DNS servers cannot be reached, some resolvers may serve expired responses under certain conditions to improve resilience. RFC 8767 describes this behavior.^[8] Monitor the old and new destinations, access logs, and client behavior, and define a separate transition approach for long-lived application connections.

When the DNS provider or domain delegation will also change, manage NS records, delegation, and DNSSEC under a separate change plan. This is not the same as changing an application's A/AAAA record. After stabilization, reassess the TTL according to the normal operating policy.

How Should Parallel Connectivity and Carrier Diversity Be Used?

Temporarily connecting the old and new locations can support a wave-based migration. Assess the bandwidth of this connection not only for the initial data copy, but also for daily changes and temporary application traffic. If the transfer backlog keeps growing, final synchronization may not fit within the planned downtime window.

For two circuits, investigate building entry points, routes, shared infrastructure, and termination points rather than carrier names alone. Track order placement, physical delivery, cross-connect completion, and service acceptance dates separately. Confirm actual lead times with the provider; do not assume a fixed number of weeks for every project.

Internet Exchange and peering and Direct Cloud Access address different connectivity needs. Do not treat access to an exchange point as automatic, ready-to-use private connectivity to every cloud service; verify the scope of the specific service separately.

How Do You Protect Data and Business Continuity During Relocation?

Although relocation is planned work, it does not eliminate the possibility of data loss, equipment failure, or an unsuccessful cutover. Build the protection plan around evidence of restore capability, an alternative operating environment, and application consistency, not simply a record that “a backup was taken.”

Distinguish Backups, Replication, and Final Synchronization

Record which services, configurations, and point in time the pre-relocation backup covers. Restoring one file does not demonstrate that the entire ERP service can be recovered in working order. Plan restore and application tests with an appropriate scope for critical services.

Do not expose production equipment and the only recovery copy to the same transportation risk. Verify that backups, decryption keys, and recovery access will be available when needed. Do not assume replication provides the same protection as backup; incorrect changes may also be propagated to the destination. For the fundamental distinctions, see our guide to backup types and strategies.

A change freeze and stopping data writes are different actions. Restricting configuration changes does not stop users or integrations from generating data. For final synchronization, writes, queues, scheduled jobs, and integrations must be brought under control using a method supported by the application.

Prevent the source and target from accepting production data simultaneously in an uncontrolled manner. Keep separate cutover records for “last confirmed transaction,” “synchronization complete,” “source writes blocked,” and “target opened for production.” This makes it clear which data must be preserved if a problem occurs.

Why Do Physical Relocation and Replication Require Different Rollback Plans?

Simply pointing DNS back to the old environment is not a safe rollback plan when orders have already been processed in the new environment. Document in advance how new records will be transferred, how transactions completed in external systems will be reconciled, and who has decision-making authority. Assess rollback and remediation at the target within the same decision record.

When rollback after a physical move requires transporting equipment back, transportation, facility access, rack installation, and startup must all be included in the duration. If the total does not fit within the window, “we will go back to the old site” must be replaced by tested alternative capacity. DRaaS and recovery architecture can complement this assessment, but the actual readiness of capacity and access must be verified.

KVKK, Physical Security, and Decommissioning the Source Environment

Responsibility for protecting personal data does not automatically disappear when equipment moves to another facility. Türkiye's Personal Data Protection Authority (KVKK) emphasizes technical and administrative measures appropriate to the risks, together with the necessary audits.^[10] Review transportation and access records, encryption, key management, service provider roles, and contractual scope with legal and information security teams. This guide is not a substitute for legal advice.

Vacating the old environment should not mean immediately deleting all data. First assess retention requirements, ongoing investigations, and rollback needs. The conditions for erasing, destroying, or anonymizing personal data are subject to a separate legal framework.^[11]

For media being retired, choose a sanitization or destruction method appropriate to the sensitivity of the data and the type of medium. NIST SP 800-88 Rev. 2 provides a framework for establishing a media sanitization program on that basis.^[9] Retain the device or media identifier, method applied, verification result, and authorized approval in the project records. Also remember to close or retire obsolete circuits, access accounts, VPNs, monitoring entries, and licensing associations.

Example Scenario: Moving an ERP Service from a Server Room to Colocation

The following scenario was created for a fictional ERP service whose target infrastructure has already been prepared and whose replication process has been tested. It is not a logistics plan for physically moving existing equipment on the same night. The timings are neither industry averages nor Ixpanse commitments; they illustrate how decision points can be structured.

In this example, the maintenance window is 22:00–01:00, the validated rollback duration before any new production data is created is 30 minutes, and the safety margin is 15 minutes. The latest decision time for that rollback method is therefore 00:15. However, if the target starts accepting new transactions earlier, the original rollback assumption becomes invalid at that point, and the failback plan applies.

If the service is accepted as available at 23:40, the measured downtime in this example is 100 minutes. Starting the virtual machines earlier is not enough to consider the outage over at that point. If testing creates real transactions in external systems, treat them as production data too; do not exclude them from the rollback assessment on the grounds that “we have not opened the service to users yet.”

The acceptance list should include user sign-in, a sample order, an inventory or financial transaction, external integration, latency and error comparisons, monitoring, and backups. If a full backup or a periodic job takes longer than the maintenance window, record service availability and completion of that check as separate milestones. Do not mark an incomplete check as finished; make project closure dependent on actual verification.

Who Is Responsible for What in a Relocation Project?

A colocation agreement does not automatically cover transportation, application migration, and round-the-clock systems management. Before work begins, replace the example roles below with named people and actual service scopes. Every task should have a defined acceptance authority as well as an implementer.

When assessing on-site services such as remote hands, distinguish physical intervention from configuration changes and application management. Clarify operating hours, approval requirements, the scope of intervention, and additional charges in advance.

How Do You Calculate Data Center Relocation Costs?

Relocation cost is not simply the sum of transportation charges and the monthly cabinet fee. The project budget should separate one-time migration expenses, temporary dual-environment costs, and the costs of the new operating model. Use the same service scope and evaluation period when comparing proposals.

Do not compare options by looking only at the new invoice. Separate costs that will genuinely disappear from the existing server room from staffing and licensing expenses that will continue. Do not assume colocation is automatically cheaper for every organization; include growth, resilience, and operational responsibility in the decision.

To assess downtime risk, work with the business team on the affected process and transaction volume instead of using one generic “loss per hour” figure. If the relocation also includes a hardware refresh, show separately which portion of that investment would have been necessary even without the move.

Which Common Data Center Relocation Mistakes Should You Avoid?

The following table is a risk review aid, not a statistical ranking of how frequently these mistakes occur. Add the evidence and responsible person in your organization to each row.

Pre-Relocation Checklist

The items below are not merely boxes to tick. For each one, record the responsible person, the location of the evidence, and the completion date. If a critical item remains open, use the defined risk-acceptance process to decide whether to proceed.

Frequently Asked Questions About Data Center Relocation

How long does a data center relocation take?

There is no single standard duration. Measure the total project timeline and service downtime separately. Inventory work, hardware and circuit delivery, application testing, external-party approvals, and the business calendar determine the schedule. An overnight cutover plan does not mean the entire project can be prepared and completed in one night.

Is downtime unavoidable during relocation?

The equipment being physically moved must be shut down, but whether the service is interrupted depends on alternative operating capacity and the application architecture. Physical relocation causes an outage for a service running on a single instance. Replication or parallel operation can reduce downtime; however, zero downtime should not be promised without validation of the method, dependencies, and acceptance tests.

Is it better to move existing equipment or buy new hardware?

Make the decision around the service's overall requirements, not the device alone. Assess support status, failure risk, capacity, procurement lead times, licensing, and testing costs together. Installing new capacity at the destination may allow parallel testing, but compatibility with the new platform still needs to be verified separately.

Will IP addresses change after the relocation?

That depends on the conditions governing address use and the new connectivity architecture. Provider-dependent public IP addresses may change. Even with portable resources, announcement authorization, route filters, and carrier acceptance must be checked. Retaining internal IP addresses does not mean gateways, routing, and security rules will remain unchanged.

Is lowering the DNS TTL enough for a fast cutover?

No. Records previously cached with a long TTL are not retroactively updated when a new value is entered. Plan the reduction in advance, account for the previous TTL, and monitor actual access. A DNS change alone does not manage existing application sessions or every aspect of client behavior.^[7]

How should an application with an RPO target of zero be migrated?

First determine which transactions must not be lost and how this will be verified. Demonstrate that the last confirmed transactions are present at the target using an application-supported synchronization method and a controlled transition of write activity. Rollback after new transactions begin at the target must be designed separately. Selecting a product does not, by itself, demonstrate zero data loss.

Who owns and manages the hardware after a move to colocation?

When an organization uses its own hardware for colocation, ownership remains with the organization; leasing and other commercial models are different. Distinguish facility infrastructure from operating system, network, application, and data management. Any management tasks undertaken by the provider must be explicitly defined in the contract.

Is moving to colocation the same as moving to the cloud?

No. Colocation is the facility and infrastructure model in which equipment is hosted. Cloud migration may also change resource consumption, services, and the operating model. In the same project, some services may move to the cloud and others to colocation; prepare dependency, connectivity, and responsibility plans for each group.

How are backups and disaster recovery affected by relocation?

The primary environment's location, connections, access permissions, and replication directions may change. Verify backup jobs and restores in the new environment, and update addresses, sequencing, and capacity in the recovery plan. A temporary target becoming the new production environment does not remove the need to protect that environment in its own right.

Should critical systems always be moved last?

No. Starting with a low-risk pilot is a useful project approach, but dependencies and business requirements determine the order of the waves. Shared services such as identity or networking may need to be ready beforehand. What matters is the point at which a critical service has been sufficiently tested and can be rolled back.

How should data center relocation be assessed in relation to KVKK?

Assess data security, authorized access, service provider roles, contracts, and retention conditions together. Choosing colocation does not automatically establish compliance. Technical and administrative measures appropriate to the organization and data types should be defined with legal and information security teams.^[10]

When is a relocation project considered complete?

Closure can be considered when business services have been accepted, data consistency and access have been verified, monitoring/backup/recovery tasks work in the new environment, and operational responsibilities have been handed over. Decommissioning of the old environment and any applicable media sanitization records must also be completed. Equipment delivery or a successful startup alone does not constitute project closure.

Moving from a Server Room to Colocation with Ixpanse

Ixpanse's carrier-neutral data center approach in Ankara and its colocation services provide a foundation for assessing hosting and connectivity requirements together. Connectivity options available through Ankara IX can also be considered alongside requirements between locations and cloud environments.

Assess post-migration needs for data protection and managed infrastructure services separately. Do not assume cabinet and power capacity, connectivity delivery, on-site intervention, transportation, application migration, and operational tasks are all covered by the same scope. Clarify them through a project-specific proposal and responsibility matrix.

Discuss your project with the Ixpanse expert team to assess your move from a server room to colocation alongside capacity, connectivity, downtime objectives, and operational responsibilities. Bringing an inventory of current equipment and applications, growth expectations, connectivity requirements, and acceptable downtime to the discussion makes it easier to define the scope.

Conclusion: Relocate the Working Service, Not Just the Equipment

A successful data center relocation is measured not by equipment arriving in a new cabinet, but by verified business services operating in the new environment. Inventory, dependencies, target capacity, network cutover, data consistency, and rollback are all parts of the same plan.

Select the migration method service by service. Separate the planned downtime window from preparation time and recovery objectives. Require evidence at every decision point, and remember that rollback assumptions change once new production data is created. Do not consider the project finished before operational handover and controlled decommissioning of the old environment are complete.

The starting question should not be “Which night should we move the equipment?” but “What dependencies does each service have, under what conditions will it be considered available, and how will we continue operating if the plan does not work?”

Related Ixpanse Guides

At the decision stage, compare infrastructure models. For connectivity design, explore carrier-neutral data centers; for continuity objectives, review RPO and RTO; and for the protection plan, consider backup strategies and the DRaaS approach together.

Technical References

The sources below support the concepts and technical distinctions in the relevant sections. The runbook, responsibility, cost, and checklist tables are example frameworks prepared for this guide; they are not mandatory templates prescribed by a standard or records of a real organization's project.

1. NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems. The contingency planning approach.
2. NIST CSRC Glossary — Recovery Time Objective. The RTO concept.
3. NIST CSRC Glossary — Recovery Point Objective. The RPO concept.
4. Microsoft Learn — About Recovery Plans. Application dependencies and startup sequencing.
5. IETF RFC 7454 — BGP Operations and Security. BGP operations and route filtering.
6. IETF RFC 9582 — A Profile for Route Origin Authorizations. Prefix and origin-AS authorization.
7. AWS Route 53 — Making Route 53 the DNS Service for a Domain That’s in Use. Lowering the TTL and waiting for the previous TTL's effect to expire. Used for the DNS principle in this guide; changing DNS providers is not required for a move to colocation.
8. IETF RFC 8767 — Serving Stale Data to Improve DNS Resiliency. Serving expired DNS data in exceptional circumstances.
9. NIST SP 800-88 Rev. 2 — Guidelines for Media Sanitization. Media sanitization programs and data sensitivity.
10. Personal Data Protection Authority — Obligations Concerning Data Security (in Turkish). Technical and administrative measures appropriate to the risks, and auditing.
11. Personal Data Protection Authority — Erasure, Destruction, or Anonymization of Personal Data (in Turkish). Assessment of data retention and disposal.