#### Description Yesterday, Jerzy and I discovered some inconsistencies occurring in the remote state of the “skills” service. We noticed the changes while migrating the service from infrastructure repo to foundational repo. Most of the services from ENG-16 have been deployed in the default terraform workspace, so in the new repo it is required to move objects from the default to prod workspace. In the skills service, the state file list for the prod workspace is not empty. The difference in state list is covered here: https://www.diffchecker.com/2bIuybsz The key inconsistency occurs for the resource: **module.skills.aws_cloudformation_stack.workers_asg** and **terraform_remote_state.bastion**. > module.skills.aws_cloudformation_stack.workers is present in both environments however, it differs in the cloudformation stack used. Default uses a stack with id arn:aws:cloudformation:us-east-1:307275847480:stack/prod-sumdogskills/b653f2a0-6982-11e8-b69b-500c28afa0ba and production uses a stack with id prod-sumdogskills. [Differences output](https://www.diffchecker.com/RGYKrRwg) These stacks differ in launchConfigurations used, however these configurations contain the same elements, they differ in user data hash and name. > In the case of terraform_remote_state.bastion, the difference is in used public addresses and DNS records. [Differences output](https://www.diffchecker.com/fik6Ozrr) #### Solution In our opinion, the above situation may be due to an attempt to previously migrate resources from one repository to another, or mistakenly apply changes to the prod workspace. The above case causes duplication of resources and in our opinion removing the list of states (resources using the old cloud formation stack) will be a good solution. What do you think?