Migration
Part of Cloud migration planning
Assessing which workloads should move first
Choose early cloud migration workloads by screening readiness, comparing business value and risk, and selecting a useful first move group.
Pick an early migration workload that delivers useful learning or business value, has understood dependencies and can tolerate failure. Compare the groups that would actually move together, not individual servers ranked by size or apparent simplicity. Identify readiness blockers first, then weigh value, risk and effort among viable candidates.
From candidate screening to a reviewable first wave
- Screen for reasons to deferConfirm owner, reason, destination; log constraints; defer if blockers remain
- Compare move groups consistentlyAssess the group that moves together across business reason, impact, dependency confidence, effort, fallback and timing
- Choose a first wave that teaches somethingPick a manageable group with a clear owner, defined action and explainable dependencies
- Record the decisionState move, prepare, retain, replace or retire, with owner, evidence and open question
Screen for reasons to defer
Confirm the workload's owner, its reason for moving and the proposed destination. Check if the application should instead be retained, replaced or retired. Log unresolved software, licensing, data-handling and operating constraints as questions with owners.
Defer scheduling when an essential integration is unidentified, a required component is unsupported, no one can approve the change, or the team cannot describe a credible success check and fallback. A deferral needs a next action and review date. It is not a permanent rejection.
Defer scheduling: readiness screen
- Workload owner confirmed
- Reason for moving confirmed
- Proposed destination confirmed
- Retain, replace or retire option checked
- Unresolved software, licensing, data-handling or operating constraints logged with owners
- Essential integration identified
- Required component supported
- Change approver available
- Credible success check and fallback described
Compare move groups consistently
An application may share a database, identity service or batch process with another. Assess the group that must move together, including any temporary connections to components left behind.
Question / What to record
- Business reason
- Expected benefit of moving now and its owner
- Interruption impact
- Affected users, important actions and acceptable window
- Dependency confidence
- Known connections, open questions and separation limits
- Migration effort
- Data transfer, application changes, access, checks and operator work
- Fallback
- Whether the source could resume with a usable data state
- Timing
- Business dates, releases and available support staff
The table is a comparison aid, not a scoring formula. A valuable application may still need preparation before cutover. A lower-impact tool may be a good early choice if it exercises a migration pattern the team will reuse.
Choose a first wave that teaches something
Select a manageable group with a clear owner, a defined application action and dependencies the team can explain. Include enough real work to learn about the target environment, transfer, access and handover. A development environment can test parts of the procedure; it cannot establish production performance or data integrity.
For example, an internal reporting tool with one known feed might be an earlier candidate than a customer transaction service that shares a writable database with other applications. That choice depends on whether the feed can tolerate the proposed transition and whether the reporting tool's owner can verify its result.
Keep critical applications visible in the preparation queue. Resolve shared-data questions, rehearse their cutover and agree on acceptance and fallback conditions. A contractual deadline or expiring facility may change the order; record the reason and the additional safeguards.
Record the decision
For each candidate, record move in wave, prepare for later wave, retain, replace or retire, with its owner, key evidence and open question. State why the first group precedes the others. Revisit the order when discovery, a business date or a rehearsal changes the assumptions.
The output is a reviewable first wave and preparation queue, not a claim that every workload is ready.
Decision record for each candidate
- Move in wave
- Prepare for later wave
- Retain
- Replace
- Retire
- Owner recorded
- Key evidence recorded
- Open question recorded
- Reason the first group precedes the others stated
- Order revisit trigger noted
