CL-001·CL Track·Intermediate–Advanced·6–30 hrs saved

Decide Which Workloads Move, Stay, or Die — Before the Migration Bill Arrives

An AI-assisted cloud-readiness assessment that assigns each workload an evidence-based disposition and builds a migration roadmap aligned to business value, risk, cost, and organizational capability.

3Phases

15Prompts

6–30Hours saved

8Deliverables

Executive Brief

Your Challenge

You are being asked to move to the cloud, and the pressure is to pick a provider and start with the easy servers. But cloud migration is not a single technical action — it is a portfolio of business, application, data, security, network, identity, financial, and organizational decisions. Choose wrong and you inherit higher costs, unresolved security gaps, poor application performance, fragile hybrid environments, unexpected licensing charges, and a technically completed migration that delivers no business value.

Common Obstacles

Programs fail in predictable ways: starting with technology instead of outcomes, treating every workload the same, assuming cloud automatically reduces cost, underestimating application dependencies, ignoring data gravity and licensing, replicating on-premises architecture in the cloud, and migrating before landing-zone controls exist. Underneath sits the same habit — moving servers instead of workloads, and selecting migration strategies based on preference rather than evidence.

The ABME Approach

This workflow does it in order: define why the organization is adopting cloud and which outcomes are measurable, then inventory and group components into workloads, then assess readiness across every dimension, then compare all nine dispositions per workload and recommend one with rationale, prerequisites, complexity, and a migration wave. The objective is not to move everything — it is to determine the right disposition for each workload and require human validation before any migration is approved.

Insight Summary

Cloud readiness is not determined by whether a server can run in a cloud environment. A workload is ready when its purpose, dependencies, data, identity, security, operations, cost, validation, and migration path are understood well enough to make a responsible decision.

phase-1

"Move to the cloud" is not an outcome. If the stated driver isn't measurable, the assessment's first job is to force it into one — or reject cloud as the answer.

phase-1

Retirement often produces the highest immediate savings. Evaluate whether a workload should exist at all before deciding where it should run.

phase-2

Assess workloads, not isolated servers. A workload that migrates cleanly can still fail because a critical dependency stayed behind or its data has too much gravity to move.

phase-2

Rehosting moves technical debt unless remediation is planned. A facility deadline met by lift-and-shift is not modernization.

phase-3

Do not calculate a single average that hides a critical security or operational gap. A high overall score does not make a workload production-ready.

tactical

An AI-generated readiness rating is not authorization to migrate. AI organizes evidence; it cannot confirm infrastructure, licensing, dependencies, or usage that was never measured.

The Journey

Three phases; each lists the tools you'll use there.

Define Drivers and Scope the Portfolio

Establish measurable cloud objectives, gather evidence, and group components into workloads before any disposition is decided.

Determine why the organization is considering cloud adoption and which outcomes matter
Confirm each stated outcome is measurable, not aspirational
Gather inventory, dependency, cost, licensing, and readiness evidence
Group servers, databases, and services into business workloads
Identify retirement and replacement candidates before migration planning

Prerequisites Checklist

Assess Readiness and Assign Dispositions

Use the prompt pack to assess readiness across every dimension and compare all nine dispositions per workload.

Run the primary prompt with the collected evidence
Assess readiness across business, application, infrastructure, data, identity, network, security, operations, organization, skills, and financial dimensions
Compare Retain, Retire, Rehost, Relocate, Replatform, Refactor, Rearchitect, Repurchase, and Rebuild for each workload
Rate readiness, complexity, and business criticality
Record the workload disposition matrix with rationale and prerequisites

Cloud Readiness Prompt Pack Workload Disposition Matrix Cloud Readiness Scorecard

Sequence, Validate, and Govern

Build migration waves, define validation and rollback, and gate migration behind human approval.

Sequence workloads into migration waves based on readiness and dependencies
Define validation, rollback, and success criteria per workload
Build the risk register and confirm landing-zone prerequisites
Run the validation checklist and pass the approval gates
Require human validation before final migration approval

Validation Checklist Migration Risk Register Suggested Approval Gates Workload Retirement Checklist

What's Inside the Execution Layer

Numbered deliverables grouped by phase. Membership unlocks every tool.

2. PHASE 2Prompt Packprotected

Cloud Readiness Prompt Pack

One primary prompt and fourteen targeted follow-ups that assess readiness, compare dispositions, and build the migration roadmap without assuming cloud is always the answer.

Use this to

Run a full portfolio readiness assessment and disposition matrix
Assess individual dimensions — identity, network, data, security, landing zone
Build workload inventories, migration waves, business cases, and scorecards

Included with membership — $20/mo

Primary Prompt

Start here with the full set of collected evidence.

