> For the complete documentation index, see [llms.txt](https://docs.ionos.com/cloud/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ionos.com/cloud/terraform/guides/migrating_inmemorydb_v1_to_v2.md).

# Migrating InMemoryDB from ionoscloud\_dbaas\_inmemorydb\_replica\_set to ionoscloud\_inmemorydb\_cluster\_v

`ionoscloud_inmemorydb_cluster_v2` is a re-implementation of the InMemoryDB resource on the newer plugin framework, backed by the v2 DBaaS InMemoryDB API. It is a **different resource type** from the legacy `ionoscloud_dbaas_inmemorydb_replica_set`, with a different schema (single nested blocks instead of lists, a required `location`, explicit snapshot and maintenance window configuration, etc.).

Because the two are different resource types served by different plugin frameworks, a plain `moved {}` block **does not** work between them. Instead, the recommended migration adopts each existing cluster into the new resource and drops the old one from state — **without touching the running cluster**. No data is moved or recreated; only Terraform state changes.

> **Important:** This migration assumes `ionoscloud_dbaas_inmemorydb_replica_set` and `ionoscloud_inmemorydb_cluster_v2` manage the *same* underlying cluster (same UUID). It changes Terraform state only and never mutates, recreates, or deletes the live database.

## Prerequisites

* Terraform **1.14+** (for the `terraform query` list/config-generation workflow used below). Terraform **1.7+** is enough if you choose to write the `import` blocks by hand.
* A backup of your state file (`terraform state pull > state.backup.json`).

## Recommended approach: query-generate + `removed`

The `ionoscloud_inmemorydb_cluster_v2` **list resource** can enumerate your existing clusters and generate complete `v2` configuration for each one, so you don't have to hand-write the new resource blocks or look up cluster UUIDs.

### 1. Discover clusters and generate v2 configuration

Create a query file, for example `migrate.tfquery.hcl`:

```hcl
list "ionoscloud_inmemorydb_cluster_v2" "all" {
  provider         = ionoscloud
  include_resource = true
  # Optional: scope discovery to a single region.
  # config {
  #   filters = [
  #     { field_name = "location", field_value = "de/txl" },
  #   ]
  # }
}
```

Then generate configuration and import blocks for the discovered clusters:

```sh
terraform query -generate-config-out=generated_inmemorydb_v2.tf
```

`generated_inmemorydb_v2.tf` will contain a fully-populated `ionoscloud_inmemorydb_cluster_v2` block for each cluster (name, version, instances, connections, snapshot, maintenance window, logs/metrics, …), together with `import` blocks keyed by the v2 resource identity (the cluster `id` and `location`).

### 2. Drop the legacy resources from state

For each legacy `ionoscloud_dbaas_inmemorydb_replica_set` you are migrating, add a `removed` block so Terraform forgets it **without destroying** the live cluster:

```hcl
removed {
  from = ionoscloud_dbaas_inmemorydb_replica_set.example
  lifecycle {
    destroy = false
  }
}
```

Delete the corresponding `resource "ionoscloud_dbaas_inmemorydb_replica_set" "example" { … }` configuration.

### 3. Fill in the values that cannot be generated

A few attributes are not part of the cluster's readable state and must be added by hand to the generated `ionoscloud_inmemorydb_cluster_v2` blocks:

| Attribute              | Why it's missing                      | What to do                                          |
| ---------------------- | ------------------------------------- | --------------------------------------------------- |
| `credentials.password` | Write-only; the API never returns it. | Add the entire `password` block (it is `Required`). |
| `timeouts`             | Optional; not generated.              | Add only if you previously customized timeouts.     |

`restore_from_snapshot` is never returned by the API, so config generation never emits it. You do not need it when adopting an existing cluster — add it only if you want to trigger a restore from a snapshot.

### 4. Apply

```sh
terraform plan    # confirm: imports the v2 resources, removes v1 from state, NO destroys/replaces
terraform apply
```

The plan should show the clusters being **imported** into `ionoscloud_inmemorydb_cluster_v2`, the `ionoscloud_dbaas_inmemorydb_replica_set` resources being **removed from state**, and **no** create/destroy/replace actions against the live clusters. If you see a forced replacement, stop and reconcile the offending attribute before applying.

## Manual alternative (no config generation)

If you prefer not to use the query workflow, you can do the same thing with explicit blocks. For each cluster, write the `ionoscloud_inmemorydb_cluster_v2` configuration yourself and pair it with:

```hcl
import {
  to = ionoscloud_inmemorydb_cluster_v2.example
  id = "de/txl:00000000-0000-0000-0000-000000000000" # "<location>:<cluster_id>"
}

removed {
  from = ionoscloud_dbaas_inmemorydb_replica_set.example
  lifecycle {
    destroy = false
  }
}
```

Then `terraform plan` / `terraform apply` as above. You can find the cluster UUID in the legacy resource's state (`terraform state show ionoscloud_dbaas_inmemorydb_replica_set.example`).

## Rollback

Because the live cluster is never touched, rollback is just reverting your configuration changes and restoring the pre-migration state file if you already applied:

```sh
terraform state push state.backup.json
```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.ionos.com/cloud/terraform/guides/migrating_inmemorydb_v1_to_v2.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.