Before you move a whole data center, check the facility itself: the racks, circuits, leases, destination power and network, the period when old and new run together, any hardware that travels, and the closing down of the old site. This data center migration checklist covers the facility side of that move to the cloud. It works as a data center assessment, with 21 facility checks in six parts, each with a suggested owner, the evidence to collect and the risk if it is skipped.
This guide is for IT heads, infrastructure managers and operations leads at mid-size companies in India and the GCC. They have approved a move out of an on-premises or colocated data center. If that decision is still open, start with the signs that it is time. This checklist has nothing to do with Atlassian’s Jira Data Center product.
Last reviewed 2026-11-01 by Manish Sharma.
Data Center Migration to Cloud Checklist: The Short Answer
The checks here belong to the facility, not to any one application. The application-level checks sit in our cloud migration checklist for legacy applications, so this list points to them instead of repeating them. A checklist here is a readiness review. You record what you find, name the owner, and then decide at a short gate whether a wave goes ahead. As a data center assessment, it asks whether the facility is ready, while the application checklist asks whether each system is.
How to Use the 21 Checks
First, set aside a session for the data center assessment with the infrastructure owner, the network lead and whoever holds the contracts. Then, for every row, write down what you saw, the evidence (a record, a contract page, a test result) and the person who confirmed it. So a check passes only with its evidence. Change nothing yet, because this pass is about learning where the facility stands.
The owners in the tables are only suggestions, so adapt them to your team. Also, the split-site and rollback checks draw on Microsoft’s Cloud Adoption Framework. In contrast, the checks for racks, leases, moving hardware and closing the site are practice, not taken from a vendor source.
Colocation is renting space and power in another operator’s facility. A cross-connect is a direct cable link between two parties in the same facility, while a circuit is a leased network link and a lease is the contract for space or equipment. The split-site period is the time when the old and new sites run together.
What the Application Checklist Already Covers
Checks that look the same for one application or a whole estate sit in our cloud migration checklist for legacy applications. Then run them for each system in scope. So the table gives the check numbers in that list.
| Shared check | Number in the application list |
|---|---|
| Named owners; success criteria and a baseline | 1, 2 |
| Inventory with support status; supported versions | 4, 5 |
| Internal and external dependencies; hard-coded addresses; shared databases | 8 to 11 |
| Identity, encryption, residency and landing zone | 12 to 15 |
| Data path, restorable backups, cutover method, rollback plan, recovery targets | 16 to 20 |
| Test environment, tests and rehearsal | 21 to 23 |
| Post-cutover metrics against the baseline; acceptance | 25, 26 |
Our guide to application migration to cloud gives the method for those application-level steps.
Data Center Migration to Cloud Checklist, Part 1: Racks, Circuits and Leases
Four checks establish first what you have and then what binds you. The surprises in a facility move are the ones nobody wrote down, which is why Part 1 comes first.
| Check | Suggested owner | Evidence to collect | Risk if skipped |
|---|---|---|---|
| 1. Every rack, device, cable run and circuit listed with location, owner and purchase date | Infrastructure lead | Inventory export, with serial numbers and cabling recorded before anything is disconnected | Otherwise, an undocumented device is left behind or breaks something |
| 2. Contracts, leases, maintenance agreements and carrier circuits with notice periods and exit terms | Procurement with the infrastructure lead | A table of each contract, its end date, notice period and exit terms | As a result, a missed notice period locks you in |
| 3. Power, cooling and floor-space footprint of what moves and what stays, per rack | Facilities lead | Per-rack figures for what each rack draws and occupies | The old site is left half-empty and badly balanced, or the new one is undersized |
| 4. Equipment and lease end dates, with those that fix the order of the move marked | Infrastructure lead | A dated list with the fixed dates highlighted | A date arrives before the system has moved |
An undocumented device or an unread notice period is the one that can cost a month. So read the contract text, not the summary.
Data Center Migration to Cloud Checklist, Part 2: Destination Power, Space and Network
Three checks confirm that the destination is ready before any equipment leaves. AWS’s checklist for small and mid-size businesses (1 September 2025) puts the landing zone before the first application move. The same order also makes sense for a physical destination.
| Check | Suggested owner | Evidence to collect | Risk if skipped |
|---|---|---|---|
| 5. Colocation or hybrid space confirmed: rack positions, power feeds, cooling, cross-connects | Infrastructure lead | Written confirmation from the facility operator before equipment moves | Otherwise, equipment arrives and has nowhere to go |
| 6. Carrier circuits and site-to-site links ordered with their lead times, and tested for bandwidth and latency | Network lead | Order records, lead times and test results, for example bandwidth and latency | So the move waits for a link that is not ready |
| 7. The addressing, DNS and VLAN plan for the move, including whether any Layer 2 network is stretched between sites | Network lead | A written plan, reviewed by the network and security leads before the move | A stretched network can spread one fault across both sites |
A VLAN is a logical network segment on shared switches. A stretched Layer 2 network goes further: it extends one segment across two sites.
Circuits can be the longest wait, so start the request before the rest of the plan is finished.
Data Center Migration to Cloud Checklist, Part 3: The Split-Site Period and Parts That Stay
Four checks cover the period when you run in two places and the components that do not move yet. Microsoft advises keeping the split short and delaying a wave until more can move together.
| Check | Suggested owner | Evidence to collect | Risk if skipped |
|---|---|---|---|
| 8. An end date and an owner for the split-site period | Migration lead | A dated plan with a named owner | As a result, the split drags on with no one answerable for ending it |
| 9. Components that stay, each with the technical or regulatory reason and a plan | Architect with compliance lead | A list of each component, its reason and its plan | Otherwise, a component stays by accident and nobody plans for it |
| 10. The order of moving shared storage and network segments, before or with what depends on them | Infrastructure lead | A sequence showing each dependent system | A system moves before the storage it needs |
| 11. Where shared services such as identity, DNS, time and monitoring live during the split | Platform lead | A diagram of each service and its location in each phase | A shared service fails when one site loses the other |
Key Takeaway The split-site period carries risk, so set its end date before it starts.
Data Center Migration to Cloud Checklist, Part 4: Moving the Hardware
Three checks apply only if equipment physically moves to colocation. But if nothing physical moves, skip this part.
| Check | Suggested owner | Evidence to collect | Risk if skipped |
|---|---|---|---|
| 12. A move plan: cable labels at both ends, asset tags, rack and unrack sequence, transport, insurance and chain of custody | Infrastructure lead | The written plan and an asset-tag list | Cables are reconnected wrongly, or equipment goes missing |
| 13. Access and permissions at both sites, with carrier and vendor staff on standby during the move | Facilities lead | Access lists and a contact sheet | As a result, the move stalls at a locked door |
| 14. A power-down and power-up order, with shutdown and startup tests | Infrastructure lead | The written order and test results, including shutdown and startup | Otherwise, systems start in the wrong order and fail to come up |
If every workload goes to the cloud, Part 4 does not apply. Part 6 still does.
Data Center Migration to Cloud Checklist, Part 5: Cutover Window and Facility Rollback
Three checks define the facility’s way back, so write them down before the move. Our high availability checklist, however, covers failover and recovery design separately.
| Check | Suggested owner | Evidence to collect | Risk if skipped |
|---|---|---|---|
| 15. The old site stays powered, connected and under contract until each wave is validated, with a date it can be released | Migration lead | The release date and the contract position | The way back disappears before the new site is proven |
| 16. The read-only point and freeze window for shared storage, set before the final sync | Storage lead | A written window and the steps | Writes continue to the old copy after the final sync |
| 17. An agreed trigger and a named person who can order the old site back into service | Migration lead with the sponsor | A signed trigger and name | No one can decide to go back |
Releasing circuits or a lease before validation removes the way back. Keep both until each wave is signed off.
For failover and recovery design, see our high availability checklist.
Data Center Migration to Cloud Checklist, Part 6: Decommission and Sanitization
Four checks close the old site, because this is the part application checklists leave out.
| Check | Suggested owner | Evidence to collect | Risk if skipped |
|---|---|---|---|
| 18. A defined stability period and a written sign-off before the old site is touched | Migration lead with the sponsor | A signed sign-off and the date it passed | The old site is dismantled while the new one is still unproven |
| 19. Every drive sanitized or destroyed to a named standard, with certificates | Security lead | Certificates by serial number | Otherwise, data leaves the building on a drive |
| 20. Equipment returned, recycled or disposed of with asset tracking and chain of custody | Infrastructure lead | Asset records and disposal receipts | So equipment cannot be traced after it leaves |
| 21. Contracts, leases and circuits ended, site access revoked, space and power released, records updated | Procurement with the facilities lead | Termination notices, as well as access removal records | You keep paying for, or keep access to, a site you have left |
Sanitization is making the data on a drive unrecoverable. NIST publishes SP 800-88 Rev. 2, Guidelines for Media Sanitization (September 2025, which replaced Rev. 1 of 2014). Then name the revision you follow in your records.
Key Takeaway The old site closes only after a signed stability period, and every drive leaves with a certificate.
A Short Facility Gate
Before each wave, answer three questions in writing, then check them against the evidence. The three answers close the data center assessment for that wave. The full gate pattern and the finding record are in the application checklist.
Parts 2 and 4 have evidence, and the circuits are tested before the wave.
Part 5 is in place and the old site is still powered and under contract.
Nothing in Part 6 has started until the stability period is over.
What This Checklist Does Not Cover
This checklist is a data center assessment of the facility, so it does not cover the application-level checks, the migration strategy or the choice of destination. It also gives no cost lines and no template file. A data center assessment for cost or capacity planning is a different piece of work. So use the evidence column as your structure and the application checklist for the rest.
For the wider picture, see how Signisys supports data center infrastructure upgrades. Our page on server and data center work adds detail. See also our IT infrastructure, networking and data center services.
FAQ: Data Center Migration to Cloud Checklist
What should be on a data center migration to cloud checklist?
How is this different from a cloud migration checklist for one application?
Who should own each facility check?
When is the facility ready for cutover?
What should we check before shutting down the old data center?
Do we need the hardware-moving part if everything goes to the cloud?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.