Stop 13 · Cloud Migration & Multi-CloudTopics · 2/8

Migration Assessment & Planning

In short

Most migrations that run late didn't fail in the cloud. They failed weeks earlier, when someone moved a server without knowing three other systems quietly depended on it.

Cataloging existing applications, their dependencies, and their technical debt before migrating — skipping this step is a common cause of migrations that stall or blow past their budget and timeline.

The blob character traces coloured wires from a switchboard to a fan with a torch and notepad.

Think of it like this

Tracing the wires first

A good electrician doesn't start cutting wires when rewiring an old flat. First he flips each switch and notes which fan, bulb or socket it runs. That one boring hour saves a day of surprises and a burnt fuse.

Watch it happen

From a messy data centre to a migration plan

Discover

Map deps

Assess

Pick the R

Waves

Schedule

1/6Build an inventory: every server, app, database, owner, OS version and monthly cost. Discovery tools can scan for you.

The big ideas

What you need to know

Inventory everything

You can't move what you don't know exists. Forgotten cron jobs and shared file servers cause most surprises.

Dependencies decide order

If two apps share a database, moving one alone can add slow cross-network calls or break it.

Every app needs an owner

Someone must say what "working" means and sign off after the move. No owner, no migration date.

Build a cost baseline

Note what each app costs today. Without it, nobody can prove later that the move saved money.

See it in code

Walk through the code

json

1{2  "app": "fee-portal",3  "owner": "accounts-team",4  "servers": ["web-01", "web-02", "db-01"],5  "dependsOn": ["student-db", "payment-gateway", "smtp-relay"],6  "os": "Ubuntu 18.04",7  "peakUsers": "admission week",8  "downtimeAllowed": "2 hours on Sunday night",9  "strategy": "replatform",10  "wave": 211}

1/4What the app is, who owns it and which machines it runs on.

One row of a migration inventory. Real teams keep hundreds of these, usually in a sheet or a discovery tool.

Save yourself the pain

Common mistakes

Oops

Trusting an old spreadsheet of servers made two years ago.

Do this instead

Run fresh discovery and check network traffic. Real connections reveal dependencies people forgot.

Oops

Planning the first wave around the most important app.

Do this instead

Start with small, low-risk apps. The team learns the process before touching anything critical.

Your mission

Map your own laptop

~30 min

Quick check

The library app and the fee portal both read from the same student database. What should the plan do?

Go deeper

1Draft a migration assessment template: application, dependencies, data volume, downtime tolerance.
2Learn why dependency mapping often surfaces the biggest unexpected complications.
3Practice prioritizing which applications to migrate first based on risk and complexity.