Data Center Migration Checklist: A 2026 Field Guide for Indian IT Teams

The ₹18 Lakh Lesson from a Peenya Server Room

In March 2025, a 180-person logistics company in Peenya decided to move its primary data center from a leased room on the second floor to a Tier III colocation facility in Whitefield. The plan looked clean on paper. Sixty-two VMs, four physical servers, one SAN, a tape library nobody had touched since 2022. The project manager gave it ten days.

It took nineteen. The company lost ₹18.4 lakh in overtime, emergency transport, and two days of near-total order processing downtime because a single service account — a Windows 2012 R2 box running a legacy label-printing API that nobody had documented — held the DNS zone for three internal applications. When that box went down, so did warehouse dispatch. Nobody knew it existed until the third day.

That box cost more in lost business than the entire migration budget.

This is the pattern. Data center migrations rarely fail at the cutover. They fail during discovery, because the map was incomplete. What follows is the checklist we actually use at SynergyScape when we run these projects — not a generic template, but the working document, with the sequencing rules, rollback criteria, and post-move validation steps that keep projects from turning into that Peenya story.

Phase 1: Discovery and Dependency Mapping

This is where 70% of your project risk lives. Spend 40% of your total project time here. If your timeline has discovery at 15%, it will slip.

Asset Inventory: What Actually Counts as an Asset

Most teams inventory servers and call it done. That is the mistake. Your asset register needs five categories, not one.

For each physical server, capture: make and model (e.g. Dell PowerEdge R740, HPE ProLiant DL380 Gen10), age, warranty expiry date, serial number, rack unit position, and whether it is still under a support contract. An HPE DL380 Gen10 out of warranty is a different decision than one covered until 2027. If it is older than seven years and not covered, do not move it. P2V it or replace it.

Do not trust any inventory that has not been physically verified. We have walked into server rooms where the CMDB listed 48 servers and 51 were in the racks. Three had been decommissioned in 2023 but never powered off.

Application-to-Server Mapping: The Layer Everyone Skips

Every business application needs a row. Not a spreadsheet tab — a row with an owner name and a mobile number.

For each application, capture:

• Primary server or VM it runs on
• Database server it connects to
• Authentication source (AD, LDAP, local)
• File shares or object storage it reads/writes
• External endpoints it calls (payment gateways, GST APIs, SMS gateways)
• Scheduled jobs and their times
• Backup schedule and last successful restore test date
• Business owner (name, department, phone)

A typical 200-user Indian company runs 25–45 business applications. Eight to twelve of them will have undocumented dependencies. You will only find them by asking the business owner, not the server admin. The admin knows what the server does. The business owner knows what breaks when it stops.

Dependency Mapping: Build the Graph, Not the List

A dependency list tells you box A talks to box B. A dependency graph tells you what breaks when A moves and B does not. You need the graph.

Use a discovery tool to start. For Windows estate, run Microsoft Assessment and Planning Toolkit or a current tool like Lansweeper. For mixed environments, Device42 or Faddom give you traffic-level mapping. Most Indian SMEs have neither, so start with netstat captures on critical servers during peak hours, plus firewall log analysis for the last 30 days.

Rank every dependency into three tiers:

• Tier 1 — Hard. Server cannot function without it. Move together or the app breaks.
• Tier 2 — Soft. App degrades or fails after timeout. Can move within the same window but not across windows.
• Tier 3 — Reference. Logging, monitoring, or reporting. Move independently.

Write the dependencies down. Store the file in the project folder with a version number. This single document is worth more than the rest of the project plan combined.

The Failure Story That Keeps Appearing

The Peenya label-printing API was not unique. It was a Tier 1 hard dependency with no documentation. The reason it was missed: the application owner (a warehouse supervisor) assumed IT knew about it, and IT assumed the printing was handled by the ERP.

Every project has one of these. The way you find it is by walking the floor and asking operators what they use, not by asking IT. Do a two-hour walkthrough of every department that consumes IT services. Ask one question: "What screen do you use to do your job, and what happens when it stops working?" Three answers will surprise you.

Phase 2: Migration Strategy and Move-Group Sequencing

By the end of discovery, you have an inventory and a dependency graph. Now you decide how each workload moves.

Choose the Method, Not the Tool

Four methods exist. Pick per workload, not per project.

For a Bangalore-based company with a real colo contract, lift and shift is often right for the firewall pair (FortiGate 200F, for instance) and storage, while VMs re-host onto new hosts. Do not re-architect during a physical move unless you enjoy pain.

Move-Group Sequencing: The Rules That Hold