You are a senior cloud architect, enterprise architect, security reviewer, and cloud migration strategist.I will provide some or all of the following:• Business strategy• Cloud-adoption objectives• Data-center or hosting deadlines• Application inventory• Server inventory• Database inventory• Application architecture• Network diagrams• Dependency information• Identity architecture• Data classifications• Security requirements• Compliance requirements• Availability targets• Recovery objectives• Performance requirements• Current infrastructure costs• Cloud pricing assumptions• Licensing agreements• Support contracts• Application roadmaps• End-of-life dates• Incident history• Monitoring and utilization data• Backup and recovery design• Existing cloud environment• Landing-zone design• Skills inventory• Organizational constraints• Existing migration plansYour task is to assess cloud readiness and recommend a workload disposition and migration strategy.Do not assume every workload should move to the cloud.Do not begin by selecting a cloud provider or architecture.First:1. Summarize the business drivers.2. Identify the intended business outcomes.3. Determine whether each outcome is measurable.4. Summarize the current environment.5. Separate: • Confirmed facts • Reported observations • Inferences • Assumptions • Unknowns6. Identify missing evidence that materially affects the assessment.7. Identify the workloads and their components.8. Identify: • Business owners • Technical owners • Business criticality • Users • Data • Dependencies • Integrations • Regulatory obligations • Availability requirements • Recovery requirements • Performance requirements • Planned retirement dates9. Assess readiness across: • Business • Application • Infrastructure • Data • Identity • Network • Security • Compliance • Operations • Organization • Skills • Financial management • Governance10. Identify cloud foundation prerequisites, including: • Landing zone • Identity • Connectivity • Logging • Monitoring • Policy • Security operations • Backup • Recovery • Cost allocation • Infrastructure-as-Code • CI/CDFor each workload, compare these dispositions:• Retain• Retire• Rehost• Relocate• Replatform• Refactor• Rearchitect• Repurchase• RebuildFor each viable option include:• Business value• Benefits• Drawbacks• Technical complexity• Security impact• Compliance impact• Operational impact• Data impact• Dependency impact• Migration risk• Customer impact• Estimated effort range• Estimated cost considerations• Time to value• Reversibility• Prerequisites• Long-term technical debt• Exit considerationsThen recommend one primary disposition for each workload.For each recommendation provide:• Workload ID• Workload name• Business capability• Business criticality• Current environment• Current lifecycle status• Recommended disposition• Rationale• Readiness rating• Migration complexity• Confidence• Key evidence• Prerequisites• Dependencies• Security requirements• Data requirements• Connectivity requirements• Testing requirements• Migration approach• Rollback approach• Suggested wave• Suggested owner• Success criteria• Metrics• Risks• Open questionsRequirements:• Do not assume cloud will reduce cost.• Do not invent licensing rights.• Do not invent regulatory requirements.• Do not estimate cost without showing assumptions.• Do not evaluate servers independently when they form one workload.• Do not recommend multi-cloud without a clear requirement.• Do not recommend microservices, containers, serverless, or managed services solely because they are modern.• Identify workloads that should remain on-premises.• Identify workloads that should be retired or replaced instead of migrated.• Identify dependencies that require workloads to move together.• Identify data-gravity and latency concerns.• Identify unsupported platforms and end-of-life risks.• Identify missing ownership.• Identify where a proof of concept, benchmark, security review, licensing review, data assessment, or performance test is required.• Separate mandatory prerequisites from optional improvements.• State when evidence is insufficient.• Require human validation before final migration approval.Then produce:1. Executive summary.2. Cloud-adoption objectives.3. Current-state assessment.4. Readiness scorecard.5. Workload portfolio.6. Dependency summary.7. Security and compliance assessment.8. Data assessment.9. Network and identity assessment.10. Operational readiness assessment.11. Skills and organization assessment.12. Financial considerations.13. Workload-disposition matrix.14. Migration-wave recommendations.15. Landing-zone prerequisites.16. Quick wins.17. Major blockers.18. Risk register.19. Validation plan.20. Governance recommendations.21. Open questions.22. Recommended next actions.

Assess a Single Application

To assess one application in depth.

Assess this application for cloud readiness.Review:• Business purpose• Criticality• Architecture• Runtime• Dependencies• Data• Identity• Network• Security• Compliance• Availability• Recovery• Performance• Operations• Cost• Support lifecycle• TestabilityCompare:• Retain• Retire• Rehost• Replatform• Refactor• Replace• RebuildRecommend the most appropriate disposition and explain the evidence.

Build a Workload Inventory

To group raw infrastructure components into workloads.

Convert the supplied application, server, database, and dependency information into a workload inventory.Group infrastructure components by business workload rather than listing each server independently.Include:• Workload ID• Workload name• Business capability• Business owner• Technical owner• Components• Environment• Criticality• Users• Data• Dependencies• Integrations• Support lifecycle• Planned retirement• Migration status• Evidence quality

Identify Migration Dependencies

To determine which workloads must move together.

Analyze the workload inventory and identify migration dependencies.Create dependency groups based on:• Application calls• Database access• File shares• Identity• DNS• Certificates• Messaging• Scheduled jobs• Network rules• Shared storage• Shared services• Monitoring• Backup• Vendor integrationsIdentify which workloads should move together and which dependencies can remain hybrid temporarily.

Assess Landing-Zone Readiness

To check whether the foundation can receive production workloads.

Assess whether the cloud landing zone is ready to receive production workloads.Review:• Organization structure• Accounts, subscriptions, or projects• Identity• Privileged access• Network• DNS• Logging• Monitoring• Security tooling• Policies• Encryption• Key management• Secret management• Backup• Recovery• Resource naming• Tagging• Cost allocation• CI/CD• Infrastructure-as-Code• Exception management• Incident responseClassify each control as:• Ready• Partially ready• Not ready• Not applicable• Unable to assess

Assess Cloud Security Readiness

Before any production migration.

Assess cloud security readiness.Review:• Identity architecture• Federation• Multi-factor authentication• Privileged access• Service identities• Network segmentation• Private connectivity• Encryption• Key management• Secret management• Logging• Security monitoring• Vulnerability management• Configuration management• Incident response• Backup protection• Data classification• Compliance evidence• Shared-responsibility ownershipIdentify controls that must exist before production migration.

Assess Network Readiness

To surface connectivity blockers and validation tests.

Assess network readiness for cloud migration.Review:• IP address space• Overlapping ranges• Routing• DNS• Connectivity• Bandwidth• Latency• Redundancy• Firewalls• Inspection• Segmentation• Private endpoints• Internet ingress• Internet egress• Remote access• Third-party connectivity• Monitoring• Failure recoveryIdentify migration blockers and required validation tests.

Assess Identity Readiness

Before broad workload migration.

Assess identity readiness for cloud adoption.Review:• User identities• Administrative identities• Service identities• Device identities• Federation• Directory synchronization• Single sign-on• Multi-factor authentication• Conditional access• Privileged access• Role design• Legacy authentication• Break-glass access• Identity logging• Tenant structure• Joiner, mover, and leaver processesIdentify identity prerequisites for production workloads.

Assess Data Migration Readiness

To surface data sets that need separate migration plans.

Assess data readiness for cloud migration.Review:• Data ownership• Classification• Volume• Growth• Quality• Residency• Retention• Encryption• Backup• Recovery• Replication• Migration method• Transfer duration• Validation• Reconciliation• Cutover• Rollback• Egress requirements• Data gravityIdentify data sets that require separate migration plans.

Compare Cloud Migration Strategies

To compare dispositions for a selected workload.

Compare these strategies for the selected workload:• Retain• Rehost• Replatform• Refactor• Rearchitect• Replace• Rebuild• RetireFor each option include:• Benefits• Drawbacks• Business value• Technical complexity• Migration risk• Security impact• Operational impact• Cost considerations• Time to value• Reversibility• Prerequisites• Long-term constraintsDo not recommend the most transformative strategy by default.

Create Migration Waves

To sequence the workload portfolio.

Create migration waves for the workload portfolio.Sequence workloads based on:• Business priority• Readiness• Complexity• Dependencies• Criticality• Risk• Team capacity• Landing-zone readiness• Data requirements• Connectivity• Quick-win potential• Learning value• Contract deadlinesFor each wave include:• Objectives• Workloads• Prerequisites• Dependencies• Risks• Owners• Validation• Rollback• Success criteria

Create a Cloud Business Case

To prepare an executive decision document.

