Build brief · Cloud Computing
Turn an application inventory into evidence-based migration waves instead of moving the easiest-looking server first.
Start with the business or technical outcome
Migration risk is usually hidden in dependencies, ownership and operating habits rather than in the virtual machine alone. This field lab turns the topic into a small deliverable that can be built, checked and explained. A mid-sized organisation wants to move twelve applications but has incomplete documentation, shared databases and different recovery requirements.
A readiness assessment is not a sales forecast. It should expose uncertainty and show what must be learned before a migration commitment. Interview application owners, operators, security teams and data stewards; each sees a different dependency.
Classify data and regulatory constraints before choosing a target. Record peak usage, batch schedules, identity dependencies, integrations, support windows and business deadlines. Unknown values belong in the assessment as risks, not as guessed answers.
What to understand before opening the tool
Understand the broad migration patterns: retire, retain, rehost, relocate, replatform, repurchase and refactor. The label is less important than the evidence behind it and the operating model after migration.
Readiness includes people and process. Monitoring, patching, identity, backup, incident response, cost ownership and change control need future-state owners before cutover.
Discovery Inventory
Use it for: capture applications, owners, technology, usage and lifecycle Keep as evidence: validated workload register
Dependency Map
Use it for: show inbound, outbound, data and identity relationships Keep as evidence: reviewed system diagram
Readiness Scorecard
Use it for: compare business, technical, security and operational gaps Keep as evidence: scored evidence with unknowns
Wave Plan
Use it for: group workloads by dependency and learning value Keep as evidence: sequenced plan with entry and exit gates
The practical outcome is a workload inventory, dependency map, readiness score, migration-pattern decision and sequenced wave plan with exit criteria. Build it with fictional, public or explicitly authorised data. Record the starting state before making changes, because a screenshot of the final screen cannot explain how the result was produced. The strongest evidence is a short chain: requirement, action, validation and one reflection on what you would improve.
Build the workflow in six controlled moves
Move from facts to classification, then use an early low-risk wave to test the operating model.
- Define assessment scopeName business outcomes, deadlines, excluded systems and decision owners.Checkpoint: Signed scope and success criteria.
- Discover workloadsCollect runtime, data, usage, support and ownership facts from tools and interviews.Checkpoint: Inventory with source and confidence.
- Map dependenciesTrace calls, shared databases, files, identity, DNS, schedules and manual hand-offs.Checkpoint: Dependency map reviewed by owners.
- Assess constraintsEvaluate security, compliance, latency, licensing, recovery and skills gaps.Checkpoint: Risk register with accountable owners.
- Select migration patternChoose a provisional pattern for each workload and document rejected options.Checkpoint: Decision record per application.
- Sequence wavesGroup by dependency, business calendar and learning; define rollback and acceptance.Checkpoint: Wave roadmap and cutover gates.
Do not rush through the successful path. Repeat one step with a controlled variation and compare the evidence. That second run reveals which inputs are important and gives you a concrete troubleshooting story for interviews.
Tools, decisions and proof
A readiness score should reveal evidence gaps rather than produce a decorative percentage.
| Decision or signal | Action to take | Evidence to retain |
|---|---|---|
| Business ownership | Named owner and acceptable downtime | Owner approval and calendar |
| Technical dependency | Interfaces and shared services understood | Validated map and test cases |
| Data and compliance | Classification, location and retention known | Data-owner review |
| Operations | Monitoring, backup, patching and support designed | Future runbook and RACI |
| Financial model | Current baseline and target drivers compared | Assumptions with sensitivity range |
Failure tests that improve the project
Migration programmes fail when optimistic unknowns are treated as green status.
- Inventorying servers but not services: Applications depend on identity, data, networks, vendors and people.
- Choosing rehost by default: Speed may preserve cost or reliability problems that needed redesign.
- Ignoring business calendars: Cutover near financial close or peak season can multiply impact.
- Scoring without evidence: Every rating should cite a source, test or accountable owner.
- Planning cutover before operations: The team that runs the target needs tools, access and rehearsal first.
Turn the exercise into credible portfolio evidence
Create a fictional portfolio of six workloads: a public website, ERP integration, file server, batch process, database and retired tool. Produce the inventory, dependency diagram and two migration waves.
Add one decision where retain is more responsible than migrate. This shows that assessment quality is measured by fit, not by the number of systems moved.
Explain it clearly in an interview
Explain which unknown changed your sequencing, why one workload became the pilot and how you would prove business acceptance before retiring the source.
Peer review before calling the work complete
Ask another learner to inspect the result without watching you build it. Give them the original scenario—a mid-sized organisation wants to move twelve applications but has incomplete documentation, shared databases and different recovery requirements.—and the evidence pack, but not your intended conclusion. They should be able to trace the input, identify the main decision and locate the proof of the output. If they cannot, improve the labels, timestamps or explanation instead of adding decorative screenshots.
Use this acceptance condition during the review: Every workload has an owner, dependency confidence, data classification, provisional pattern and explicit entry or exit criteria; unknowns remain visible and assigned. Record one question the reviewer raised and the change you made in response. That small feedback loop makes the cloud migration readiness assessment exercise more credible, easier to maintain and easier to explain under interview questioning.
Questions learners ask
What is migration readiness?
It is evidence that a workload, organisation and target operating model are prepared for a controlled migration decision.
Should the easiest server migrate first?
Not always. A useful pilot has manageable risk, clear success measures and enough representativeness to teach the team.
Is rehosting always the fastest option?
It can reduce application change, but dependencies, testing, landing-zone readiness and operations still determine elapsed time.
Why include retain and retire?
A good assessment considers whether migration creates value at all, rather than assuming every workload needs a cloud target.
Use current product guidance
Menus, fields, permissions and service behavior can change between product versions or tenant configurations. Check the NIST cloud computing definition before applying version-sensitive steps in a live environment.
Build the complete skill path
Learn cloud service models, architecture, migration, resilience, security and cost decisions through provider-neutral scenarios and practical labs.
Final perspective
The real value of cloud migration readiness assessment is the ability to complete a controlled task and defend the result with evidence. A learner who can show the input, explain the decision, verify the output and describe one realistic exception demonstrates far more than someone who has only memorised a menu path or definition.