G2

Mallairaj A.

Principal architect

Small-Business (50 or fewer emp.)

10/13/2026

Business partner of the seller or seller's competitor, not included in G2 scores.

"Multi-Cloud Power Meets Persistent State and Licensing Friction"

5/5

What do you like best about IBM Terraform (formerly HashiCorp Terraform)?

The multi-cloud, provider-agnostic model combined with the plan/apply workflow. What stands out most about Terraform (now under IBM after the HashiCorp acquisition closed in February 2025) is that it lets you describe infrastructure declaratively once and drive it consistently across AWS, Azure, Google Cloud, on-prem, IBM Cloud, SaaS services, and a huge range of other providers through the same workflow and language (HCL). You write the desired end state. Terraform builds a dependency graph, produces a clear plan of exactly what will be created, changed, or destroyed, and only then applies it. That preview-before-mutation step, plus solid state tracking, is still one of the cleanest ways to manage real infrastructure changes without surprises. The large ecosystem of official, partner, and community providers and modules amplifies this: you’re rarely starting from zero. It’s not perfect (state management has always required care, the BSL licensing shift and IBM ownership have prompted some community forks like OpenTofu, and it’s stronger at provisioning than ongoing configuration management), but the core idea of one consistent, reviewable, multi-provider IaC workflow remains its strongest feature. Review collected by and hosted on G2.com.

What do you dislike about IBM Terraform (formerly HashiCorp Terraform)?

State management and the friction that comes with it at scale. Terraform’s state file is both its greatest strength and its biggest ongoing liability. It enables the excellent plan/apply workflow, but in real teams it frequently becomes a source of pain: locking conflicts, configuration drift from console or script changes, risk of sensitive values ending up in state (even when marked sensitive), occasional corruption, and long plan times once you have hundreds or thousands of resources. Remote backends and locking help, but they don’t eliminate the operational overhead. Other notable drawbacks: • Licensing and ownership uncertainty. The 2023 shift from MPL to the Business Source License (BSL) made Terraform source-available rather than fully open source, restricting competing commercial offerings. This prompted the OpenTofu fork and eroded some community trust. IBM’s acquisition (closed February 2025) added another layer—narrower free tiers for HCP Terraform, resource-based pricing, product discontinuations in the broader HashiCorp portfolio, and questions about long-term priorities. Many organizations still use it fine for internal infrastructure, but the change in incentives is real. • Learning curve and day-to-day friction. HCL is more readable than many alternatives, yet dynamic blocks, for_each/count nuances, module composition, and provider quirks create a non-trivial learning curve. Debugging large configurations can be slow, and error messages are often less helpful than they should be. Scaling cleanly across environments and teams usually requires significant discipline (or extra tooling) to avoid module sprawl and duplicated effort. • Limited native strengths outside pure provisioning. Terraform is excellent at declaring and applying infrastructure state, but it’s a weaker fit for ongoing configuration management or application deployment. Most mature setups pair it with something like Ansible (or other tools) rather than trying to force everything into Terraform. In short, the core model remains powerful, but the practical costs of state, the licensing shift, and the post-acquisition commercial direction are the parts that most often frustrate experienced users. Review collected by and hosted on G2.com.

What problems is IBM Terraform (formerly HashiCorp Terraform) solving and how is that benefiting you?

Terraform solves the core problems of managing infrastructure manually or with fragmented, provider-specific tools. Key problems it addresses 1 Manual, inconsistent, and error-prone provisioning (“ClickOps”) Clicking through cloud consoles or running one-off scripts produces snowflake environments that are hard to reproduce, document, or audit. Small differences between dev, staging, and production become common, and human mistakes (wrong settings, missing resources, forgotten cleanups) are frequent. 2 Multi-cloud, hybrid, and multi-tool complexity Each provider (AWS, Azure, Google Cloud, IBM Cloud, on-prem, SaaS services, etc.) has its own APIs, consoles, and CLIs. Managing resources across them without a unifying layer creates operational sprawl and knowledge silos. 3 No safe, reviewable change process Without a clear preview of what will be created, changed, or destroyed, infrastructure updates carry high risk. Teams often lack a reliable way to understand dependencies or the blast radius of a change before it happens. 4 Configuration drift and lack of a single source of truth Resources modified outside the intended process (console hotfixes, scripts, other tools) diverge from the desired state. Over time this leads to undocumented, hard-to-manage infrastructure. 5 Poor collaboration, versioning, and scalability Infrastructure changes are difficult to review, roll back, or share. Large teams struggle with consistency, module reuse, policy enforcement, and safe parallel work. How that benefits users (and practitioners in general) • Consistency and repeatability: The same declarative configuration produces the same infrastructure every time. Environments stay aligned, disaster recovery becomes faster, and “works on my machine” problems shrink dramatically for infrastructure. • Safety through visibility: The plan step shows exactly what will change before anything is applied. This turns high-risk operations into reviewable, approvable changes and reduces the chance of accidental outages or costly mistakes. • One workflow across almost everything: A single language (HCL) and process works across major clouds, private data centers, SaaS tools, and (under IBM) even mainframe environments. Teams stop maintaining parallel toolchains. • Infrastructure as real code: Configurations live in Git, go through pull requests, support modules for reuse, and integrate into CI/CD. This brings software engineering practices (reviews, testing patterns, collaboration, audit trails) to infrastructure. • Faster delivery with less toil: Provisioning and updating environments becomes automated and far quicker than manual work. Platform teams can offer self-service or standardized modules; application teams spend less time waiting for infrastructure. • Better governance and reduced risk (especially in enterprise setups): Policies, approved modules, remote state, locking, and auditability help enforce security, compliance, and cost controls at scale. In short, Terraform turns infrastructure from a fragile, manual, provider-specific chore into a versioned, reviewable, multi-environment system that can be managed with the same rigor as application code. That reliability, speed, and consistency is the practical payoff for teams that adopt it well—despite the state-management and operational overhead that come with it. Review collected by and hosted on G2.com.