> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Operations

> Health, configuration changes, migrations and recovery.

Operate the adapter and its dependencies as one request path. An accepting listener does not prove the selected backend is reachable, and a healthy backend does not prove that origin requests can be authenticated and translated.

## Establish a baseline

Record the adapter version, redacted configuration, selected mappings and expected endpoints. Identify the backend stores and any shared coordination store. Keep a small representative request you can use to verify the path with test data.

Observe request outcomes and latency alongside backend and process health. Keep correlation identifiers from failures so you can relate an application report to adapter logs. See [debugging](/cloud-adapter/debugging/overview).

## Change configuration deliberately

Run the local Tensor9 CLI with a proposed configuration. The CLI compares it with the installed configuration, rejects incompatible changes, carries out supported migrations and coordinates rolling restarts across the adapters.

Before a rollout, review both the proposed settings and the transition needed to reach them. Keep the previous configuration, verify backups and establish how to detect a failed change. A rolling restart does not, by itself, make every migration reversible or guarantee uninterrupted requests.

## Backend changes can require data migration

Changing a DynamoDB adapter from one database backend to another may require copying data, preserving identifiers and coordinating writes during the move. That is not an ordinary settings update.

The upgrade workflow blocks a backend change when no supported migration exists. Do not work around a compatibility refusal by manually editing shared state or replacing backend credentials.

## Safe and blocked changes

| Change                                        | Handling                                                                      |
| --------------------------------------------- | ----------------------------------------------------------------------------- |
| Adapter image or non-stateful process setting | Compatibility check, rolling restart and health verification                  |
| Endpoint, network or credential reference     | Preflight connectivity and identity checks, then rolling restart              |
| New service adapter using new resources       | Validate coverage and provision the resources before rollout                  |
| Backend for an empty service                  | Allowed only when the configuration contract says no data migration is needed |
| Backend for a populated DynamoDB service      | Block unless a supported migration exists; do not treat it as a setting edit  |
| Key, identity or data-format change           | Block or require a service-specific migration and recovery plan               |

The CLI shows which category a proposed change falls into before applying it. A rolling restart is an activation mechanism, not proof that data or identities can be moved safely.

## Recovery and interruption

After an interrupted change, inspect the actual running versions and migration state before retrying. Reapplying the old configuration is not necessarily a rollback after data has changed. The release-specific upgrade guide must define restart, retry and rollback behavior before an upgrade can be considered supported.

For a request that times out, first determine whether the backend operation took effect. Absence of a successful response is not evidence of no write. Use [response headers](/cloud-adapter/debugging/response-headers), resource reads and documented idempotency behavior when deciding what to retry.

## Scaling and teardown

Measure bottlenecks before adding processes. The origin client, adapter, coordination store and backend can each impose limits. Test the scale change with representative requests, not only process health checks.

Before teardown, inventory resources and decide which data to retain. Stopping adapters and deleting backend storage are separate actions. No automatic deletion or data-retention policy should be assumed without a release-specific procedure.