---
title: "Comment by OneLifeVibe on \"Terraform Plan Says Destroy and Recreate. What Now?\" | Hashnode"
description: "The point about a data source returning a new latest AMI quietly triggering a replacement really stood out — that is the kind of surprise that does not show up"
url: "https://hashnode.com/posts/terraform-plan-says-destroy-and-recreate-what-now/6af155ea633a03c5378bdbb9/comment/6af22556a1bd141a01e3a7dd"
---

[Discussion](https://hashnode.com/posts/terraform-plan-says-destroy-and-recreate-what-now/6af155ea633a03c5378bdbb9)

Comment [Terraform Plan Says Destroy and Recreate. What Now?](https://hashnode.com/posts/terraform-plan-says-destroy-and-recreate-what-now/6af155ea633a03c5378bdbb9)

[OneLifeVibe](https://hashnode.com/@onelifevibe)

[3d ago](https://hashnode.com/posts/terraform-plan-says-destroy-and-recreate-what-now/6af155ea633a03c5378bdbb9/comment/6af22556a1bd141a01e3a7dd)

The point about a data source returning a new latest AMI quietly triggering a replacement really stood out — that is the kind of surprise that does not show up in the change you actually made. I also liked the distinction between using ignore\_changes for something another system legitimately manages versus using it to silence a plan you do not understand. Do you have a rule of thumb for when a replacement on a stateful resource is worth handling with a migration plan instead of accepting the recreate and scheduling downtime?