Move groups are how you avoid the interdependency trap. A move group is a set of workloads that must move together because they are tightly coupled. Between groups, you sequence by risk and by business calendar.

Six rules we use:

1. No group moves during month-end close, quarter-end, or GST filing week. That rules out roughly 12 days per month for most Indian finance-heavy firms.
2. Move non-production first, always. Dev and test groups prove the runbook before production risks anything.
3. Network moves before workload moves. Firewall, core switching, and routing must be stable before the first VM arrives.
4. Authentication last, not first. Moving AD early breaks everything. Move it after the applications that trust it, and keep a replica in the old room until the last group.
5. Databases move with their application, not separately. Cross-site database calls are the number one cause of silent corruption.
6. One group per 24 hours minimum, two if you have proven the runbook twice. Rushing this compresses the rollback window to nothing.

A typical sequence for a 60-VM environment looks like this:

• Group 0 (14 days before cutover): Network stack, monitoring, out-of-band management
• Group 1: Dev/test VMs and staging databases
• Group 2: Non-critical internal apps (intranet, print server, file services)
• Group 3: Mid-tier apps (CRM, HRMS, ticketing)
• Group 4: Primary ERP and its database
• Group 5: Authentication, DNS, PKI, backup infrastructure
• Group 6: Legacy or end-of-life systems being retired, not moved

Move-Group Size: Don't Make Them Too Big

A group should be between four and twelve VMs. Smaller and you spend too many nights in cutover. Larger and rollback becomes a multi-hour ordeal.

If a group cannot be rolled back within 90 minutes, it is too large.

Phase 3: Rollback Criteria — Deciding Before You Need To

Rollback is not a decision you make at 3 AM in a tired state. It is a decision you define weeks in advance, with numbers, and the person running the cutover only executes it.

Define the Rollback Triggers

Every migration has a go/no-go moment. Before that moment, rollback is cheap. After it, it is expensive. You need explicit numeric criteria for both the pre-point and post-point.

For a 40-VM production group, our standard rollback triggers are:

• More than 15 minutes over the planned cutover window without a validated cause
• Any data integrity failure (row counts, checksum mismatch on critical tables)
• More than three Tier 1 applications not responding within 30 minutes of their planned start time
• Database replication lag above 60 seconds sustained for 10 minutes
• Any unexpected firewall rule change that cannot be attributed to the migration script
• One confirmed security control regression (e.g. logging stopped flowing to SIEM)

Any one of these triggers triggers rollback. Not a debate. Rollback.

Rollback Time Budgets

Every group must have a stated rollback time budget. If your team says "about two hours", ask for a number in minutes and make them commit.

If rollback exceeds the maximum, treat it as a failed cutover and escalate to project sponsor. Downtime continues until resolved or the group is reverted.

What Rollback Actually Means

Rollback is not the same for every workload. Define it precisely.

• Server VMs: powered off in target room, powered on in source room, DNS reverted, storage remounted. 15–45 min.
• Databases: stop writes in target, replay transaction log back to source, restart replication in reverse direction, validate row counts. 45–120 min.
• File shares: revert DFS namespace target, remount shares, validate access permissions. 20–60 min.
• Firewalls: restore pre-change config from backup, reapply VPN tunnels, test critical tunnels. 30–90 min.
• Applications with external endpoints: reverse DNS and NAT, notify providers if IP allowlists exist. 30 min–24 hours (some vendors take a full day).

That last line matters. If your application has an allowlisted IP at a payment gateway, rollback may take 24 hours because the vendor has to update their firewall. Build this into your trigger definition.

Phase 4: The Cutover Runbook

A runbook is not a plan. A plan describes what will happen. A runbook is a numbered list of commands and checks that any competent engineer can execute without interpretation. If your runbook has a step that says "verify everything looks good", you have not written a runbook.

Structure of a Working Runbook

Every step has five parts: number, who, what, expected result, and where to record. Our templates always include a sign-off cell. No sign-off, no next step.

Example step (abbreviated):

Step 47. Engineer: Priya S.
Action: Disable replication link from source SQL-01 to target SQL-01-T.
Command: ALTER AVAILABILITY GROUP [AG_PROD] SET (ROLE = SECONDARY);
Expected: 'The operation completed successfully.'
Verify: sp_read_secondary_replica on target shows Not Synchronizing.
Record: MVG4-047 / OK / 22:14 IST

Every step has an owner. Every step has a verification. Every step is reversible or has a documented reason why not.

The Runbook Sections