Create an executive cloud business case.Include:• Business drivers• Current-state risks• Target outcomes• Workload scope• Recommended strategies• Current-state cost categories• Migration cost categories• Target-state cost categories• Financial assumptions• Nonfinancial benefits• Risks• Timeline• Decision requiredAvoid promising cost savings without evidence.

Identify Quick Wins

To surface low-risk early actions.

Identify cloud-readiness quick wins.A quick win should have:• Clear business or risk value• Low implementation risk• Limited dependencies• Measurable outcome• Relevance to the broader cloud programExamples may include:• Retiring unused workloads• Enabling cost allocation• Resolving unsupported systems• Documenting dependencies• Establishing identity controls• Creating infrastructure standards• Adding backup validation

Create a Cloud Readiness Scorecard

To produce a category-level readiness view.

Create a cloud-readiness scorecard.Score:• Business• Application• Infrastructure• Data• Identity• Network• Security• Compliance• Operations• Organization• Skills• Financial management• GovernanceFor each category provide:• Score• Evidence• Major strengths• Major gaps• Required action• Owner• Target date or phase

3. PHASE 2Matrixprotected

Workload Disposition Matrix

A portfolio-level grid that records the recommended disposition, readiness, complexity, and migration wave for every workload.

Use this to

Record one disposition per workload with evidence
Compare readiness and complexity across the portfolio
Feed workload sequencing into migration waves

Included with membership — $20/mo

Reference rows from the blueprint — downloads ship as an empty skeleton

Workload	Criticality	Readiness	Recommended Strategy	Complexity	Wave
Customer Order Management	Mission Critical	Ready with prerequisites	Replatform	High	3
Internal Reporting Portal	Business Operational	Ready	Rehost	Low	1
Legacy Time Entry	Business Operational	Low	Repurchase	Medium	2
Unused Archive Application	Noncritical	Ready	Retire	Low	0
Factory-Control System	Mission Critical	Low	Retain	Very High	Not scheduled

4. PHASE 2Matrixprotected

Cloud Readiness Scorecard

A category-level scorecard that records a rating and the primary gap for each readiness dimension.

Use this to

Score each readiness dimension separately
Record the primary gap and required action per category
Avoid a single average that hides a critical gap

Included with membership — $20/mo

Reference rows from the blueprint — downloads ship as an empty skeleton

Category	Rating	Primary Gap
Business	Ready	Benefits require stronger metrics
Applications	Partial	Dependencies incomplete
Data	Partial	Classification not complete
Identity	Ready with prerequisites	Privileged access model pending
Network	Partial	Redundant connectivity not implemented
Security	Partial	Cloud logging not integrated with SOC
Operations	Not ready	Support ownership unclear
Skills	Partial	Limited infrastructure-as-code experience
FinOps	Not ready	Tagging and budget controls absent
Governance	Partial	Exception process undefined

RubricRating may use: 0 — Not assessed, 1 — Not ready, 2 — Major gaps, 3 — Ready with prerequisites, 4 — Ready, 5 — Optimized. Do not calculate a single average that hides a critical security or operational gap.

5. PHASE 3Matrixprotected

Migration Risk Register

A structured register of migration risks with probability, impact, mitigation, and owner.

Use this to

Record and rate each migration risk
Assign a mitigation and owner per risk
Track risks through the approval gates

Included with membership — $20/mo

Reference rows from the blueprint — downloads ship as an empty skeleton

Risk	Probability	Impact	Mitigation	Owner
Warehouse latency exceeds target	Medium	High	Network test and application benchmark	Network Architect
Database migration exceeds cutover window	High	High	Migration rehearsal and incremental replication	DBA
Cloud licensing rights are unavailable	Medium	High	Vendor contract review	Procurement
Identity claims differ from current application expectations	Medium	High	Identity proof of concept	Identity Team
Cloud cost exceeds estimate	Medium	Medium	Usage modeling and budget alerts	FinOps

🔒 The full execution layer — every checklist, matrix, and the prompt pack — is included with ABME membership.

Unlock Full Blueprint

Full Playbook

Overviewpublic

Cloud migration is not a single technical action. It is a portfolio of business, application, infrastructure, security, data, operational, financial, and organizational decisions.

A successful cloud migration begins by determining:

Why the organization is considering cloud adoption
Which business outcomes matter
Which workloads are suitable
Which workloads are not suitable
What constraints exist
What dependencies must move together
Which migration strategy fits each workload
What must be modernized before migration
What can be moved with minimal change
What risks require mitigation
Whether the organization can securely operate the target environment
How migration success will be measured

Organizations often begin cloud programs by selecting a cloud provider or moving the easiest servers first. This can create:

Higher costs
Unresolved security gaps
Poor application performance
Increased operational complexity
Fragile hybrid environments
Unexpected licensing costs
Failed migrations
New technical debt
Vendor lock-in
Incomplete disaster recovery
Confused ownership
Business disruption

This workflow uses AI to perform a structured cloud-readiness assessment and recommend an evidence-based migration strategy for each workload. The objective is not to move everything to the cloud. The objective is to determine the right disposition for each workload and create a practical migration roadmap aligned to business value, risk, cost, and organizational capability.

Business Problempublic

Cloud programs frequently struggle because organizations:

Start with technology instead of business outcomes
Treat all workloads the same
Assume cloud automatically reduces cost
Underestimate application dependencies
Ignore licensing constraints
Fail to assess data gravity
Move unsupported applications without remediation
Replicate on-premises architecture in the cloud
Do not establish landing-zone controls
Lack cloud security and operational skills
Ignore identity and network dependencies
Underestimate data-transfer cost
Fail to define migration waves
Lack rollback planning
Do not rationalize unused applications
Migrate technical debt without addressing it
Ignore regulatory and data-residency requirements
Select migration strategies based on preference rather than evidence

The result may be a technically completed migration that fails to deliver business value.

A cloud-readiness assessment creates the evidence needed to decide:

What should migrate
What should remain
What should be modernized
What should be replaced
What should be retired
In what order migration should occur
What capabilities must be established first

Typical Use Casespublic

Use this workflow when:

Beginning a cloud-adoption program
Assessing a data-center exit
Evaluating Azure, AWS, or Google Cloud
Building an application migration portfolio
Planning a hybrid-cloud strategy
Planning a multi-cloud strategy
Migrating after an acquisition
Consolidating infrastructure
Reducing end-of-life platform risk
Preparing a cloud business case
Prioritizing migration waves
Assessing cloud operating readiness
Reviewing application modernization opportunities
Identifying workloads that should remain on-premises
Evaluating SaaS replacement opportunities
Preparing for a regulatory review
Planning a major hosting-contract transition
Performing cloud technical due diligence
Reviewing a stalled cloud program
Reassessing workloads already moved to the cloud

