Most cloud migration programs begin with an infrastructure scan. Azure Migrate discovers the VMs. AWS Application Discovery Service maps the servers. Google Migration Center inventories the workloads. Within days, the team has a spreadsheet of every server, its CPU utilization, its memory footprint, and an estimated cost to run the equivalent configuration in the target cloud. The infrastructure assessment is complete. Planning can begin.
Except it cannot. Because the infrastructure inventory tells you what hardware is running your applications, not whether those applications can run in the cloud, what it will cost to change them so they can, which ones have dependencies that will break on migration, which ones are written against deprecated APIs that the cloud platform does not support, or which ones contain ten years of undocumented business logic that will need to be understood before any conversion can be validated. Infrastructure discovery is a prerequisite for cloud migration assessment. It is not the assessment itself.
Assess Your Code Before You Move It
SMART TS XL maps every dependency, blocker, and refactoring candidate across your full application portfolio.
More InfoWhat Is a Cloud Migration Assessment?
A cloud migration assessment is the structured analysis that determines whether, how, and at what cost a set of workloads can move to the cloud. It produces the evidence base for three decisions: which migration strategy to apply to each workload, what the migration will actually cost in effort and cloud spend, and in what sequence workloads should migrate to manage dependency risk.
A complete cloud migration assessment spans five distinct dimensions. Infrastructure discovery tools address one of them. The other four require different tools, different techniques, and different expertise.
| Assessment Dimension | What It Answers | Primary Tools |
|---|---|---|
| Infrastructure | What servers, VMs, and services exist? What are their utilization profiles? | Azure Migrate, AWS Application Discovery, Google Migration Center |
| Application code | Is the code compatible with cloud targets? What needs to change? | CAST Highlight, SMART TS XL, CloudPilot, GitHub Copilot App Modernization |
| Data | What data volumes exist? Where does data reside? What are the migration complexity and compliance constraints? | AWS Database Migration Service, Azure Database Migration Service, Striim |
| Security and compliance | What regulatory requirements apply? What security gaps exist? What IAM and encryption changes are needed? | AWS Security Hub, Microsoft Defender for Cloud, Prisma Cloud |
| Cost and TCO | What is the full cost of migration and the total cost of ownership post-migration? | AWS Pricing Calculator, Azure TCO Calculator, Infracost, Apptio Cloudability |
Organizations that run only the infrastructure dimension produce migration plans with unknown scope. They discover the application, data, security, and cost surprises during migration, when the cost of addressing them is highest.
The Five Dimensions of Cloud Migration Assessment
Infrastructure Assessment
Infrastructure assessment is the starting point. It inventories the source environment: every server, VM, container, and service, with its configuration, utilization data, and dependency connections to other infrastructure components.
Tools like Azure Migrate or other products automate discovery of workload components and configurations. These tools reduce manual effort and provide consistent data collection across your environment, though they might miss undocumented dependencies.
Azure Migrate is the standard for organizations migrating to Azure. It performs agentless discovery of VMware vSphere, Hyper-V, and physical server environments, producing readiness assessments, performance-based right-sizing recommendations, and cost estimates before a single workload moves.
AWS Application Migration Service (MGN) and AWS Application Discovery Service serve the equivalent function for AWS targets. Discovery Service collects on-premises configuration and performance data through agentless collection or a locally installed agent.
Google Migration Center provides unified discovery and assessment for Google Cloud migrations, combining asset inventory, dependency analysis, and TCO modeling in a single console.
What infrastructure tools produce: server inventory, utilization baselines, network dependency maps between infrastructure components, and right-sizing recommendations for the target cloud tier. What they do not produce: any insight into whether the applications running on those servers are compatible with the cloud, what the code will cost to change, or how data within those applications will migrate.
Application Code Assessment
An application code assessment identifies compatibility issues and modernization opportunities that can affect migration success. This assessment is essential to ensure applications run reliably in Azure and to plan migration waves effectively. You must assess application code to detect blockers early, reduce the risk of migration failure, and inform target architecture decisions.
Application code assessment finds four categories of problem that infrastructure scanning cannot detect:
Compatibility blockers, APIs, frameworks, or runtime features that do not exist or behave differently in the target cloud environment. A Java application built against a Java EE application server that is not available in the target PaaS service needs code changes before it can be deployed. An application using a Windows-specific file path convention cannot run on a Linux-based cloud instance without modification.
Hardcoded infrastructure assumptions, IP addresses, file system paths, server names, or port numbers embedded in the code that will no longer be valid in the cloud environment. These are migration blockers that no infrastructure scan will find because they are inside the application code, not in the infrastructure configuration.
Deprecated API usage, calls to APIs, libraries, or platform features that the target cloud environment does not support or that have been superseded. Cloud platform providers regularly deprecate older API versions, and applications that use them will fail on the new platform even if they run correctly today.
Dependency complexity, the internal structure of the application, which determines how difficult it is to migrate and whether it can be broken into independently deployable services. A monolithic application with high internal coupling is harder and more expensive to migrate than a loosely coupled application, regardless of what the infrastructure inventory says.
CAST Highlight performs automated portfolio-level application code assessment, scanning source code across multiple languages to produce cloud readiness scores, blocker identification, and open-source risk analysis. It is referenced in Microsoft’s Azure Cloud Adoption Framework as a recommended tool for non-.NET and non-Java workloads.
CloudPilot specializes in detailed cloud readiness assessment with compatibility scoring and migration roadmap generation across JavaScript, Python, Node.js, and Go.
GitHub Copilot App Modernization combines CAST’s AppCAT assessment capabilities with AI-assisted code remediation for .NET and Java workloads specifically.
For enterprise environments that span COBOL, JCL, PL/I, RPG, and other mainframe languages alongside modern stacks, these tools have no coverage. Application code assessment for legacy systems requires a different category of tool entirely.
Data Assessment
Data assessment determines the complexity, volume, compliance requirements, and migration method for every data store in scope. It is frequently underestimated because it appears straightforward, move the database, move the data, until the actual complexity emerges.
The key questions data assessment must answer:
Volume and throughput: How much data exists? What is the rate of change? Can it be migrated with downtime, or must it use continuous replication to achieve near-zero downtime cutover?
Schema compatibility: Does the target database service support the same schema features, data types, and stored procedures as the source? Oracle-specific PL/SQL constructs require conversion before migrating to PostgreSQL or a cloud-native alternative.
Data sovereignty and compliance: Where is the data legally required to reside? GDPR, HIPAA, PCI-DSS, and sector-specific regulations may restrict which cloud regions can host specific data categories.
Application coupling: How tightly is the application code coupled to the specific database schema? A schema change that is technically simple may require extensive application code changes to accommodate.
AWS Database Migration Service and Azure Database Migration Service support continuous replication with minimal downtime for homogeneous migrations (Oracle to Oracle, SQL Server to SQL Server) and schema conversion for heterogeneous migrations (Oracle to PostgreSQL, SQL Server to Aurora).
Striim and Attunity provide real-time data streaming and replication for high-availability migration scenarios where database downtime is unacceptable.
Security and Compliance Assessment
Security assessment maps the current security posture of each workload and identifies the changes required to meet cloud security standards, compliance frameworks, and zero-trust architecture principles.
The dimensions security assessment must cover:
Identity and access management (IAM): On-premises applications often use service accounts with broad permissions and password-based authentication. Cloud environments require role-based access control, least-privilege service identities, and certificate or token-based authentication. The gap between current and required IAM is a migration effort that has nothing to do with the infrastructure inventory.
Encryption: Data at rest and in transit encryption requirements differ between on-premises and cloud environments. Applications that manage their own encryption at the application layer need to integrate with cloud key management services. Unencrypted data stores that are acceptable on private networks require encryption before moving to cloud-hosted services.
Network security: Firewall rules, network segmentation, and traffic inspection that were implemented in on-premises network hardware must be reconstructed as cloud security groups, virtual network configurations, and cloud-native firewall rules.
Compliance framework alignment: Each regulated industry has specific compliance requirements that map to specific cloud configurations. HIPAA workloads require specific configuration choices across storage, access logging, and encryption. PCI-DSS requires network segmentation that must be implemented differently in a cloud VPC than in physical network infrastructure.
Microsoft Defender for Cloud provides security posture assessment and compliance evaluation against CIS benchmarks, NIST, PCI-DSS, and other frameworks for Azure workloads.
Prisma Cloud (Palo Alto Networks) and AWS Security Hub provide equivalent multi-cloud security assessment and compliance monitoring.
Cost and TCO Assessment
Cost assessment is the most visible migration deliverable for business stakeholders and the one most frequently produced incorrectly. The common error is comparing current on-premises hardware costs against cloud compute and storage costs, which produces an incomplete and usually misleading comparison.
A complete TCO assessment includes:
Cloud infrastructure costs: Compute, storage, networking, and managed service costs in the target cloud configuration. Right-sizing based on actual utilization data (not provisioned capacity) is the difference between accurate and inflated estimates.
Migration effort costs: The engineering hours required to complete the application code changes, data migration, security reconfiguration, and testing. Infrastructure-only assessments systematically underestimate this because they have no visibility into application complexity.
Licensing changes: Moving from perpetual on-premises licenses to cloud-based licensing models, or from vendor-specific software to cloud-native alternatives, changes the licensing cost structure fundamentally.
Operational model changes: On-premises operations teams managing physical hardware are replaced by cloud operations teams managing cloud services. The skills, tooling, and headcount change.
Training and transition costs: Teams learning new cloud platforms, new deployment models, and new operational procedures incur productivity costs during the transition.
AWS Pricing Calculator, Azure TCO Calculator, and Google Cloud Pricing Calculator address the cloud infrastructure cost dimension. Infracost provides cost estimation integrated into IaC pipelines, producing cost estimates as part of the CI/CD process. Apptio Cloudability and similar FinOps tools provide ongoing cost visibility post-migration.
The Seven Migration Strategies: How Assessment Determines Which Applies
The “7 Rs” framework describes the strategies available for each workload migration. Assessment determines which strategy is appropriate, and getting the assessment wrong means applying the wrong strategy, which is the root cause of most migration cost overruns.
| Strategy | What It Means | Assessment Signal That Suggests It |
|---|---|---|
| Rehost (lift-and-shift) | Move to cloud with no code changes | Low application complexity, no compatibility blockers, infrastructure-compatible |
| Replatform | Minor changes to leverage cloud services (e.g., move to managed database) | Moderate coupling, specific platform upgrade opportunity, acceptable code change scope |
| Refactor | Rearchitect for cloud-native patterns (microservices, containers) | High monolith coupling, significant scalability requirements, justified by expected traffic growth |
| Rearchitect | Significant redesign of the application architecture | Application fundamentally incompatible with cloud; new architecture provides major business benefit |
| Rebuild | Rewrite from scratch | Application is beyond economic repair; replacement is cheaper than remediation |
| Replace | Retire the custom application, adopt a SaaS alternative | Application provides commodity functionality better served by an existing cloud service |
| Retire | Decommission, the application is no longer needed | Application identified as dead, redundant, or superseded during assessment |
The infrastructure inventory cannot distinguish between Rehost, Replatform, Refactor, and Rebuild candidates, all of them look identical at the infrastructure layer. Application code assessment is what makes this distinction.
Cloud Migration Assessment for Legacy and Mainframe Systems
Standard cloud migration assessment tools are designed for modern infrastructure: virtual machines, containers, microservices, and cloud-native applications. They perform poorly or not at all for mainframe workloads, COBOL programs running on IBM z/OS, JCL job streams managing batch processing, PL/I applications handling financial transactions, and RPG programs embedded in AS/400 systems.
Mainframe cloud migration assessment requires a fundamentally different approach because the infrastructure layer is not the constraint. The constraint is the application code, decades of accumulated business logic, implicit dependencies through shared datasets and copybooks, and runtime behaviors that no infrastructure scan can reveal.
The eight analyses required before any mainframe migration can be responsibly planned, program inventory, dependency mapping, business logic extraction, dead code identification, complexity classification, batch scheduling analysis, data quality assessment, and integration mapping, are described in detail in the context of mainframe migration de-risking. Each of these is a code-level assessment activity, not an infrastructure assessment activity.
Cloud Migration Assessment Tools Comparison
The table below maps the major cloud migration assessment tools to the assessment dimension they address and their best-fit scenario.
| Tool | Assessment Layer | Cloud Target | Best For |
|---|---|---|---|
| Azure Migrate | Infrastructure | Azure | VM and server discovery, right-sizing, Azure cost estimation |
| AWS Application Discovery Service | Infrastructure | AWS | On-premises server discovery for AWS migrations |
| Google Migration Center | Infrastructure | GCP | Asset inventory and TCO for GCP migrations |
| CAST Highlight | Application code | Multi-cloud | Portfolio-scale code readiness scoring across languages |
| CloudPilot | Application code | Multi-cloud | Detailed compatibility analysis for Python, JS, Node.js, Go |
| SMART TS XL | Application code + dependency mapping | Multi-cloud | COBOL, JCL, mainframe, and multi-language portfolio analysis |
| AWS DMS | Data | AWS | Database migration with schema conversion |
| Azure Database Migration Service | Data | Azure | SQL Server, MySQL, PostgreSQL migration to Azure |
| Striim | Data | Multi-cloud | Real-time replication for zero-downtime data migration |
| Microsoft Defender for Cloud | Security | Azure / Multi-cloud | Security posture and compliance assessment |
| Prisma Cloud | Security | Multi-cloud | CSPM and compliance across AWS, Azure, GCP |
| Infracost | Cost | Multi-cloud | IaC-integrated cost estimation in CI/CD pipelines |
| Apptio Cloudability | Cost | Multi-cloud | FinOps and ongoing cloud cost management |
| Corent SurPaaS | Infrastructure + application | Multi-cloud | AI-driven discovery, assessment, and migration orchestration |
How SMART TS XL Performs Application Code Assessment for Cloud Migration
SMART TS XL addresses the application code assessment layer that infrastructure tools cannot reach, specifically for enterprise and legacy environments where the application portfolio spans multiple languages, platforms, and technology generations.
For a migration program that includes COBOL programs, JCL job streams, Java services, Python pipelines, and SQL schemas, SMART TS XL builds a unified dependency model across all of them simultaneously. Before the migration team decides what to rehost, what to refactor, and what to retire, SMART TS XL provides:
Complete program inventory: Every source program, copybook, procedure, and schema across every language in the environment, the actual inventory, not the documented one, which in legacy environments typically diverges by 20-30%.
Cross-language dependency mapping: The application dependency mapping capability traces how a COBOL program connects to a DB2 schema that a Java service queries, which feeds a Python pipeline that produces output consumed by a modern React frontend. This cross-language dependency chain determines migration sequencing, components with many dependents must migrate after their dependents are ready.
Dead code identification: Programs and procedures that are never called by any production execution path can be excluded from migration scope entirely. In large legacy environments this typically represents 10-25% of the total inventory, significant cost reduction achieved at the assessment stage.
Complexity classification: The static code analysis capability classifies each program by cyclomatic complexity, copybook dependency count, called-by count, and other metrics that determine migration difficulty. High-complexity programs with many callers are Refactor or Rebuild candidates. Low-complexity, low-dependency programs are Rehost candidates.
Impact analysis before any change: The impact analysis capability answers “what will be affected if this program changes?” before any migration activity begins, converting unknown risk into a structured, enumerated scope.
For organizations planning mainframe-to-cloud migration programs, SMART TS XL’s legacy modernization analysis produces the pre-migration assessment that migration vendors require before conversion work begins: complete structural inventory, dependency graph, complexity classification, and dead code exclusion report.
What a Complete Cloud Migration Assessment Should Produce
An assessment is only as valuable as the decisions it enables. A complete cloud migration assessment should produce five deliverables that together define the migration program:
Application portfolio inventory with migration strategy assignment: Every application in scope classified as Rehost, Replatform, Refactor, Rearchitect, Rebuild, Replace, or Retire, with the assessment evidence that supports each classification.
Dependency-based migration wave plan: The sequence in which applications should migrate, derived from the dependency graph rather than from arbitrary groupings. Applications with no inbound dependencies from other in-scope applications can migrate in early waves. Applications that many others depend on migrate in later waves after their dependents are ready.
Total cost of migration estimate: Engineering effort, migration tooling costs, temporary parallel-run costs, and training costs, not just infrastructure cost differentials.
Post-migration TCO model: Projected cloud spend based on right-sized configurations and actual utilization data, compared against current on-premises operational costs, with realistic assumptions about licensing changes and operational model transitions.
Risk register: The identified risks, compatibility blockers, complex data migrations, undocumented dependencies, compliance constraints, with their probability, impact, and proposed mitigation for each.
Organizations that produce all five of these deliverables before migration begins have the information they need to make the program succeed. Organizations that skip application code assessment, data assessment, or security assessment produce incomplete versions of these deliverables, and discover the missing pieces during migration, when every discovery costs more to address.
