Cloud Migration Readiness Assessment: 11-Point Checklist and Transfer Time Estimator
Most problems in a server move to the cloud do not start on migration night; they start with an item that was skipped during preparation. This cloud migration readiness assessment works as a cloud migration checklist with 11 questions: inventory, dependencies, verified backups, rollback, downtime window, licensing, bandwidth, security rules, test scenarios, application owners and day-one monitoring. Each question is answered Yes, Partly or No, and the result is a readiness score from 0 to 100 plus a list of gaps ranked by weight.
Below the questions, a transfer time estimator works out how long your data will take to copy from its size and your line speed. Your answers stay in your browser and are not sent to any server.
Close the Gaps With a Migration Team
The gaps in your result show which parts of the migration plan are not ready yet. The MAV Cloud team can work through them with you, based on your current infrastructure and business calendar.
What does migration readiness mean?
Migration readiness means knowing, before the move, what each system is, what it depends on, and how to bring it back if something goes wrong. It also needs an approved downtime window and application owners who take part in testing.
Microsoft’s Cloud Adoption Framework follows the same order in its migration planning guidance: discover dependencies, group workloads into waves, define and test a rollback plan before migrating, and set success criteria up front (Microsoft, Plan your migration). This assessment condenses that approach into a one-page self-check.
Which 11 items does the assessment score, and how are they weighted?
Each item carries a weight from 1 to 3; Yes earns the full weight, Partly earns half and No earns zero. The weights add up to 22, and the score is the points earned as a share of that total, on a 0-100 scale.
| Item | Weight |
|---|---|
| Up-to-date server and application inventory | 3 |
| Documented dependencies | 3 |
| Verified pre-migration backup with a tested restore | 3 |
| Rollback plan | 2 |
| Agreed downtime window and communication plan | 2 |
| Software license terms checked for virtual/cloud use | 2 |
| Identity, access and firewall rules designed for the new environment | 2 |
| Post-migration test scenarios and acceptance criteria | 2 |
| Bandwidth and transfer time calculated | 1 |
| Application owners and software vendors involved | 1 |
| Monitoring and backup planned from day one | 1 |
Inventory, dependencies and backups carry the highest weights. A gap here usually causes the hardest problem to undo.
The core areas of a server migration plan
A solid server migration plan gives a written answer to each of the 11 items.
Inventory and dependency map
The inventory should list servers, operating system versions, running applications, disk sizes and databases. The dependency map shows which application talks to which database, file share, identity server or external service. If systems sharing a database are not moved together, one ends up in the cloud and the other on premises, and the latency between them hurts performance.
Pre-migration backup and restore test
Having a backup is not the same as having a verified one; a backup that has never been restored and opened is unproven. Restore a fresh full backup in a separate environment and confirm the application starts with consistent data.
Rollback plan and downtime window
The rollback plan states in writing under which conditions the migration is called off and how the old system is brought back into service. Keep the source server running until the new environment passes acceptance. Pick a downtime window outside busy periods such as month-end close, and announce it to users and affected teams in advance.
Licensing terms
Some operating system, database and application licenses have specific terms for virtualization, core counts or hosting providers. Whether a license that is valid on a physical server can be used the same way in the cloud should be confirmed in writing with the software vendor or licensing partner before the migration date.
How is data transfer time calculated?
The estimator takes data size in gigabytes (GB) and line speed in megabits per second (Mbps), and assumes the line runs at 70% efficiency on average. The formula is: time (hours) = GB × 8,000 / (Mbps × 0.70) / 3,600.
| Data | Line speed | Estimated time |
|---|---|---|
| 1,000 GB | 100 Mbps | ≈31.7 hours (≈1.3 days) |
| 5,000 GB (5 TB) | 1,000 Mbps (1 Gbps) | ≈15.9 hours |
| 10,000 GB (10 TB) | 100 Mbps | ≈317.5 hours (≈13.2 days) |
The last row shows that large data sets cannot be moved inside a single downtime window. In that case the data is copied ahead of time while systems keep running (pre-seeding), and on migration night only the changes since the last copy are synchronized (delta sync). For very large sets, offline transfer on physical disks is another option.
Why redesign security rules and acceptance tests?
On-premises firewall rules and access rights cannot be copied one-to-one into a cloud network. IP addresses, VPN connections, admin accounts and exposed ports need to be redesigned for the new environment; unused rules can be dropped at the same time.
Acceptance tests write down in advance what must work for the migration to count as successful: user logins, invoicing, reports, printing and data exchange with integrations. Application owners and software vendors know these scenarios best, so involve them well before migration night.
Waves and a pilot migration
Rather than moving everything at once, related systems are grouped and moved in waves. The first wave is a pilot with a system that is low in complexity and business impact.
A pilot tests transfer time, rollback steps and test scenarios in practice. Microsoft’s guidance likewise recommends moving non-production environments and simpler workloads first, and scheduling critical systems after early successes.
How to read your readiness score
A score of 80 or more means high readiness, 50-79 medium and below 50 low. The ranked gap list on the result screen matters more than the number itself.
For example, a project with a partly ready inventory, no rollback plan and every other item complete earns 18.5 out of 22, a score of about 84. The score looks high, yet the rollback plan sits at the top of the gap list and should be closed before the migration date. Each gap comes with a recommendation and a service link.
Build the Migration Plan Together
Once the inventory, dependency map and transfer time are clear, migration waves and the downtime window can be planned. Share your current server details and the plan can be worked out together.
Common cloud migration mistakes
Most mistakes come from planning rather than technology:
- Treating a backup as verified without restoring it: when something breaks, the backup turns out to be incomplete or unreadable.
- Shutting down the source server too early: a server switched off before acceptance tests finish removes the rollback option.
- Skipping the transfer time calculation: a copy expected to finish overnight can take days.
- Leaving licensing for later: after the move, the license terms may turn out not to fit the new environment.
- Leaving monitoring for later: if backups and monitoring are not running from day one, problems are found through user complaints.
If one of the systems is a Remote Desktop (RDS) server, the RDS server sizing calculator estimates its size in the new environment. The general flow of a move is covered in our guide to migrating servers to the cloud.
Cloud migration with MAV Cloud
MAV Cloud runs server and application moves from planning through acceptance testing as part of its cloud migration services.
Migrated servers land on cloud servers running in an Equinix data center on VMware infrastructure.
For day-to-day operation after the move, MAV Cloud’s service level agreement sets a monthly 99.9% availability target for cloud server services. First-response targets are 15 minutes for critical, 1 hour for high, 4 hours for medium and 1 business day for low priority.
MAV Cloud is certified to ISO/IEC 27001, ISO/IEC 27701, ISO 22301, ISO/IEC 20000 and ISO 9001 (see our certifications).
Frequently Asked Questions
What should be checked before migrating to the cloud?
The three most critical checks are an up-to-date inventory, documented dependencies and a backup whose restore has been tested. Add a rollback plan, an approved downtime window, license confirmation, security rules and acceptance tests.
What readiness score should I aim for?
80 or above counts as high readiness. Even with a high score, if the gap list contains an item weighted 2 or 3, fix the migration date only after that item is closed.
Why does the transfer estimate use 70% efficiency?
A line is never fully available for data transfer: protocol overhead, other traffic and fluctuations reduce real throughput. 70% is a reasonable planning assumption; measure the real figure with a pilot transfer.
How is a very large data set migrated?
Copy the data ahead of time, sync only the changes on migration night, and consider offline transfer on physical disks if the line still cannot cope.
Are my answers stored anywhere?
No. The assessment and calculation run in your browser and your answers are not sent to a server.
Free Infrastructure Assessment Before You Migrate
Share your server list, data volume and the software you use, and your readiness and the right migration method can be reviewed together.
If your score is low, the top three gaps are the starting point of the migration plan. If it is high, the transfer time estimate and a pilot migration are the next steps.