Do NOT Use This Workflow Whenpublic

This workflow is not intended to:

Assume every workload belongs in the cloud
Guarantee cost savings
Select a cloud provider based only on popularity
Replace detailed application discovery
Replace a security architecture review
Replace a privacy or legal review
Replace a formal financial model
Replace performance testing
Replace licensing analysis
Replace detailed migration execution planning
Recommend multi-cloud without a clear business requirement
Treat rehosting as modernization
Ignore business-process dependencies
Ignore user experience and latency
Estimate infrastructure from CPU and memory alone
Recommend serverless, containers, or microservices without justification
Approve migration of unsupported or unidentified workloads
Move regulated data without validated controls
Rely on AI-generated inventory without human verification

The cloud is an operating model and a set of capabilities, not simply another data center.

Expected Outcomepublic

After completing this workflow, you should have:

Cloud-adoption objectives
Business outcome inventory
Current-state summary
Application and workload inventory
Dependency assessment
Data assessment
Security and compliance assessment
Operational maturity assessment
Skills and organizational readiness assessment
Financial considerations
Workload suitability ratings
Migration strategy recommendations
Workloads recommended to remain on-premises
Workloads recommended for replacement or retirement
Migration-wave recommendations
Landing-zone prerequisites
Risk register
Validation plan
Executive recommendation
Open questions and missing evidence

🔒 The complete playbook — reference models, worked examples, and operational guidance — is included with ABME membership.

Unlock Full Blueprint

Cloud Readiness Objectivesprotected

A complete cloud-readiness assessment should answer:

Why is the organization considering cloud adoption?
Which business outcomes are expected?
Which workloads are in scope?
Which workloads are business critical?
Which workloads are technically suitable?
Which workloads are constrained by latency, licensing, hardware, regulation, or dependencies?
Which applications should be retained, rehosted, replatformed, refactored, replaced, or retired?
What data must move?
What data should not move?
What connectivity is required?
What identity model is required?
What security controls must exist first?
What operating capabilities are missing?
What cloud skills are available?
What financial assumptions are valid?
What migration dependencies exist?
What should move first?
What should move together?
What must be tested before migration?
How will success be measured?
What is the rollback or exit strategy?

Adoption Drivers and Outcomesprotected

Cloud Adoption Drivers

Cloud adoption may be driven by:

Data-center exit
Hardware refresh avoidance
End-of-life infrastructure
Geographic expansion
Business agility
Faster provisioning
Improved resilience
Application modernization
Security improvement
Merger and acquisition
Cost transparency
Disaster recovery
Product innovation
Analytics and AI
Remote workforce support
Regulatory requirements
Sustainability objectives
Reduction of operational toil

The assessment should determine whether the stated driver is measurable and whether cloud adoption is the best response.

Cloud Adoption Outcomes

Examples of measurable outcomes include:

Reduce infrastructure provisioning from weeks to hours
Exit a data center before a contract expiration
Move critical workloads to supported platforms
Improve recovery-time objectives
Eliminate unsupported operating systems
Expand into a new region
Improve deployment frequency
Reduce manual infrastructure changes
Improve cost allocation
Establish consistent security controls
Increase capacity without major hardware purchases
Provide managed data and analytics capabilities

Weak outcome: Move to the cloud.

Stronger outcome: Migrate customer-facing applications from the current data center before the hosting contract expires while maintaining service availability, meeting data-residency requirements, and reducing manual infrastructure provisioning.

Assessment Scope

The assessment may include:

Applications
Databases
Servers
Virtual machines
Containers
File services
Identity systems
Network services
Security appliances
Batch jobs
Scheduled tasks
Integration middleware
Message queues
Data platforms
End-user computing
Backup systems
Disaster recovery
Monitoring platforms
Development environments
CI/CD systems
Commercial applications
Vendor-hosted systems
Shadow IT
Retired but still running systems

Workload Definition

A workload is a business or technical capability composed of one or more related components. A workload may include:

Application services
Database
File storage
Messaging
Identity dependencies
Network dependencies
Scheduled jobs
External integrations
Monitoring
Backup
Operational procedures

Avoid evaluating servers independently when they form one application dependency group.

Readiness Assessment Dimensionsprotected

Business Readiness

Assess:

Business owner
Business purpose
Criticality
User population
Revenue impact
Customer impact
Regulatory impact
Service expectations
Growth expectations
Planned retirement
Strategic fit

Application Readiness

Assess:

Architecture
Runtime
Framework
Operating system
Dependencies
Statefulness
Configuration
Deployment model
Scalability
Test coverage
Documentation
Support status
Technical debt
Vendor support
Hardware dependencies

Infrastructure Readiness

Assess:

Compute
Storage
Network
Load balancing
DNS
Certificates
Firewalls
Backup
Recovery
Monitoring
Capacity
Hardware dependencies
Virtualization
Configuration management

Data Readiness

Assess:

Data ownership
Classification
Volume
Growth
Latency requirements
Residency
Retention
Backup
Recovery
Encryption
Replication
Migration method
Data quality
Data gravity
Egress requirements

Security Readiness

Assess:

Identity
Authentication
Authorization
Privileged access
Network segmentation
Encryption
Key management
Secret management
Logging
Monitoring
Vulnerability management
Configuration standards
Incident response
Compliance controls
Tenant isolation
Third-party access

Operational Readiness

Assess:

Cloud operating model
Ownership
Support model
On-call capability
Monitoring
Incident management
Change management
Configuration management
Patch management
Backup and recovery
Cost management
Capacity management
Runbooks
Service management integration
Automation

Organizational Readiness

Assess:

Executive sponsorship
Product ownership
Architecture governance
Security governance
Platform team
Cloud skills
Training
Hiring needs
Vendor support
Procurement
Financial management
Change readiness
Decision authority

Financial Readiness

Assess:

Current infrastructure cost
Licensing
Support cost
Facility cost
Network cost
Backup cost
Disaster-recovery cost
Labor
Migration cost
Cloud consumption
Data transfer
Support plans
Managed services
Reserved capacity
Commitment discounts
Exit cost
Parallel-run cost
Decommissioning cost

Cloud Suitability Factorsprotected

A workload may be more suitable for cloud migration when it:

Has variable or growing demand
Requires rapid provisioning
Benefits from geographic reach
Uses supported platforms
Has clear ownership
Has documented dependencies
Can tolerate network latency
Can use managed services
Has automation potential
Has measurable business value
Requires improved resilience
Has predictable security requirements
Has a viable migration and rollback path

A workload may be less suitable when it:

