Migration / Tasmanian Cloud
Cloud migration without a big-bang cutover
A practical migration sequence for teams moving a workload while keeping its state, access paths, and rollback visible.
Start with the workload, not the provider
A migration starts with a service map: what runs, what it stores, which identities it needs, who reaches it, which jobs call it, and what must remain private. A provider comparison without this map turns into a list of features instead of a migration plan.
The first deliverable should be a bounded workload and a clear statement of what must remain true after the move.
Capture desired and observed state
Define VM or container state, Docker Compose state, network intent, service identities, secret references, health checks, and the expected outputs. Keep the plan separate from the observed state so a failed step does not look like a successful deployment.
Saga workflows attach steps, outputs, and recovery actions to one run. That gives the team a place to inspect partial progress before deciding whether to retry, repair, or roll back.
Rehearse the access path
Test the user path and the machine path separately. The portal, CLI, SDK, REST, and GraphQL clients all call the API, but each may be used by a different operator or automation job. Test private access, bastion grants, webhooks, and notification delivery before cutover.
A workload that runs but cannot be operated is not ready to move.
Use a parallel period
A parallel period makes differences visible. Compare application outputs, data freshness, logs, patch findings, backups, and delivery events. Keep a known rollback path and define who can call it.
The purpose is not to run two systems forever. It is to replace assumptions with evidence before the production switch.
Leave with a record
At cutover, keep the final resource state, data transfer record, identity changes, validation results, and unresolved exceptions. That record helps the team operate the new boundary and makes a future move less expensive.
The strongest migration outcome is not a new console. It is a workload whose important decisions remain inspectable and repeatable.
Need the implementation details?
Read the Tasmanian Cloud documentation ↗