1. Pre-flight (T-72 hours). Hardware validation, network path testing, storage capacity check, backup verification, change approvals logged.
2. Freeze and freeze verification (T-2 hours). Applications quiesced, users notified, batch jobs disabled, incoming data queued. Verify the freeze with a monitor, not with a promise.
3. Final data sync (T-30 minutes). Replication lag checked, last delta pushed, target database validated with row counts and a 10-record spot check.
4. Cutover (T-0). Execute the actual moves. DNS updates staged but not committed until validated.
5. Validation (T+15 minutes). Business-level tests, not server-level checks. Can the operator print a label? Can the warehouse supervisor process an order? Can finance raise an invoice?
6. Commit or rollback (T+60 minutes). Decision point. Use the criteria from Phase 3.
7. Post-cutover monitoring (T+0 to T+72 hours). Elevated monitoring, on-call engineer, defined escalation.

Communication Plan

The single most common runbook failure is communication, not technology. At T-24 hours, distribute a one-page document with: the scheduled window, expected impact per system, source-of-truth contact, and a phone number (not email) for escalation. At T-1 hour, announce the freeze. At T+0, announce cutover start. At T+30, provide a status. At T+completion, announce success and confirm the freeze is lifted.

Use a single WhatsApp group for the timing signals. It is faster and more reliable than email in Indian operations.

Phase 5: Site Preparation and Bangalore-Specific Realities

Moving to a new data center in Bangalore or shifting to a colo provider comes with operational details that no vendor-neutral checklist covers.

Cabling: Monsoon and Legacy

Bangalore monsoons (June–September and October–November) are bad for cabling work. If your target room is in a building with poorly sealed conduits, water ingress into cable trays is a real risk. We have seen Cat6A runs degrade within a year of installation because the conduit filled with water during the August rains.

Specify outdoor-rated or LSZH cable for any runs that pass through unconditioned spaces. Budget ₹1,400–₹2,200 per structured cabling point (2026 rates in Bangalore, material and labour) for certified Cat6A. If your existing cabling is untested and over five years old, do not re-use it in the new room. Test every run with a Fluke DSX-5000 or equivalent; anything below Cat5e specification gets replaced.

Power: UPS, DG, and the Genset Start Time

Verify the new site's UPS topology. A typical small data center runs N+1 UPS with a diesel generator as backup. The critical number is the genset start time and the UPS runtime.

If genset start takes 45 seconds and UPS runtime is 8 minutes, you are fine. If the UPS is at 60% battery health and runtime has dropped to 3 minutes, you are not. Test the actual backup power path with a load bank before the first server goes in. Do not trust the UPS status panel.

ISP Circuits: Lead Times in Bangalore

If the new site needs new internet or MPLS circuits, start the process 10–14 weeks before cutover. Fibre last-mile provisioning from Airtel, Jio, or ACT in Bangalore can be quick (2–3 weeks) or slow (12+ weeks), depending on building permissions and last-mile trenching. Colo facilities generally have multiple carriers on-site, which typically cuts provisioning to 3–5 weeks — but confirm the carrier your existing firewall configuration relies on is actually present in the facility.

Compliance: CERT-In, DPDP, and Data Residency

For any migration that touches personal data — customer records, employee data, health information — the Digital Personal Data Protection Act (DPDP Act 2023) obligations apply from 2025 onward. Your migration plan needs to document:

• Where personal data will reside post-move (state, country, specific facility)
• Which processors and sub-processors are involved
• Retention periods for logs generated during migration
• Incident notification path if data is exposed during transit

For regulated sectors (BFSI, healthcare), CERT-In directions of April 2022 require incident reporting within 6 hours. Ensure your migration runbook names a security officer and the reporting channel.

GST treatment matters for the procurement side. Data center and colocation services attract 18% GST. If you are moving from an owned facility to a colo, this is a new input cost that changes your per-year run rate. Factor it into the business case before you sign a three-year colo agreement.

Phase 6: Post-Move Validation

You are not done when the servers are running. You are done when the business is operating normally and you have proof.

Application-Level Testing

Server ping tests prove nothing. Test the business process end to end.

• Process one order in the ERP, from quote to dispatch note
• Generate one invoice, verify it posts to the correct GST ledger
• Generate one payslip and check digital signature validity
• Book a leave request, approve it, confirm it routes correctly
• Run the nightly backup, confirm the backup completes, restore one file from it
• Send a test email to an external address and confirm SPF/DKIM/DMARC still pass (moving IPs often breaks email authentication)

That last item catches people off guard. If your mail is self-hosted or uses a smart host in the moved infrastructure, your sending IP changes, and your SPF record must be updated. Do it the day of cutover, not two weeks later.

