Most cloud migrations that run late do so for the same reason: the team didn’t know exactly what they were moving. An application turns out to depend on a file share nobody mentioned, or a database is shared by three systems instead of one.
This template fixes that by making you write everything down first. Copy the table into a spreadsheet and fill in one row per application or service.
Step 1: List everything
For each application, capture these columns:
| Column | What to write |
|---|---|
| Application | The name your team uses for it |
| Owner | The person who can answer questions about it |
| What it does | One line, in business terms |
| Business impact if down | High, medium or low |
| Users | Internal, customers, partners |
| Depends on | Databases, file shares, other apps, third-party services |
| Data size | Rough size of its data (GB or TB) |
| Current hosting | Where it runs today |
| Known problems | Slow, fragile, out of support, hard to deploy |
| Approach | See step 2 |
| Wave | See step 3 |
Don’t aim for perfect. A rough first pass in a day is more useful than a perfect one in a month. Fill gaps by talking to the owners.
Step 2: Choose an approach for each one
Every application gets one of five labels:
- Retire. Nobody really uses it. Switch it off instead of moving it. Most inventories find a few of these.
- Replace. A SaaS product now does the job better. Move the data and stop running it yourself.
- Rehost. Move it as it is onto cloud servers. Fastest, but you keep the same problems.
- Replatform. Make small changes so it can use managed services, such as moving its database to RDS or Cloud SQL, or running it in containers.
- Refactor. Rework it properly to take advantage of the cloud. Most effort, most benefit. Save this for systems that matter and are changing anyway.
A common mistake is to refactor everything. Most applications should be rehosted or replatformed, with refactoring reserved for a few.
Step 3: Group into waves
A wave is a set of applications you move together over a few weeks. Good waves follow three rules:
- Start small and low-risk. The first wave should be one or two internal applications with few dependencies. Its real job is to test your process, tooling and runbooks.
- Move dependencies together. If two applications share a database, they go in the same wave, or the database moves first.
- Leave the most critical systems until you’ve practised. By the time you move customer-facing systems, the team should have done several migrations already.
Step 4: Write a runbook for each wave
For every wave, write down:
- the steps to move, in order, with who does each one
- how you’ll test that everything works afterwards
- the point of no return, and how to roll back before it
- who needs to be told, and when
Do a full rehearsal in a test environment before the real move.
Step 5: Track cost from the start
Set up cost reporting in your cloud account before the first wave, and tag every resource with its application name. That way you can see what each application costs to run, and you’ll spot over-sized servers early. Cloud costs that aren’t watched in the first three months are much harder to bring down later.
A worked example
| Application | Impact if down | Depends on | Approach | Wave |
|---|---|---|---|---|
| Internal wiki | Low | File share | Replace with SaaS | 1 |
| Reporting dashboard | Medium | Main database (read-only copy) | Rehost | 1 |
| Customer portal | High | Main database, payments API | Replatform | 3 |
| Main database | High | — | Replatform to managed database | 2 |
| Legacy billing tool | Medium | Main database | Retire, move to billing SaaS | 2 |
These rows are an example only. Your own inventory will look different, and that’s the point of doing it.
Planning a migration?
We'll help you build the inventory and the wave plan, then move with you.