Walkthrough: Using Sentinel policies during a Terraform migration to enforce new standards.

Your terror is the correct response. Using Sentinel to gatekeep during a migration is like running a new antivirus scan while you're reinstalling the operating system. It adds a critical failure point to an already delicate process.

The gotcha is that policies evaluate the *entire* planned diff, not just new resources. If your old state has a thousand untagged resources, a mandatory-tag policy will fail the entire migration plan. You'd need to write overly permissive policies with complex logic to grandfather old resources, which defeats the purpose of enforcement. Your lead is conflating two separate projects: state migration and governance rollout.

Do the migration cleanly first, then apply Sentinel. Trying to do both at once turns a technical lift into a policy negotiation mid-air. I've seen teams waste weeks writing temporary policy exceptions instead of just moving the state.

You're right about the scope issue, but I think the analogy oversimplifies. The migration itself is often the only time you have full organizational focus on infrastructure. It's a painful but unique opportunity to embed governance.

The key is policy design. Sentinel can inspect the `change.action` attribute. You can write policies that only flag resources with `create` or `update` actions, explicitly ignoring `read` (which is what the state migration will show for existing resources). This lets you enforce new standards on net-new work during the migration without blocking the state import.

Done poorly, it's a hurdle. Done with precise targeting, it prevents the new "proper backend" from immediately accumulating technical debt. The risk is less in the concept and more in the team's policy-writing discipline.

>Your terror is the correct response.

I see you've survived at least one migration. I agree 100%. The other reply's suggestion about inspecting `change.action` is technically correct, but it ignores the human factor. You're now asking a team under migration pressure to also become Sentinel policy authors, which is a whole other skillset. The policy will have a bug. Someone will bypass it in a panic to hit a deadline, and now your "enforcement" is a joke you spent three sprints building.

It turns a straightforward, if tedious, technical task into a high-stakes logic puzzle. I watched a team try this exact thing and the policy falsely flagged a dozen existing S3 buckets as "new creates" because of how the state was being mapped. They spent two days debugging Sentinel instead of validating their migrated state. The migration was delayed, and they turned the policy off "temporarily." It's still off.

The technical suggestions about `change.action` are valid, but they depend heavily on your migration method. If you're using `terraform import` or `state mv`, the action mapping isn't always intuitive. A resource being imported to a new module address might show as a `create` in the plan, which would be incorrectly flagged by a naive policy.

You need to test your policies against dry-run plans of each migration batch. Write a small script that runs `terraform plan`, saves the mock data, and runs your Sentinel policies locally against it before any real execution.

It can help, but only if you treat policy writing as a parallel, equally important track with its own testing cycle. Otherwise, it becomes a debugging time-sink as user467 noted.