Performance Baseline Comparison

Have a pre-move baseline: transaction response times, batch job durations, backup window durations, replication lag under load. Compare post-move. If any metric degrades by more than 20%, investigate before closing the project.

Typical post-move issues:

• MTU mismatch causing fragmentation and slow transfers
• Storage tier misconfiguration (SSD tier undersized, forcing hot data to NL-SAS)
• Firewall policy ordering causing latency on high-throughput paths
• DNS TTLs set too high causing slow failover if there is a rollback need

Documentation Handover

Update: CMDB, network diagrams, IP address register, firewall rule documentation, DNS records, certificate inventory, backup schedules, and runbook library. If any of these are more than 72 hours out of date, they are already drifting.

Costs: What a Data Center Migration Actually Costs in 2026

Cost depends heavily on scope. Here are ranges we see in Indian SME contexts (100–300 users, 20–80 VMs), 2026 pricing.

Add 18% GST on services. For a 60-VM migration with hardware refresh, ₹25–₹40 lakh all-in is a reasonable planning number.

If that number is out of reach, the alternative is not "cheaper migration". It is phased migration over 12 months, prioritizing non-critical workloads first and deferring hardware refresh where the warranty still holds. We have run those too, and they work — you just accept longer risk exposure.

Where This Approach Does Not Fit

We will be honest: this checklist is built for on-prem-to-on-prem or on-prem-to-colo migrations where latency and data residency matter. It is not the right shape if:

• You are moving primarily to public cloud (AWS, Azure, GCP). The move groups differ, and cloud-native migration patterns (Landing Zone, Azure Migrate, AWS MGN) have their own discipline.
• Your total footprint is under 10 VMs. You will spend more on the checklist than on the migration. Just do it in one weekend with a senior engineer and a solid backup.
• You have already decided to re-platform everything. If you are rewriting applications, sequencing rules differ.

If any of those are true, tell us upfront. We will say so and point you in a different direction. The worst outcome is a project scoped as a migration when it is actually a transformation.

FAQ

How long does a data center migration take for a 50-VM environment?

Plan for 8–12 weeks from kickoff to project close. Discovery alone is 3–4 weeks. Move-group execution is typically 4–6 weeks at one group per day. Add 2 weeks for post-move stabilisation and documentation. Anything claiming 2–3 weeks for 50 VMs is skipping discovery, and skipping discovery is how you end up with the Peenya story.

Can we migrate a data center without downtime?

In almost all cases, no. You can reduce downtime to a scheduled window of 2–6 hours per move group, but zero-downtime migrations require either active-active architecture (expensive, usually out of scope for SMEs) or application-level re-architecture. Anyone promising zero downtime for a lift-and-shift on a legacy ERP is overpromising. Plan for windows, communicate them, and execute cleanly.

What is the single most important step in a data center migration checklist?

Dependency mapping. Not cutover planning, not hardware selection, not rollback scripting. If your dependency map is wrong, every later step is built on sand. Spend the time. Use tools. Walk the floor. Ask operators, not just admins.

How do we handle DNS and IP changes during migration?

Two approaches. First, keep IP addresses identical between source and target (possible with L2 extension or with the same subnet routed to the new site). Second, if IPs must change, do it in a single window per group and update all downstream references in the same runbook — firewall rules, DNS records, application configs, monitoring, backup targets. Never split IP changes across multiple windows for the same application. That is where silent failures live.

What should be on a data center migration rollback plan?

Numeric triggers, defined rollback steps per workload type, time budgets per group, and a named decision-maker. Rollback without numbers is just hoping. Document rollback time budgets in minutes, not hours, and make the cutover engineer commit to them before the window opens.

Does moving to a colocation facility in Bangalore change our compliance obligations?

Yes. Under the DPDP Act and, for regulated sectors, CERT-In directions, you need to document where personal data resides, which processors handle it, and the incident reporting path. Colocation providers are processors under DPDP. Ensure your contract names them as such, specifies data residency guarantees, and includes breach notification timelines that meet your regulatory obligations. Also budget for the 18% GST on colo services — it changes your annual run rate by a meaningful amount.

Your Next Step

If you are planning a data center migration in the next six months, the highest-value thing you can do this week is not select hardware or sign a colo agreement. It is to build the first draft of your dependency map. Take your top 10 business applications and draw the lines between them. You will find at least two dependencies nobody documented.

If you want help building that map — or running the full project — talk to us. We have run migrations across Bangalore, Chennai, Hyderabad, and Pune, and we will tell you upfront if your project is not the right fit for our approach.