Requires specialized physical hardware
Has extreme latency sensitivity
Has unsupported licensing terms
Is tightly coupled to on-premises equipment
Has unclear ownership
Is scheduled for retirement
Contains unidentified regulated data
Cannot tolerate migration downtime
Depends on systems that cannot move
Has no test or validation capability
Has high data-egress requirements
Is already inexpensive and stable
Has a vendor that prohibits cloud hosting

Lower suitability does not always mean “never migrate.” It may mean prerequisites are required.

Migration Strategy Modelprotected

Retain

Keep the workload in its current environment. Retain should include a review date and continued-support plan.

Migration provides limited value.
Constraints make migration impractical.
The application will remain supported.
Latency or hardware requirements favor the current environment.
Retirement is planned later.
Risk exceeds expected benefit.

Retire

Decommission the workload. Retirement often produces the highest immediate savings.

It is unused.
Its capability is duplicated.
The business process no longer exists.
The data can be archived.
The cost and risk exceed its value.

Rehost

Move the workload with minimal application changes. Also called lift and shift. Rehosting moves technical debt unless remediation is planned.

Time is limited.
Data-center exit is the primary driver.
The workload is supported in the target environment.
Modernization can occur later.
Operational risk is acceptable.

Relocate

Move a virtualization platform or environment with minimal workload-level change. Relocation may preserve existing operational patterns and limitations.

Existing virtualized workloads can move together.
A rapid facility exit is required.
The organization wants limited application change.

Replatform

Move the workload while making targeted platform changes. Use when targeted changes provide clear operational or resilience benefits.

Move a database to a managed database service.
Move an application to managed containers.
Replace a self-managed load balancer.
Use managed backup or monitoring.

Refactor

Change application structure to use cloud capabilities more effectively. Use when business value justifies engineering investment.

Remove local state
Externalize configuration
Introduce managed messaging
Improve horizontal scaling
Modernize authentication
Redesign persistence

Rearchitect

Make substantial architectural changes. Use only when requirements justify the complexity.

Decompose a monolith
Introduce event-driven workflows
Redesign for regional resilience
Separate data ownership
Create cloud-native service boundaries

Repurchase

Replace the application with a commercial product or SaaS platform.

The application is not differentiating.
A supported product meets requirements.
Custom maintenance is no longer justified.
Migration and process-change risks are acceptable.

Rebuild

Create a new implementation. Rebuild is not the default response to old or complex software.

Existing architecture cannot satisfy future requirements.
Business rules can be specified.
Migration can be validated.
Alternatives have been compared.
Organizational capacity exists.

Migration Strategy Decision Questionsprotected

For each workload ask:

Is the business capability still required?
Is the workload strategically differentiating?
Is the current platform supported?
Is the workload stable?
What is the cost of keeping it?
What is the value of moving it?
What dependencies exist?
Can it operate across a network boundary?
What data must move?
What compliance obligations apply?
What downtime is acceptable?
Can behavior be validated?
Can it be rolled back?
Can the team operate it in the cloud?
Is a SaaS replacement available?
Will migration reduce or increase technical debt?
Is the workload scheduled for retirement?

Cloud Readiness Ratingprotected

Ready

The workload is ready to migrate.

Business owner identified
Dependencies understood
Security requirements defined
Supported technology
Migration strategy established
Validation and rollback feasible
Landing-zone services available

Ready with Prerequisites

Migration is appropriate after specific blockers are resolved.

Upgrade runtime
Complete data classification
Establish private connectivity
Add regression tests
Resolve licensing
Implement identity integration

Requires Modernization

The workload requires material application or architecture change before or during migration.

Retain for Now

Migration value is limited or constraints remain unresolved.

Replace or Retire

The workload should not be migrated in its current form.

Unable to Assess

Evidence is insufficient.

Migration Complexity Ratingprotected

Low

Few components
Clear ownership
Limited dependencies
Supported platform
Low data volume
Simple validation
Limited downtime concern

Medium

Multiple dependencies
Moderate data migration
Some platform changes
Defined but nontrivial testing
Limited external integrations

High

Business-critical
Complex data
Many integrations
Strict downtime
Unsupported technology
High regulatory impact
Limited test coverage
Specialized infrastructure

Very High

Undocumented business rules
Unknown ownership
Large data gravity
Cross-system transactions
Irreversible migration
Severe compliance constraints
No practical rollback
Critical physical dependencies

Business Criticality Modelprotected

Mission Critical

Failure may cause material impact.

Material financial loss
Regulatory breach
Safety impact
Major customer disruption
Enterprise-wide outage

Business Critical

Failure materially affects important operations or customers.

Business Operational

Failure causes inconvenience or reduced productivity but has manageable workarounds.

Noncritical

Failure has limited immediate business impact.

Applying Criticalityprotected

Criticality should influence sequencing, testing, rollback, and support—not automatically prevent migration.

Dependency Assessmentprotected

Dependency Categories

Assess:

Application-to-application
Database
File shares
Identity
DNS
Certificates
Message queues
Batch processing
Scheduled jobs
APIs
Network routes
Firewalls
Hardware devices
Printers and scanners
Mainframe
SaaS
Vendor services
Monitoring
Backup
Administrative tools
User devices
Licensing services

Dependency Mapping

For each dependency capture:

Source workload
Target workload
Protocol
Port
Direction
Data exchanged
Frequency
Latency sensitivity
Authentication
Business importance
Failure behavior
Migration requirement
Owner
Validation method

A dependency map should reflect application behavior, not only network traffic.

Data Gravity

Data gravity describes how large or frequently used data sets influence where applications should run. Assess:

Data volume
Data growth
Number of consumers
Processing locality
Transfer frequency
Network bandwidth
Egress cost
Latency
Replication
Regulatory boundaries
Backup and recovery
Analytics use

Moving an application without its data may create unacceptable latency or cost.

Latency Assessment

Identify:

User locations
Application location
Database location
External services
Round-trip requirements
Synchronous call chains
Real-time control dependencies
Voice or video
Transaction deadlines
Batch windows

A workload that performs many sequential database calls may perform poorly across a hybrid network even when bandwidth is adequate.

Identity, Network, Security, and Foundation Readinessprotected

Identity Readiness

Assess:

User identities
Service identities
Device identities
Federation
Single sign-on
Multi-factor authentication
Privileged access
Role mapping
Conditional access
Legacy authentication
Directory synchronization
Break-glass access
Identity logging
Tenant design

Identity design should precede broad workload migration.

Network Readiness

Assess:

Address space
Routing
DNS
Connectivity
Bandwidth
Latency
Redundancy
Firewalls
Inspection
Segmentation
Proxy requirements
Private endpoints
Internet ingress
Internet egress
Remote access
Third-party connectivity
Monitoring

