Auditing Terraform for Cloud Lock-In Before Migrating to a European Provider

Engineers planning a move off a hyperscaler can scan their Terraform files and state to find lock-in before migrating. Resources should be sorted into three tiers: standard portable components such as VMs, PostgreSQL, and S3-compatible storage; managed services needing config changes; and proprietary services like DynamoDB or BigQuery that force application code rewrites. The audit should also cover application dependencies, since a resource only creates real lock-in when code calls its proprietary SDK directly rather than a standard protocol. The article notes that Terraform standardizes provisioning syntax but does not make infrastructure portable, because each provider uses distinct resource names and APIs. Teams are advised to run scanners in CI/CD pull requests to prevent new proprietary dependencies while planning the migration.