Adapting Across a Tool Change

You're helping a Manila BPO that manages cloud infrastructure for twelve client organizations adapt to several tool changes happening at once.

What you're practicing: migrating a working Terraform configuration to OpenTofu and proving it transferred with a clean cross-tool plan and the state intact; re-expressing a GitHub Actions deployment pipeline in GitLab CI with zero deploy disruption; refactoring your own AI infrastructure — CLAUDE.md, a skill — from tool-bound to tool-agnostic; and building a reusable framework for evaluating any tool change.

What you're learning about the loop: a tool migration looks like a find-and-replace, and that is exactly how AI treats it. It renames terraform to tofu, regenerates the lockfile, and reports success — while missing what doesn't carry over. The state has to be migrated deliberately. The provider source address changed. The GitLab runner and auth model is not GitHub Actions OIDC. CLAUDE.md still has tool-specific commands baked in. And there is a licensing question AI won't raise because nothing in the repo asks it. The work is holding the conceptual map of what transfers and what breaks — the map AI does not have — and directing it against that, not against the migration looking right.

Your Role

After this project you can take an understanding you built on one toolchain and carry it to another without losing the thread — and produce the repeatable method a team uses for the next tool change, and the one after that.

Maria is a senior technology leader. She is not confused about whether infrastructure-as-code is still infrastructure-as-code under a different binary — she knows it is. Her problem is scale: fifty engineers of varying adaptability, twelve clients, shifts that never stop, and a stream of tool changes that won't stop either. She does not want the migrations done for her. She wants a systematic approach her team can run themselves, including the engineer who has to deploy at 3am. This is independent work. The difficulty here is conceptual, not infrastructural — almost nothing is provided.

What's New

Last time, at the Municipality of Rosario in Argentina, you inherited a complete environment with broken state, drifted monitoring, and an unexplained bill, and reconstructed what was actually running before changing anything.

This time the system is small, working, and correct — and that is the point. Every infrastructure-as-code project you have done was Terraform. Every pipeline was GitHub Actions. You have never lived a tool migration directly. This one asks whether the skill you have been building for twenty-four projects was ever the tool, or the concept underneath it.

The hard part: the migration itself is genuinely small, so the temptation is to treat it as small all the way through. The friction is in what doesn't transfer — and it is quiet. A plan that looks clean while the state has desynced. A pipeline that lints but fails on the first real deploy. The proof is not that the migration looks right; it's a clean cross-tool plan against the existing state. And the deliverable Maria actually needs is not the migrated configuration — it's the framework.

Tools

• Claude Code — directs the migrations, drafts the framework, and refactors the AI infrastructure.
• Terraform and OpenTofu — used side by side: terraform plan and state inspection, tofu init, the cross-tool plan that proves the migration, lockfile and provider-source comparison.
• GitHub Actions and GitLab CI — the existing workflow and its GitLab CI re-expression.
• AWS CLI — the orphan scan at teardown, with describe-confirmation.
• AWS Budgets — the budget guardrail, provisioned first, before anything else.
• Git / GitHub — the engagement repo; the framework and updated AI infrastructure are committed deliverables.

OpenTofu and GitLab CI are new here. Everything else you have used before. The unit that introduces a new tool walks through what you need.

Materials

In the project zip:

• Slack message (slack-message.md) — the engagement opener from Maria. Short. It says less than the project needs; the rest surfaces in discovery.
• Starter Terraform (starter-terraform/) — one small, working, correct configuration: an S3 bucket and where the budget guardrail goes. This is what you migrate to OpenTofu.
• GitHub Actions workflow (github-actions/deploy.yml) — the pipeline that deploys it, and what you re-express in GitLab CI.
• AI infrastructure starter (ai-infra-starter/) — a CLAUDE.md and a skill with Terraform-specific facts baked in on purpose, so you can factor out what is tool-agnostic.

There is no framework template, no migration runbook, and no answer key. You author your own engagement CLAUDE.md, design your own framework, and decide what transfers. The budget-alarm-first habit, the describe-confirmed orphan-scan teardown, the three-tag scheme, and the repo-handoff habit carry forward unchanged.