Cloud Migration Assessment Template
A per-application assessment for a cloud migration — current state, data gravity, dependencies, the migration pattern chosen, cost before and after, and the rollback that makes the cutover safe.
Markdown. No sign-up, no email.
Complete one of these per application, not one per programme. Migrations fail at the application level, and the ones that hurt are always the application everybody assumed was simple.
Application: _______________ Business owner: _______________ Technical owner: _______________ Date: _______
1. What it is#
| What it does, in one sentence | |
| Users (number, internal/external) | |
| Business criticality | critical / important / routine |
| Hours it must be available | |
| Acceptable downtime for the cutover | |
| Who notices first if it stops |
If it disappeared for a day, what would actually happen? _______________
Ask this question of the business owner, not the technical owner. Roughly half of the applications on a typical migration list turn out to be retirable, and retiring one is the cheapest possible migration.
2. Current state#
| Servers / instances | |
| Operating system + version (still supported?) | |
| Runtime + version | |
| Database + version | |
| Data volume today, growth per year | |
| Licensing that follows the workload |
3. Dependencies — the part that breaks cutovers#
| Depends on | Direction | Latency sensitive | Moving at the same time |
|---|---|---|---|
| in / out | yes / no | yes / no |
Hard-coded IP addresses, hostnames or file paths anywhere: _______________ Scheduled jobs that touch this system: _______________ Anything that connects to it that we do not control: _______________
🔴 The dependency nobody documents is the batch job on someone's machine. Ask the operations team, and ask what runs overnight.
4. Data gravity#
| Data volume to move | |
| Bandwidth available | |
| Estimated transfer time at that bandwidth | |
| Can the source stay writable during transfer | yes / no |
| How changes during transfer are reconciled | |
| Residency or sovereignty constraints |
Data movement, not application compatibility, sets the schedule for most migrations. Calculate the transfer time before agreeing to a cutover window.
5. Migration pattern — pick one, record why#
| Pattern | Meaning | Chosen |
|---|---|---|
| Retire | Turn it off | |
| Retain | Leave it where it is, for now | |
| Rehost | Move as-is | |
| Replatform | Move with modest changes (managed database, container) | |
| Refactor | Rework for cloud services | |
| Repurchase | Replace with a product |
Why this pattern: _______________ What we are explicitly NOT doing in this move: _______________
Doing a rehost and a refactor in one step means that when something breaks you cannot tell which change caused it. Move it, stabilise it, then improve it.
6. Target state and cost#
| Today | Target | |
|---|---|---|
| Compute | ||
| Storage | ||
| Database | ||
| Network / egress | ||
| Licences | ||
| Backup | ||
| Monthly total |
Costs that will appear only after go-live (egress, cross-zone traffic, log volume, non-production environments): _______________
7. Security and compliance#
| Data classification | |
| Personal data involved | yes / no |
| Encryption at rest / in transit | |
| Who has access after the move | |
| Logging and retention requirement | |
| Sign-off required from |
8. Cutover plan#
| Proposed window | |
| Steps, in order | |
| Point of no return | |
| How we roll back, and until when | |
| Who decides to roll back | |
| Validation before declaring success |
Rollback tested on (date): _______
🔴 "We will roll back if needed" is not a plan unless someone has run it. Establish the point after which rollback is no longer possible, and make sure the decision-maker knows they are crossing it.
9. After go-live#
- [ ] Monitoring and alerts in place before the window, not after
- [ ] Old environment kept for ___ days, then decommissioned (date: ______)
- [ ] Backups running and one restore tested in the new location
- [ ] Cost checked against estimate at day 30
- [ ] Documentation and runbooks updated
- [ ] Licences on the old platform cancelled
Sign-off#
| Name | Date | |
|---|---|---|
| Technical owner | ||
| Business owner | ||
| Security | ||
| Go / no-go |