This PoC demonstrates how object storage abstraction + rclone + clean Kubernetes deployment makes observability backend migration predictable and low-risk.

This PoC was not only a technical exercise — it was a validation of reverse cloud migration feasibility: moving stateful observability infrastructure from a US hyperscaler (Azure) to a European cloud provider (OVH).

Initial Architecture (Azure)

Components

• AKS (Azure Kubernetes Service)

• Grafana Tempo

• Azure Blob Storage (Storage Account)

Storage Model

Tempo was configured to use:

storage:
  trace:
    backend: azure
    azure:
      container_name: tempo
      storage_account_name: <account-name>

storage:
  trace:
    backend: azure
    azure:
      container_name: tempo
      storage_account_name: <account-name>

storage:
  trace:
    backend: azure
    azure:
      container_name: tempo
      storage_account_name: <account-name>

Tempo writes:

• WAL (Write-Ahead Log)

• Blocks

• Index metadata

All persisted in Azure Blob Storage.

Important property:

Tempo treats object storage as the system of record.

This is what makes the migration possible.

Target Architecture (OVH)

Components

• OVH Managed Kubernetes

• OVH Object Storage (S3-compatible)

• Grafana Tempo (new deployment)

• Grafana (new deployment)

• Same trace data, copied from Azure

Key idea:

Instead of re-ingesting traces, we migrate the object storage backend ans show reverse migration in practical way.

Migration Strategy

Instead of:

• Replaying telemetry

• Dual-writing traces

• Modifying collectors

We chose:

Copy object storage contents from Azure Storage Account to OVH Object Storage Service → Deploy new Tempo in OVH Managed Kubernetes Service → Point to new bucket

Data Transfer with rclone

We decided to use rclone https://rclone.org/. It is a really cool utility to migrate data between different providers.

Why rclone?

• Supports Azure Blob

• Supports S3-compatible object storage

• Efficient parallel transfer

• Metadata preservation

• Resume support

Step 1 — Configure rclone

Azure Blob config

rclone config

rclone config

rclone config

Example remote:

[azure]
type = azureblob
account = <storage_account_name>
key = <account_key>

[azure]
type = azureblob
account = <storage_account_name>
key = <account_key>

[azure]
type = azureblob
account = <storage_account_name>
key = <account_key>

OVH Object Storage (S3 compatible)

[ovh]
type = s3
provider = Other
env_auth = false
access_key_id = <access_key>
secret_access_key = <secret>
endpoint = s3.<region>

[ovh]
type = s3
provider = Other
env_auth = false
access_key_id = <access_key>
secret_access_key = <secret>
endpoint = s3.<region>

[ovh]
type = s3
provider = Other
env_auth = false
access_key_id = <access_key>
secret_access_key = <secret>
endpoint = s3.<region>

Step 2 — Copy Data

rclone copy azure:tempo ovh:tempo \
  --progress \
  --transfers 16 \
  --checkers 16

rclone copy azure:tempo ovh:tempo \
  --progress \
  --transfers 16 \
  --checkers 16

rclone copy azure:tempo ovh:tempo \
  --progress \
  --transfers 16 \
  --checkers 16

Verification:

rclone check azure:tempo ovh:tempo

rclone check azure:tempo ovh:tempo

rclone check azure:tempo ovh:tempo

Deploy Tempo on OVH Kubernetes

Install via Helm:

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

tempo-values.yaml

Configured to use OVH Object Storage (S3 backend):

tempo:
  storage:
    trace:
      backend: s3
      s3:
        endpoint: s3.<region>.cloud.ovh.net
        bucket: tempo
        access_key: <access_key>
        secret_key: <secret>

tempo:
  storage:
    trace:
      backend: s3
      s3:
        endpoint: s3.<region>.cloud.ovh.net
        bucket: tempo
        access_key: <access_key>
        secret_key: <secret>

tempo:
  storage:
    trace:
      backend: s3
      s3:
        endpoint: s3.<region>.cloud.ovh.net
        bucket: tempo
        access_key: <access_key>
        secret_key: <secret>

Install:

helm install tempo grafana/tempo -f tempo-values.yaml

helm install tempo grafana/tempo -f tempo-values.yaml

helm install tempo grafana/tempo -f tempo-values.yaml

Critical:

• The bucket name must match the copied container

• Path structure must remain unchanged

Tempo reads existing blocks automatically.

Deploy Grafana on OVH

Install Grafana and check whether historical data is in Tempo or not, and here we go

What This Proves

Cloud migration does not have to be a one-way journey toward hyperscalers. Reverse migration — moving workloads and data from one cloud provider to another, including from US-based hyperscalers to European cloud platforms — is technically feasible when systems are designed with portability in mind.

The results demonstrate that when architecture is designed around open standards and storage abstraction, such a transition becomes operationally straightforward.

In other words, reverse migration (US → EU) is viable when state is portable and architecture avoids proprietary lock-in.

Conclusion

If your organization is evaluating:

• Hyperscaler exit strategies

• Sovereign cloud transitions

• Multi-cloud rebalancing

• Cost or compliance-driven cloud changes

We can help assess portability, design the migration path, and execute the transition safely.