Back to Blog
Company

Informa’s smooth migration from Terraform to OpenTofu

A phased rollout helped the cloud platform team move early, stay stable, and set the stage for future capabilities like state encryption.

Tin Nguyen
Tin
Nguyen
,
Head of Marketing
April 10, 2026

Key results

  • Standardized on OpenTofu for everything running through Gruntwork pipelines, spanning many repositories and AWS accounts.
  • Completed a staged cutover across environments with no reported consumer issues and no noticeable functional changes.
  • Built a foundation for an ongoing OpenTofu upgrade cadence.
“I would describe our upgrade from Terraform as ‘unexciting’ — and I mean that in the best possible way because it just worked.”

– Chris Smail, Senior Cloud Platform Engineer

Informa is one of the world’s largest publishers and events businesses, with a broad portfolio of brands and business units operating globally. That scale comes with real infrastructure complexity, especially across cloud accounts and shared platform services, where small tooling decisions can multiply into major risk and operational drag.

For Informa’s cloud platform organization, their mandate is clear: keep the platform stable, keep teams productive, and make choices that hold up under enterprise scrutiny.

When Terraform’s license changes introduced new uncertainty, the team made a practical call: migrate to OpenTofu early, and remove a growing question mark from their infrastructure toolchain.

Replacing licensing uncertainty with a stable OpenTofu standard

The initial driver for migrating was straightforward. “The biggest thing was the Terraform licensing issues,” said Chris Smail, Senior Cloud Platform Engineer at Informa. “No one wants to be stuck with a big asset and licensing bill.” For a platform team supporting broad internal usage, unclear future costs and compliance questions are hard to justify, especially when OpenTofu existed and kept workflows familiar.

Timing also mattered. Informa’s team had recently invested in new AWS landing zones built with Gruntwork’s patterns and modules, and they saw a narrow window where migrating would be easier than waiting. The team had already gone down a long path of setting the landing zones up. With that foundation in motion, the team chose to switch sooner rather than later: “Doing it now would be better than waiting until we had a bunch of accounts and then doing the conversion.”

That combination — license uncertainty plus a clean moment in the platform roadmap — helped them treat the migration as a proactive platform decision rather than a forced emergency change.

From there, the goal expanded beyond a single team’s tooling preference. What began as a push to make OpenTofu the default for Unity, Informa’s centralized cloud infrastructure and governance platform, became a broader standard others could align to.

“This was a risk decision as much as a technical one. We wanted to keep our platform on a tool we can standardize on without worrying about surprise costs later.”

– Andrew Deering, Head of Cloud Platforms

A staged cutover that kept changes “boring” for consumers

Informa’s current footprint of OpenTofu covers the infrastructure managed through Gruntwork. Chris Smail notes, “Absolutely everything that is a Gruntwork Pipeline is on OpenTofu now, spanning quite a few repos and a lot of AWS accounts.”

Just as important as scale was the experience of the cutover itself. The team aimed for a migration that would barely register for internal consumers, and they largely got that outcome. Smail described the upgrade as “unexciting” simply because “it just worked.”

Vince Harris, Platform Engineer at Informa, had the same view from the execution side: “The transition from our version of Terraform to OpenTofu was seamless.” When asked about consumer impact, he noted, “none at all.”

“We strive to deliver an awesome Developer experience, and this was not impacted in any way. We want teams to move faster and to remove blockers, the transition didn’t affect the velocity at which our DevSecOps, and development teams continue to move.”

– Chris Smail, Senior Cloud Platform Engineer

The team didn’t treat this as a one-shot flip. They rolled it out in phases, building confidence as they went. They started with sandbox accounts, then went on to standalones, and finalized everything with SDLC accounts. That approach reduced risk and made it easier to spot issues early, before the migration touched higher-stakes environments.

They also did prep work before the broader consumer move. Smail explained that they upgraded core components first and let them run — and ran into no issues. In fact, they had already proven the path in earlier work: “We had the dev landing zone upgraded months before, like six months before with no issues.”

Sequencing mattered because it kept the migration from becoming a major, disruptive project. Informa could validate OpenTofu in lower-risk areas, then expand with confidence once stability was proven.

“The migration was deliberately low drama. We proved it in lower environments, then rolled it forward. From a platform perspective, this was the outcome you want: a clean cutover and internal teams basically kept working as usual.”

– Chris Smail, Senior Cloud Platform Engineer

Keeping parity now, planning new capabilities next

At the time of the discussion, Informa’s OpenTofu usage focused on parity with their prior Terraform baseline, rather than chasing new features immediately. Chris Smail noted they were on “the sort of parity version, 1.6.2,” and that “no one’s noticed any functional changes.”

That stability was a feature, not a limitation. It let them standardize the toolchain without forcing downstream teams to relearn workflows, rewrite modules, or adopt new patterns midstream.

With the migration complete, the roadmap shifts to operational maturity. Smail wants a predictable release cadence: “I want to give our consumers a kind of release cadence for what we want to do regarding OpenTofu upgrades.”

They also have their eye on security-driven improvements, like state encryption. “We want to be able to do the encryption and state files, maybe in the second half of this year.” For enterprise platform teams, that kind of capability becomes easier to roll out once the toolchain is standardized and the migration risk is behind you.

“The technical win was maintaining continuity. The next phase is using the move to OpenTofu as a foundation for security and platform upgrades.”

– Chris Smail, Senior Cloud Platform Engineer

Advice for teams considering the same move

Informa’s advice is blunt, and it matches the tone of their experience. “Don’t hesitate. Just do it. It’s going to save time in the long run.”

They also shared a grounded view of why some organizations still hesitate. Deering pointed to concerns about long-term divergence: “A big fear is that as time goes on and the two projects diverge, you might worry about missing features in OpenTofu that would be in Terraform.” Support requirements may also drive similar reluctance in regulated industries. Informa, however, leaned the other direction. As for Deering, “I have more confidence in the open source community than in a monolithic corporation owning the entire code base.”

For Informa, the migration worked because they treated it like a platform decision, executed it with a staged rollout, and optimized for stability over drama. The end result is exactly what most platform leaders want: a widely adopted standard that reduces risk today, while creating room for improvements tomorrow.

“If you’re already thinking it’s the direction you’ll heading in, move early. It reduces the long-term burden and avoids doing the work later under pressure.”

– Andrew Deering, Head of Cloud Platforms