# Terraform 0.13 Error: Provider configuration not present (module files not present anymore)

**URL:** <https://discuss.hashicorp.com/t/terraform-0-13-error-provider-configuration-not-present-module-files-not-present-anymore/23507>\
**Category:** Terraform\
**Created:** [April 22, 2021, 10:07pm UTC](https://discuss.hashicorp.com/t/terraform-0-13-error-provider-configuration-not-present-module-files-not-present-anymore/23507 "2021-04-22T22:07:07Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![vikas027](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/vikas027/32/1352_2.png) [@vikas027](https://discuss.hashicorp.com/u/vikas027)\
**Post date:** [April 22, 2021, 10:07pm UTC](https://discuss.hashicorp.com/t/terraform-0-13-error-provider-configuration-not-present-module-files-not-present-anymore/23507/1 "2021-04-22T22:07:07Z")

</div>

### Issue

I am working on migrating a ton of modules from 0.11.4 to 0.13.6. I have deliberately not chosen directly to jump to 0.14 as there are some breaking changes, moving to 0.14 and then 0.15 are my next goals.

The problem is that a handful of modules have been deleted from terraform configuration files without using terraform destroy ☹

Now, the modules information is in terraform state but the actual files are lost. If I had those files, I would have used the provider specifically in the modules and fixed (like I have done with a lot of other modules).

```auto
# This is just an example, I have quite a few of these :(
To work with module.vault.data.aws_route53_zone.hosted_zone its original
provider configuration at
module.vault.provider["registry.terraform.io/hashicorp/aws"].R53 is required,
but it has been removed. This occurs when a provider configuration is removed
while objects created by that provider still exist in the state. Re-add the
provider configuration to destroy
module.vault.data.aws_route53_zone.hosted_zone, after which you can remove the
provider configuration again.

```

### Terraform Version

```auto
❯ terraform version                    
Terraform v0.13.6
+ provider registry.terraform.io/-/random v3.1.0
+ provider registry.terraform.io/hashicorp/aws v3.30.0
+ provider registry.terraform.io/hashicorp/external v2.1.0
+ provider registry.terraform.io/hashicorp/null v3.1.0
+ provider registry.terraform.io/hashicorp/random v3.1.0
+ provider registry.terraform.io/hashicorp/template v2.2.0

```

### Workaround?

I know it is not recommended but can I just pull the state file and remove all JSON blocks of `"module": "module.vault",` or run `terraform state rm` on the modules.  
I know it is not recommended way but I can’t think of anything else at the moment as I do not have the files anymore.

### References

- ["Error: Provider configuration not present" when aliased provider is used · Issue #21416 · hashicorp/terraform · GitHub](https://github.com/hashicorp/terraform/issues/21416)
- [[SOLVED] Provider alias errors with Provider configuration not present](https://discuss.hashicorp.com/t/solved-provider-alias-errors-with-provider-configuration-not-present/8271)

---

<div class="post-metadata">

**Author:** ![apparentlymart](https://sea2.discourse-cdn.com/hashicorp/user_avatar/discuss.hashicorp.com/apparentlymart/32/702_2.png) [@apparentlymart](https://discuss.hashicorp.com/u/apparentlymart)\
**Post date:** [April 23, 2021, 12:38am UTC](https://discuss.hashicorp.com/t/terraform-0-13-error-provider-configuration-not-present-module-files-not-present-anymore/23507/2 "2021-04-23T00:38:23Z")

</div>

Hi @vikas027,

You can indeed use `terraform state rm` to ask Terraform to “forget” these objects that belong to a provider configuration that is no longer present.

The effect of that would be that Terraform would behave as if they had never existed, and so if those objects do still exist in the remote system then you’ll need to delete them manually.

However, in the example you showed here the mentioned resource is a data resource, and so having Terraform “forget” it should have no significant consequences: this configuration wasn’t actually managing that object anyway, so the state only contains a cached copy of the most recent data it read.