# Cloud Migration Assessment — One Application

> 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 | | |