Most cloud migrations do not fail during execution. They fail during assessment. Incomplete discovery, overlooked dependencies, and inaccurate cost projections create problems that compound once workloads start moving. After assessing more than 300 production workloads across industries, we built a repeatable framework that catches these issues before they become expensive mistakes.
This guide walks through the assessment framework we use at Tasrie IT Services, covering every phase from initial discovery to migration wave planning. Whether you are migrating a handful of applications or an entire data center, this framework scales to fit.
Why a Structured Assessment Framework Matters
Organizations that skip or rush the assessment phase experience 2-3x more migration failures, cost overruns, and unplanned downtime. A structured framework delivers three critical outcomes:
- Accurate scope definition — You know exactly what is moving, what stays, and what gets retired.
- Realistic cost projections — TCO models built on actual utilization data rather than vendor list prices.
- Risk visibility — Dependencies, compliance requirements, and technical blockers are surfaced before they cause production incidents.
Our framework breaks the assessment into seven distinct phases, each with defined inputs, outputs, and decision gates. If you need a broader migration planning reference, our enterprise cloud migration checklist covers 50+ items across the full migration lifecycle.
Phase 1: Discovery and Inventory
Discovery is the foundation of every migration assessment. Without a complete, accurate inventory, every downstream decision is built on assumptions.
Automated Discovery
Manual inventory spreadsheets are unreliable at scale. We deploy automated discovery tools that scan your environment and capture:
- Compute resources — Physical servers, virtual machines, containers, and serverless functions with CPU, memory, and storage specifications.
- Network topology — VLANs, subnets, firewall rules, load balancers, DNS configurations, and VPN tunnels.
- Storage systems — SAN, NAS, object storage, block storage with capacity utilization and IOPS metrics.
- Databases — Engine types, versions, sizes, replication configurations, and query patterns.
- Middleware and runtime — Application servers, message queues, caching layers, and service buses.
Discovery Tools We Use
Each cloud provider offers native discovery tooling:
- AWS Application Discovery Service collects configuration data, usage data, and behavior data from your servers to help plan migrations.
- Azure Migrate provides an integrated hub for discovering, assessing, and migrating on-premises servers, databases, and applications.
- Google Cloud Migration Center offers unified discovery and assessment across your existing infrastructure.
For multi-cloud or vendor-neutral assessments, we supplement with tools like Cloudamize and Device42, which provide cross-platform dependency and utilization data without locking you into a single provider.
What Good Discovery Looks Like
A complete discovery produces a Configuration Management Database (CMDB) that accounts for every asset in scope. We validate completeness by cross-referencing discovery data against network flow logs, DNS records, and Active Directory or LDAP entries. If the discovery tool found 480 servers but DNS shows 510 hostnames, that gap needs investigation before proceeding.
Phase 2: Application Dependency Mapping
Dependency mapping is where most assessment efforts fail. Moving a web server to the cloud without its database, or migrating a database without accounting for the five services that query it, causes outages.
Why Dependencies Break Migrations
Consider a typical three-tier application: a web frontend, an API layer, and a database. The discovery phase identifies all three. But dependency mapping reveals the API layer also calls an on-premises LDAP server for authentication, sends events to a Kafka cluster shared by four other applications, and writes logs to a centralized Splunk instance. Missing any of these connections means the migrated application either fails or performs poorly.
Mapping Techniques
We use a combination of approaches to build a complete dependency picture:
- Network traffic analysis — Passive monitoring of actual network flows between systems over a 2-4 week period captures runtime dependencies that documentation misses.
- Agent-based monitoring — Lightweight agents deployed on servers track process-level communications, file access patterns, and inter-service calls.
- Agentless discovery — API-based scanning using protocols like WMI, SSH, and SNMP gathers dependency data without installing software on production systems.
- Application team interviews — Automated tools catch 80-90% of dependencies. The remaining 10-20% come from conversations with the teams who build and operate these systems daily.
Building the Dependency Map
The output is a visual dependency graph showing every application and its upstream and downstream connections. We classify dependencies into three categories:
- Hard dependencies — The application cannot function without this connection (e.g., app-to-database).
- Soft dependencies — The application degrades but continues operating (e.g., optional caching layer).
- External dependencies — Connections to third-party services, SaaS platforms, or partner APIs that cannot be migrated.
This classification directly feeds into migration wave planning later in the process.
Phase 3: 6Rs Classification
Every application in the portfolio needs a migration strategy. The 6Rs cloud migration framework provides six options, and selecting the right one for each workload is one of the most consequential decisions in the assessment.
The Six Strategies
- Rehost (Lift and Shift) — Move the application as-is to cloud infrastructure. Fastest path with lowest risk but captures the fewest cloud-native benefits.
- Replatform (Lift, Tinker, and Shift) — Make targeted optimizations during migration, such as moving from a self-managed database to a managed service like Amazon RDS or Azure SQL Database.
- Refactor (Re-architect) — Redesign the application to leverage cloud-native services like containers, serverless, or managed Kubernetes. Highest effort but greatest long-term benefit.
- Repurchase — Replace the existing application with a SaaS equivalent. Common for CRM, ITSM, and HR systems.
- Retire — Decommission the application entirely. Our assessments typically identify 10-20% of workloads that can be retired.
- Retain — Keep the application on-premises, at least temporarily. Applies to systems with regulatory constraints, hardware dependencies, or nearing end-of-life.
How We Classify Workloads
Classification is not a purely technical decision. We score each workload across five dimensions:
| Dimension | What We Evaluate |
|---|---|
| Technical complexity | Architecture, code language, framework maturity, OS dependencies |
| Business criticality | Revenue impact, user count, SLA requirements |
| Data sensitivity | PII, PHI, financial data, regulatory classification |
| Cloud readiness | Statelessness, 12-factor compliance, containerization potential |
| Organizational readiness | Team skills, operational maturity, change tolerance |
Each dimension receives a score from 1 to 5. The composite score, combined with business priorities, drives the 6R recommendation. For example, a legacy .NET application with high business criticality but low cloud readiness might be rehosted first and refactored in a later phase.
For teams running Kubernetes workloads, our EKS consulting and AKS consulting services help evaluate whether containerized applications should be rehosted to managed Kubernetes or refactored to take advantage of cloud-native orchestration features.
Phase 4: TCO and ROI Analysis
A migration that costs more than it saves is not a successful migration. TCO analysis ensures the business case is grounded in real numbers, not vendor marketing.
Components of Cloud TCO
We calculate TCO across five categories:
1. Compute costs Based on actual utilization data from discovery, not peak provisioned capacity. Most on-premises servers run at 10-20% average utilization, which means right-sizing to cloud instances can reduce compute costs significantly.
2. Storage costs Tiered by access pattern: frequently accessed data on standard storage, infrequently accessed on lower-cost tiers, and archival data on cold storage classes like S3 Glacier or Azure Archive Storage.
3. Network and data transfer Egress charges are one of the most commonly underestimated costs. We model data transfer between cloud regions, to the internet, and back to on-premises systems for hybrid architectures.
4. Licensing Windows Server, SQL Server, Oracle, and other commercial software licensing changes significantly in the cloud. We evaluate Bring Your Own License (BYOL), cloud-included licensing, and SaaS alternatives for each workload.
5. Operational costs Staff training, managed service fees, monitoring tools, and the operational overhead of running cloud infrastructure. These indirect costs are often 20-30% of the total.
TCO Tools
We combine native provider calculators with independent analysis:
- AWS Migration Evaluator provides a free, data-driven business case based on your actual on-premises usage patterns.
- Azure TCO Calculator estimates cost savings by comparing current infrastructure costs against Azure pricing.
- Cloudamize offers vendor-neutral TCO modeling across AWS, Azure, and GCP simultaneously, which is valuable for organizations evaluating multiple providers.
Building a Three-Year Financial Model
A single-year TCO comparison is misleading. Cloud costs tend to decrease over time as teams optimize, adopt reserved instances, and leverage managed services. On-premises costs tend to increase as hardware ages, licenses renew, and maintenance contracts escalate.
We build three-to-five-year models that account for:
- Migration execution costs (one-time)
- Year-one cloud costs at initial sizing
- Year-two costs after right-sizing and optimization
- Year-three costs with reserved capacity and mature FinOps practices
- Avoided on-premises costs (hardware refresh, facility, power, cooling)
This multi-year view consistently shows a 30-50% TCO reduction for well-planned migrations, though the exact number depends heavily on workload characteristics and current infrastructure age.
Phase 5: Risk Assessment
Every migration carries risk. The goal of risk assessment is not to eliminate risk but to identify, quantify, and mitigate it before it materializes.
Risk Categories
We evaluate risk across six categories:
Technical risk — Application compatibility issues, unsupported OS versions, proprietary hardware dependencies, and performance requirements that cloud instances may not meet.
Data risk — Data loss during migration, corruption during transformation, and extended periods where data is split between on-premises and cloud systems.
Security risk — Expanded attack surface during migration, temporary firewall openings, credential management across hybrid environments, and encryption gaps during data transfer.
Operational risk — Team skill gaps, insufficient monitoring during cutover, unclear rollback procedures, and inadequate testing environments.
Business risk — Extended downtime during cutover windows, degraded performance affecting customer experience, and missed SLA commitments.
Vendor risk — Provider lock-in, service availability gaps in target regions, and dependency on services that may change pricing or functionality.
Risk Scoring Matrix
Each identified risk receives a likelihood score (1-5) and an impact score (1-5). The product gives a risk priority number:
| Risk Level | Score Range | Action Required |
|---|---|---|
| Critical | 16-25 | Must be mitigated before migration proceeds |
| High | 10-15 | Mitigation plan required with defined owner |
| Medium | 5-9 | Accepted with monitoring plan |
| Low | 1-4 | Documented and accepted |
Critical and high risks generate specific mitigation tasks that become prerequisites in the migration plan. For example, if a legacy application uses TLS 1.0 and the target cloud environment requires TLS 1.2, the remediation must happen before migration, not after.
Phase 6: Compliance and Regulatory Evaluation
Compliance requirements constrain migration options in ways that technical assessments alone do not capture. A workload that is technically easy to rehost may be impossible to move if data residency laws prohibit cross-border transfer.
Regulatory Frameworks We Evaluate
- GDPR — Data residency, right to erasure, data processing agreements with cloud providers.
- HIPAA — Business Associate Agreements (BAAs), PHI encryption requirements, audit logging.
- PCI DSS — Cardholder data environment segmentation, encryption in transit and at rest, access controls.
- SOC 2 — Security, availability, processing integrity, confidentiality, and privacy controls.
- ISO 27001 — Information security management system requirements and cloud-specific controls.
- Industry-specific regulations — FCA (financial services), FDA 21 CFR Part 11 (life sciences), ITAR (defense).
Compliance Assessment Process
For each workload, we document:
- Data classification — What types of regulated data does this workload process or store?
- Jurisdictional requirements — Where must this data reside? Are there cross-border transfer restrictions?
- Provider certifications — Does the target cloud provider hold the required certifications for this workload’s region and industry?
- Shared responsibility gaps — Where does the provider’s compliance responsibility end and yours begin?
- Audit trail requirements — What logging, monitoring, and reporting capabilities must be in place from day one?
Compliance evaluation frequently changes a workload’s 6R classification. A workload initially tagged for rehosting to a public cloud region may need to move to a sovereign cloud or remain on-premises if regulatory requirements cannot be met.
For organizations with strict security requirements, integrating infrastructure as code practices through Terraform consulting ensures compliance policies are codified, version-controlled, and automatically enforced across cloud environments.
Phase 7: Migration Wave Planning
Wave planning translates the assessment into an actionable migration sequence. The goal is to group workloads into waves that minimize risk, respect dependencies, and deliver business value incrementally.
Wave Design Principles
Wave 0 — Foundation Before any workloads move, the cloud landing zone must be in place: networking, identity, security baselines, monitoring, and governance controls. This is infrastructure, not application migration.
Wave 1 — Low Risk, High Learning Start with workloads that have minimal dependencies, low business criticality, and straightforward architectures. The primary goal is building team confidence and validating the migration process.
Wave 2 — Business Value Migrate workloads that deliver measurable business benefits: cost savings, performance improvements, or new capabilities. These are typically rehost or replatform candidates with moderate complexity.
Wave 3 — Complex Workloads Applications with extensive dependencies, high data volumes, or tight SLA requirements. These benefit from the lessons learned in earlier waves.
Wave 4 — Transformation Refactor candidates and applications requiring significant re-architecture. By this point, the team has deep cloud expertise and established patterns to draw from.
Dependency-Driven Grouping
Within each wave, workloads are grouped based on the dependency maps from Phase 2. The rule is simple: if Application A depends on Application B, they must move in the same wave or Application B must move first. Breaking this rule is the single most common cause of migration-related outages.
Wave Sizing and Scheduling
Each wave has a defined scope, timeline, and success criteria:
- Workload count — We recommend 5-15 workloads per wave, depending on team capacity and complexity.
- Duration — 2-6 weeks per wave, including testing and validation.
- Rollback window — Every wave includes a defined rollback period where reverting to on-premises is still possible.
- Success gates — Performance benchmarks, security scans, and compliance checks that must pass before the next wave begins.
Assessment Tooling Comparison
Choosing the right assessment tools depends on your target cloud provider and assessment scope. Here is how the major options compare:
| Tool | Provider | Best For | Key Strength |
|---|---|---|---|
| AWS Migration Evaluator | AWS | AWS-targeted migrations | Free, data-driven business case with AWS pricing |
| Azure Migrate | Microsoft | Azure-targeted migrations | Integrated discovery, assessment, and migration |
| Google Cloud Migration Center | GCP-targeted migrations | Unified assessment with StratoZone integration | |
| Cloudamize | Independent | Multi-cloud assessment | Vendor-neutral TCO across AWS, Azure, and GCP |
| Device42 | Independent | Dependency mapping | Deep application dependency visualization |
| CAST Highlight | Independent | Application portfolio analysis | Code-level cloud readiness scoring |
For most enterprise migrations, we use a combination: a cloud-native tool for the target provider’s specific pricing and sizing, plus an independent tool for dependency mapping and cross-platform comparison.
Common Assessment Mistakes
After running hundreds of assessments, these are the patterns that consistently cause problems:
Relying on manual inventory. Spreadsheet-based inventories miss 15-30% of infrastructure. Always validate with automated discovery.
Ignoring network dependencies. An application may function perfectly in isolation but fail when its network latency to a dependent service increases from 1ms (on-premises) to 50ms (cross-region).
Underestimating data transfer costs. Egress charges add up quickly for data-intensive workloads. Model these costs explicitly.
Skipping the compliance review. Discovering a data residency requirement after migration has started is far more expensive than discovering it during assessment.
Assessing in isolation. Technical assessment without business context produces technically correct but strategically wrong migration plans. Always include business stakeholders.
One-size-fits-all classification. Not every workload should be rehosted, and not every workload needs refactoring. The 6Rs exist because different applications need different approaches.
Making the Assessment Actionable
A thorough assessment produces a detailed migration blueprint that includes:
- Complete application inventory with dependency maps
- 6R classification for every in-scope workload
- Three-to-five-year TCO model with sensitivity analysis
- Risk register with mitigation plans for critical and high risks
- Compliance matrix mapping workloads to regulatory requirements
- Wave plan with timelines, resource requirements, and success criteria
This blueprint becomes the single source of truth for the entire migration program. It aligns technical teams, business stakeholders, and leadership around a shared plan with clear milestones and measurable outcomes.
For a step-by-step operational guide that picks up where this assessment framework ends, see our detailed cloud migration services page, which covers execution, optimization, and ongoing management.
Build Your Cloud Migration Assessment with Tasrie IT Services
A migration assessment built on assumptions leads to cost overruns, missed timelines, and production incidents. A migration assessment built on data leads to predictable outcomes.
Our team at Tasrie IT Services provides comprehensive cloud migration assessment services that cover every phase outlined in this guide:
- Complete workload discovery and dependency mapping across hybrid and multi-cloud environments
- Data-driven 6Rs classification with business context and technical depth for every application
- Realistic TCO modeling using actual utilization data, not vendor estimates
- Compliance-first planning that ensures regulatory requirements are met from day one
- Actionable wave plans with clear timelines, risk mitigation, and success criteria
We have assessed more than 300 production workloads across financial services, healthcare, e-commerce, and technology organizations, delivering migration blueprints that teams can execute with confidence.
Start your cloud migration assessment with Tasrie IT Services