Common blockers include:

Overlapping IP ranges
Undocumented firewall rules
Fragile DNS
Single connectivity paths
Unmeasured bandwidth
Applications using hard-coded addresses

Security Readiness

Cloud migration should not proceed without clarity on:

Identity architecture
Administrative boundaries
Account, subscription, or project structure
Network segmentation
Encryption
Key management
Secret management
Logging
Vulnerability management
Configuration baselines
Incident response
Backup protection
Data classification
Security monitoring
Compliance evidence
Shared-responsibility ownership

Shared Responsibility

Cloud providers secure the underlying cloud infrastructure according to the service model. The customer remains responsible for areas such as:

Identity
Access
Configuration
Data
Application security
Workload security
Logging
Monitoring
Compliance
Backup decisions
Recovery testing
Cost control

The exact responsibility split varies by:

Infrastructure-as-a-Service
Platform-as-a-Service
Software-as-a-Service
Managed service
Provider
Contract
Configuration

“Hosted by the cloud provider” does not mean “fully secured by the provider.”

Landing-Zone Readiness

A landing zone is the governed foundation into which workloads are deployed. Assess whether the organization has defined:

Tenant or organization structure
Accounts, subscriptions, or projects
Management groups or folders
Identity integration
Administrative roles
Network topology
DNS
Logging
Monitoring
Security tooling
Policies
Resource naming
Tagging
Cost allocation
Backup
Recovery
Key management
Secret management
CI/CD
Infrastructure-as-Code
Exception process
Incident response

Migrating workloads before establishing foundational controls often creates rework.

Operating Model Readiness

The cloud operating model should define:

Platform ownership
Workload ownership
Security ownership
Network ownership
Identity ownership
Cost ownership
Backup ownership
Incident ownership
Patch ownership
Deployment ownership
Policy management
Exception management
Service support
Vendor management

Cloud adoption without ownership clarity often produces control gaps.

Skills Readiness

Assess capabilities in:

Cloud architecture
Cloud security
Identity
Networking
Infrastructure-as-Code
CI/CD
Containers
Data platforms
Observability
Cost management
Backup and recovery
Incident response
Automation
Governance
Vendor management

For each capability identify:

Existing skill
Required skill
Gap
Training plan
Hiring need
Partner support
Timeline

Financial Assessmentprotected

Financial Assessment

Cloud financial analysis should compare:

Current-State Cost

Hardware
Facilities
Power and cooling
Network
Licensing
Support
Backup
Disaster recovery
Operations labor
Security tools
Monitoring
Refresh cycles
Contracts

Migration Cost

Discovery
Architecture
Engineering
Data transfer
Testing
Parallel operations
Training
Consulting
Refactoring
Licensing changes
Decommissioning
Program management

Target-State Cost

Compute
Storage
Managed services
Data transfer
Internet egress
Private connectivity
Support plans
Monitoring
Security services
Backup
Disaster recovery
Licensing
Operations
FinOps tooling

Do not compare cloud consumption only to server hardware cost.

Cost Uncertainty

Use ranges where exact values are unavailable. Document:

Assumptions
Utilization
Growth
Region
Availability design
Licensing
Reservation or commitment assumptions
Data transfer
Backup retention
Logging volume
Support level
Currency
Tax treatment
Discount assumptions

Avoid false precision.

Cloud Economics Risks

Common cost risks include:

Oversized resources
Always-on nonproduction systems
Uncontrolled data transfer
Excessive logging
Orphaned storage
Unused snapshots
Premium service tiers
Duplicated security tools
Unplanned support charges
Unlicensed software
Cross-region traffic
Long parallel-run periods
Lack of tagging
Lack of ownership
Lack of budget alerts

Example Workload Inputprotected

Workload: Customer Order Management

Components

Two Windows application servers
SQL Server database
Shared file storage
Scheduled nightly processing
Active Directory authentication
Integration with warehouse and billing systems

Current State

Business critical
.NET Framework application
SQL Server Always On
Manual deployment
Limited automated testing
Data volume of approximately 4 TB
Warehouse system remains on-premises
Hosting contract expires in eighteen months

Example Assessment Summaryprotected

The Customer Order Management workload is a business-critical application with significant data and integration dependencies.

A direct rehost may satisfy the hosting deadline but would preserve:

Manual deployments
Legacy runtime constraints
Shared-file dependence
Limited regression testing
Tight integration with on-premises warehouse systems

A full rewrite would introduce excessive risk because:

Business rules are not fully documented.
Automated tests are limited.
The application is operationally critical.
The hosting deadline is shorter than a realistic rebuild timeline.

The preferred strategy is:

Stabilize and document the workload.
Add regression and characterization tests.
Establish private connectivity.
Replatform infrastructure with minimal application change.
Retain the database architecture initially.
Modernize file storage and deployment after migration.
Reassess application refactoring after operational stability is achieved.

Example Workload Dispositionprotected

CL-WL-001 — Customer Order Management

Business Criticality: Mission Critical
Recommended Disposition: Replatform
Readiness: Ready with Prerequisites
Migration Complexity: High
Confidence: Medium

Rationale: A targeted replatform balances the hosting deadline against the risks of a major application rewrite. The workload can move after connectivity, testing, licensing, identity, and data-migration requirements are validated.

Mandatory Prerequisites:

Confirm cloud-hosting rights for all software.
Validate private connectivity to the warehouse environment.
Establish cloud identity integration.
Add characterization tests for order processing.
Complete database migration rehearsal.
Define shared-file migration.
Establish logging and monitoring.
Define rollback and reconciliation.

Suggested Migration Wave: Wave 3

Rollback Approach:

Maintain the existing production environment during parallel validation.
Replicate data according to the approved migration method.
Use a controlled cutover window.
Preserve the ability to direct users and integrations back to the original environment.
Reconcile transactions created during the cutover period.

Success Criteria:

Order processing behavior matches the current system.
No unapproved data loss occurs.
Warehouse and billing integrations meet latency requirements.
Recovery objectives are met.
Monitoring and support ownership are active.
Deployment is repeatable.
Cost remains within the approved range.

Migration-Wave Modelprotected

Wave 0 — Foundation and Retirement

Establish the foundation and remove workloads that should not migrate.

Landing-zone controls
Connectivity
Identity
Logging
Cost allocation
Policies
Backup
Security operations
Workload retirement
Proofs of concept

Wave 1 — Low-Risk Learning Workloads

Characteristics: low or moderate criticality, few dependencies, supported platforms, clear ownership, low data volume, simple rollback. Purpose: validate migration factory, test governance, build team capability, improve estimates.

