Architecture / Tasmanian Cloud
A cloud exit plan starts before the exit
Reduce hyperscaler lock-in by keeping data, identity, networking, and deployment state portable before you need to move.
Lock-in is more than a contract
Hyperscaler lock-in is the cost of leaving a platform after the platform has become part of the application. The obvious costs are data transfer and replacement infrastructure. The harder costs are provider-specific identity, networking, deployment state, observability, queues, and the knowledge trapped in one console.
An exit plan is useful even when you do not plan to leave this year. It tells you which decisions are portable, which are coupled to a provider, and which dependencies need a deliberate replacement.
Keep the control surface yours
A portable workflow starts with an API-owned model of resources and runs. The portal, CLI, SDK, REST client, GraphQL client, and x402-aware caller should use the same API rather than create separate versions of the truth.
That makes a migration a change of provider or execution boundary, not a rewrite of every human and machine workflow around the workload.
Treat deployment state as a first-class asset
A VM image is not the whole deployment. Record the desired VM or container state, Docker Compose state, Ansible steps, Terraform or OpenTofu inputs, network intent, secrets references, checks, outputs, and recovery steps together.
Saga templates keep the plan and its execution evidence attached to the run. If a step fails, the useful question is not only what command failed. It is what state exists now and what can be replayed safely.
Separate secrets from the migration bundle
A migration bundle should carry references and policy, not a pile of copied credentials. Dialkeys give services stable logical identities. Kleis expressions resolve an allowed value for a specific operation without placing the plaintext secret in a template, shell history, or AI context window.
This makes provider changes easier to reason about. Rotate the underlying value or change the provider binding without rewriting every dependent .env file.
Move in stages
A credible exit plan has stages: inventory dependencies, export data, reproduce the workload, validate network and identity paths, run a parallel period, then cut over with a tested rollback. Some workloads should remain where they are while a specific dependency is replaced.
The goal is not to pretend every workload is portable. The goal is to know what is portable, what is not, and what the next reduction in dependency will cost.
What Tasmanian Cloud provides
Tasmanian Cloud provides a locally operated control plane for virtual machines, containers, private networking, storage, integrations, and stateful deployment workflows. It is one option for teams that want a clearer operating boundary and a practical path away from a single hyperscaler console.
The right starting point is an inventory and migration assessment, not a promise that every workload should move.
Need the implementation details?
Read the Tasmanian Cloud documentation ↗