Low or moderate criticality
Few dependencies
Supported platforms
Clear ownership
Low data volume
Simple rollback

Wave 2 — Moderate Complexity

More dependencies
Moderate data
Business operational importance
Targeted replatforming
More advanced validation

Wave 3 — Business-Critical Workloads

High availability
Significant data
Strict recovery
Complex integrations
Formal cutover
Executive oversight

Wave 4 — Transformation Workloads

Refactoring
Rearchitecture
Major data modernization
Business-process change
Long program horizon

Sequencing Noteprotected

Migration waves should reflect dependencies and readiness, not arbitrary dates.

Migration Factory Readinessprotected

A migration factory is a repeatable process for moving workloads. Assess:

Discovery
Assessment
Architecture
Security review
Cost estimation
Build standards
Infrastructure automation
Data migration
Testing
Cutover
Rollback
Validation
Documentation
Handover
Decommissioning
Lessons learned

Validation Planningprotected

For each workload define:

Functional validation
Performance validation
Security validation
Integration validation
Data validation
Recovery validation
Monitoring validation
Cost validation
User acceptance
Operational handover
Rollback decision criteria

Proof-of-Concept Triggersprotected

When a Proof of Concept May Be Required

A proof of concept should answer a defined question with measurable success criteria.

Latency is uncertain.
A managed service capability is unclear.
Licensing is ambiguous.
Performance is unproven.
Data migration duration is unknown.
Hardware integration is uncertain.
Authentication integration is complex.
Regional availability is uncertain.
Recovery behavior is untested.
Cost depends on uncertain utilization.

Common Cloud Migration Blockersprotected

Missing application owner
Incomplete inventory
Unknown dependencies
Overlapping IP address space
Unsupported operating systems
Unsupported database versions
Licensing restrictions
No cloud identity design
No private connectivity
No rollback plan
No data classification
No test coverage
No recovery validation
Missing landing-zone controls
Undefined support model
No cost ownership
Hardware dependencies
Data residency
High egress
Unresolved security findings

Readiness Scoring Guidanceprotected

Scoring Scale

A score may use the following levels. Do not calculate a single average that hides a critical security or operational gap. A workload should not be considered production-ready merely because its overall score is high.

0 — Not assessed
1 — Not ready
2 — Major gaps
3 — Ready with prerequisites
4 — Ready
5 — Optimized

Migration Success Metricsprotected

Useful metrics include:

Workloads assessed
Workloads with confirmed owners
Applications retired
Unsupported systems remediated
Migration-wave completion
Cutover success
Rollback rate
Customer-impacting incidents
Recovery-objective achievement
Performance against baseline
Cost against approved range
Resources with valid tags
Policy compliance
Security findings
Deployment automation
Time to provision
Data-reconciliation errors
Decommissioning completion
Cloud skill development
User satisfaction

Governance Recommendationsprotected

Define:

Cloud-adoption principles
Provider selection authority
Landing-zone ownership
Account, subscription, or project standards
Identity standards
Network standards
Security baselines
Data requirements
Tagging standards
Cost ownership
Architecture review
Migration approval
Exception process
Workload ownership
Backup and recovery
Monitoring
Incident response
Decommissioning
Exit planning
AI-assisted assessment validation

Automation Opportunitiesprotected

Application portfolio discovery
CMDB enrichment
Dependency analysis
Cloud-readiness questionnaires
Workload scoring
Migration-strategy comparison
Wave planning
Landing-zone assessments
Cost-model preparation
Risk-register generation
Executive reporting
Migration-factory intake
Post-migration review
A mature workflow could: collect inventory from approved systems, group components into workloads, enrich lifecycle and ownership data, map dependencies, identify missing evidence, generate preliminary readiness ratings, compare workload dispositions, require owner validation, create migration waves, track prerequisites and approvals, measure migration outcomes, and update the portfolio after completion.

Pro Tipsprotected

Begin with business outcomes.
Assess workloads, not isolated servers.
Confirm ownership before migration planning.
Retire before migrating.
Compare all realistic workload dispositions.
Do not assume cloud saves money.
Establish the landing zone before production migration.
Map identity and network dependencies early.
Treat data gravity as a placement constraint.
Confirm licensing before committing to a strategy.
Separate facility exit from application modernization.
Use low-risk workloads to validate the migration process.
Move tightly coupled workloads together where practical.
Measure latency rather than guessing.
Rehearse data migration.
Define rollback before cutover.
Include decommissioning in the migration plan.
Establish cost ownership before consumption begins.
Plan the cloud operating model, not only the architecture.
Record assumptions and confidence.
Require human validation of AI-generated findings.

Common Mistakesprotected

Starting with provider selection — business outcomes and workload requirements should guide provider and service decisions.
Assuming cloud is cheaper — cloud may reduce some costs while increasing others.
Moving servers instead of workloads — applications, data, identity, network, and operations must be assessed together.
Migrating unused applications — retirement should be evaluated before migration.
Treating rehosting as modernization — rehosting may address a facility deadline while preserving technical debt.
Choosing the most transformative strategy — refactoring and rearchitecture should be justified by business outcomes.
Ignoring dependencies — a workload may technically migrate but fail because a critical dependency remains distant or unavailable.
Ignoring data gravity — large or frequently accessed data sets may determine workload placement.
Ignoring licensing — software that runs on-premises may have different cloud-hosting rights or costs.
Ignoring identity — legacy authentication can become a major blocker.
Migrating before the landing zone is ready — this creates inconsistent controls and rework.
Underestimating operations — cloud services still require ownership, monitoring, response, backup, and cost control.
Treating managed services as automatic improvements — they introduce new constraints, limits, costs, and migration requirements.
Selecting multi-cloud without a requirement — multi-cloud may increase complexity, skills needs, governance burden, and cost.
Using average utilization only — peak demand, resilience, backup, and growth must be considered.
Ignoring exit strategy — the organization should understand data export, contractual, technical, and financial exit constraints.
Migrating without decommissioning — parallel environments create cost, risk, and confusion.
Overlooking organizational readiness — a technically strong design can fail when teams lack ownership or skills.
Using false precision — early migration estimates should show assumptions and confidence.
Treating AI assessment as discovery evidence — AI can organize evidence but cannot confirm infrastructure, licensing, dependencies, or usage that has not been measured.

Security Considerationsprotected

Cloud-readiness assessments may contain sensitive information: internal architecture, IP addresses, network topology, trust boundaries, vulnerabilities, identity design, administrative access, data classifications, regulatory constraints, recovery weaknesses, vendor agreements, and infrastructure costs.
Before sharing information with an AI system: remove credentials.
Remove tokens.
Remove private keys.
Remove active connection strings.
Remove unnecessary IP addresses and hostnames.
Sanitize customer and employee information.
Follow data-classification requirements.
Follow vulnerability-handling procedures.
Confirm the AI platform is approved.
Confirm retention and training settings.
Restrict distribution of the assessment.
Do not treat an AI-generated readiness rating as formal authorization to migrate regulated or business-critical workloads.

Brian Diamond

Founder, BrianOnAI

Twenty-five years designing, operating, and governing enterprise infrastructure — from MSP operations across dozens of client environments to enterprise infrastructure leadership. This blueprint codifies the operating model he's implemented in production, not theory.

Related Blueprints

Perform an Application Architecture Review Identify and Prioritize Technical Debt Review a Technical Design Modernize a Legacy Application Build and Maintain Development Prompts Design a Secure Cloud Landing Zone Design Cloud Identity and Access Controls Design Cloud Network Architecture Estimate and Optimize Cloud Costs Plan and Execute a Cloud Workload Migration Design Cloud Backup and Disaster Recovery Review Cloud Security and Configuration

⚠ Normalization Warnings — 12 for review

RESTRUCTURE: 'Primary Prompt' and 'Follow-Up Prompts' (two source H1s, 14 follow-ups) combined into one prompt_pack tool with 15 prompts; 'when' guidance lines are editorial additions, prompt text verbatim.
CLASSIFICATION TO CONFIRM: 'Prerequisites' classified as a checklist TOOL (gather-before-start items are completable). Alternative: body/prose.
CLASSIFICATION TO CONFIRM: 'Workload Disposition Matrix' built as a matrix TOOL from the source table; example_rows are the doc's own rows verbatim. rubric left empty — no scoring scheme stated for this table.
CLASSIFICATION TO CONFIRM: 'Cloud Readiness Scorecard Example' built as a matrix TOOL named 'Cloud Readiness Scorecard'; rubric imported from the separate 'Readiness Scoring Guidance' section (0–5 scale). Confirm pairing.
CLASSIFICATION TO CONFIRM: 'Migration Risk Register' built as a matrix TOOL from the example table. Alternative: body/reference/example.
CLASSIFICATION TO CONFIRM: 'Workload Retirement Checklist' and 'Suggested Approval Gates' classified as checklist TOOLS (verifiable completion items). Approval gates could alternatively be body/reference.
CLASSIFICATION TO CONFIRM: 'Migration Strategy Model', 'Cloud Readiness Rating', 'Migration Complexity Rating', 'Business Criticality Model', 'Migration-Wave Model', 'Proof-of-Concept Triggers', and 'Readiness Scoring Guidance' all classified as body/reference (consulted taxonomies/models, not completed). 'Cloud Suitability Factors' and 'Migration Strategy Decision Questions' kept as body/prose — decision-support lists the reader consults but does not fill in.
GROUPING: many domain sections grouped thematically (Adoption Drivers and Outcomes; Readiness Assessment Dimensions; Dependency Assessment; Identity/Network/Security/Foundation Readiness; Financial Assessment) to avoid a flat 50+ section body. Section wording preserved verbatim within groups.
'Security Considerations' and 'Common Mistakes' mapped to playbook flat lists (prose-light, list-shaped in source) rather than body groups; some mistake entries combine the source H2 title with its one-line body for readability — confirm.
CL-001 has no standalone Quick Wins or Roadmap H1 sections; quick_wins and roadmap intentionally empty. A 'Quick Wins' follow-up PROMPT exists inside the prompt pack.
stats.deliverables counts the 8 tools; stats.prompts=15 counts primary + 14 follow-ups.
Example sections ('Example Workload Input', 'Example Assessment Summary', 'Example Workload Disposition') classified body/example and kept verbatim as prose (no code blocks present).

SEO Block

Title tag: Assess Cloud Readiness & Migration Strategy | ABME (50 chars)
Meta: Run a structured cloud-readiness assessment that assigns each workload a disposition — retain, retire, rehost, replatform, refactor, replace — with prerequisites. (162 chars)
Schema: HowTo · noindex: false
Related: ai-003, ai-007, ai-008, ai-009, ai-010, cl-002, cl-003, cl-004, cl-005, cl-006, cl-007, cl-008, cl-009, cl-010
Keywords: cloud readiness assessment, cloud migration strategy, 6 Rs cloud migration, workload disposition, rehost vs replatform, cloud migration waves, data gravity, landing zone readiness, cloud migration assessment, rehost replatform refactor retire

Copied

Decide Which Workloads Move, Stay, or Die — Before the Migration Bill Arrives

Executive Brief

Your Challenge

Common Obstacles

The ABME Approach

Insight Summary

The Journey

Define Drivers and Scope the Portfolio

Assess Readiness and Assign Dispositions

Sequence, Validate, and Govern

What's Inside the Execution Layer

Prerequisites Checklist

Cloud Readiness Prompt Pack

Primary Prompt

Assess a Single Application

Build a Workload Inventory

Identify Migration Dependencies

Assess Landing-Zone Readiness

Assess Cloud Security Readiness

Assess Network Readiness

Assess Identity Readiness

Assess Data Migration Readiness

Compare Cloud Migration Strategies

Create Migration Waves

Create a Cloud Business Case

Identify Quick Wins

Create a Cloud Readiness Scorecard

Workload Disposition Matrix

Cloud Readiness Scorecard

Migration Risk Register

Workload Retirement Checklist

Validation Checklist

Business

Inventory

Foundation

Workloads

Organization

Financial

Governance

Suggested Approval Gates

Gate 1 — Portfolio Entry

Gate 2 — Assessment Complete

Gate 3 — Migration Design Approved

Gate 4 — Production Readiness

Gate 5 — Migration Closure

Full Playbook

Overviewpublic

Business Problempublic

Typical Use Casespublic

Do NOT Use This Workflow Whenpublic

Expected Outcomepublic

Cloud Readiness Objectivesprotected

Adoption Drivers and Outcomesprotected

Cloud Adoption Drivers

Cloud Adoption Outcomes

Assessment Scope

Workload Definition

Readiness Assessment Dimensionsprotected

Business Readiness

Application Readiness

Infrastructure Readiness

Data Readiness

Security Readiness

Operational Readiness

Organizational Readiness

Financial Readiness

Cloud Suitability Factorsprotected

Migration Strategy Modelprotected

Retain

Retire

Rehost

Relocate

Replatform

Refactor

Rearchitect

Repurchase

Rebuild

Migration Strategy Decision Questionsprotected

Cloud Readiness Ratingprotected

Ready