Migrate self-hosted Temporal to Temporal Cloud

How do you migrate self-hosted Temporal to Temporal Cloud without losing running workflows?

Moving self-hosted Temporal to Temporal Cloud is a planned, namespace-by-namespace cutover that starts with prerequisites, runs a pilot on non-production namespaces, and ends with a finalize step that cannot be undone. How long it takes and what it costs depend on workflow volume, the data stores behind your self-hosted service, how your security integration is wired, and how your workers are deployed and pointed at the new endpoint. We do not give a duration before we have read your environment. DeployOpen scopes the work in writing before any migration work starts, and that scope names the namespaces, the cutover method, the acceptance checks and who performs each step.

Start with an inventory for each namespace: the number of running workflows, open timers, the signals and queries your clients send, the workflow and activity types each worker registers, retention settings, and the search attributes your queries depend on. Confirm that your self-hosted server runs a supported version and that upgrades have followed the documented path, moving one minor version at a time, because backward compatibility is guaranteed only between successive minor versions. Where release notes call for it, schema upgrades must run before server upgrades. Record the persistence and visibility stores you run today, since they determine what you must export, reconcile or leave in place during the transition. Ask Temporal which migration method currently supports your namespace configuration, and get the answer in writing before you choose between automated replication and a manual cutover.

Security integration is where many migrations stall. Map how your self-hosted frontend authenticates callers today. A self-hosted deployment with no Authorizer configured uses a default that allows every API request without authentication, so teams that have set up mTLS, a ClaimMapper, a custom Authorizer or OIDC for the Web UI must recreate those identities and namespace role mappings for Temporal Cloud. Every client needs its credentials issued, rotated and tested. Inventory your codec servers and payload encryption keys as well, because workers and the Web UI need to decode payloads that were written before the cutover. Plan worker deployments as two sets during the transition, one connected to the old frontend and one connected to the new, and decide task queue names and worker versioning before the pilot begins.

Run the pilot on a non-production namespace that matches the production workload shape: similar workflow history length, timer use, child workflow depth and worker concurrency. Measure action volume and storage during the pilot so any quote from Temporal Cloud rests on observed numbers. The public pricing page lists the cost components, including actions, active and retained storage, and the support tier you select. Write acceptance checks before the pilot: workflows started after cutover complete, in-flight workflows finish on the expected path, and client rollback steps have been rehearsed. Schedule the finalize step only after those checks pass, and confirm with the operations owner that no process still depends on the self-hosted namespace, because finalizing is the point of no return.

Which self-hosted Temporal capabilities map to Temporal Cloud and which need a decision

This table compares each self-hosted Temporal capability with its Temporal Cloud counterpart and notes what changes during migration. Where current Temporal documentation does not confirm parity, the cell marks it to confirm and names the decision the team must make. Treat a cell marked to confirm as an open item until the vendor documentation settles it.

Source capability	Temporal Cloud equivalent	Migration notes
Namespaces	Cloud namespaces created in the Temporal Cloud account. Confirm naming, region and settings in current docs.	Map each self-hosted namespace to one cloud namespace. Choose automated replication or manual cutover per namespace.
Workflow code and workers	Workers connect to the Cloud endpoint. Confirm supported client connection and credential options.	Code changes should center on client connection settings. Retest workflow versioning and determinism before cutover.
Codec server for payload encryption	Customer-run codec server is used with Cloud. Confirm endpoint and access requirements in current docs.	Keep the codec server reachable to the Cloud UI and tooling. Key custody stays with your team.
mTLS and ClaimMapper or Authorizer	Access is managed by Temporal Cloud. Confirm supported credentials and role model.	Custom ClaimMapper and Authorizer plugins do not carry over automatically. Decide how roles are reissued.
OIDC for the Web UI versus SAML SSO	SAML SSO is documented for Temporal Cloud. Confirm IdP setup and role mapping.	OIDC settings for the self-hosted Web UI do not transfer. SCIM is listed for Enterprise and Mission Critical tiers.
Persistence and visibility stores	Managed by Temporal Cloud. Confirm what history and visibility data can be migrated.	Cassandra, PostgreSQL, MySQL and Elasticsearch or OpenSearch stores are retired after cutover. Decide what history to keep.
Helm or Kubernetes operations	No self-hosted server cluster to run. Confirm which components remain in your cluster.	Chart and server version rules apply only to components you keep. Remove retired services after validation.
Retention	Set per namespace in Cloud. Confirm available range and billing for retained storage.	Align retention with your records policy before cutover. Retained storage is billed per GB-hour on the pricing page.

Which server version, schema and deployment prerequisites must be ready first?

These prerequisites set the order of the migration. The server version, schema, deployment and storage must be known and supported before any namespace moves. Each card below is a check to complete and record in the change plan before namespace inventory and replication work begins.

Upgrade one minor version at a time

Temporal guarantees backward compatibility only between two successive minor versions, so a self-hosted cluster that is several minors behind must step through each one. Move to the latest patch of the current minor before starting the next step. Record the version at each step, confirm the sequence in the upgrade documentation, and plan a rollback point between steps because each one changes a production cluster.

Target the latest patch releases

Temporal published v1.32.1 on October 8, 2026, and patch releases v1.31.4 and v1.30.8 on October 12, 2026, for earlier minor lines. Use these as reference points for the patch level of each minor you run. Check the GitHub releases page on the day you plan the work, because a newer patch may have shipped since these were published.

Run schema upgrades before server upgrades

When release notes call for a database schema change, apply it before the server binaries or images roll forward. Running a newer server against an older schema can fail in ways that are hard to reverse. Read the notes for each minor step, mark which steps need schema work, and confirm that order in your change plan. Rehearse the same sequence on a non-production copy first.

Pin the Helm chart version

Helm chart versions below 0.73.1 do not work with server images 1.30 and later. If your cluster deploys Temporal through the Helm chart, pin the chart to 0.73.1 or higher before selecting a 1.30 or later image. Confirm the chart version your deployment pipeline actually applies, because an out-of-date chart can block a server upgrade you have already planned.

Confirm persistence store and shard count

Temporal tests persistence on Cassandra 3.11, 4.0 and 5.0.4 or later, PostgreSQL 13 to 16, and MySQL 5.7 and 8.0.19 or later, while SQLite is meant only for development and testing. Confirm your store version and shard count against the Temporal persistence documentation, because shard requirements for migration are not covered here. Ask Temporal or your implementation partner to confirm the shard figure before scheduling any namespace work.

Check the visibility store version

Advanced visibility on self-hosted Temporal supports Elasticsearch 7 and 8, OpenSearch 2 or later from Temporal Server 1.30.1, MySQL 8.0.17 or later, PostgreSQL 12 or later, and SQLite from 1.20. Cassandra visibility was removed in 1.24, so a cluster that still depends on it must change its visibility store as part of the upgrade path. Record which visibility store each namespace uses and its version.

What moves with each namespace, and what stays in your environment

A namespace migration moves the state Temporal keeps for a namespace: workflow executions, their event histories, and the visibility records your teams use to find and count executions. The Temporal Cloud namespace needs those records to continue work, so the first decision is which executions must survive the move and which can be allowed to finish or close on the self-hosted Service. Write that list for each namespace before you configure anything. Confirm in the current Temporal migration documentation exactly which execution states transfer and how retention is applied to transferred history. Those two answers decide what your operators can still look up after cutover.

Everything that runs the work stays with your team. Worker code, the processes that poll task queues and execute workflow and activity logic, keeps running in your infrastructure and connects to the Cloud namespace. Activity dependencies such as databases, internal APIs and message queues remain where they are, and so do the external systems that workflows call. If you use a payload codec, the codec server and its encryption keys also stay in your environment, so payload contents remain encrypted outside it. Plan network paths and credentials for each of these components before cutover. A migrated namespace with unreachable workers or missing secrets will stall and may show no clear error.

Workflow code must stay compatible across the move because Temporal rebuilds workflow state by replaying recorded history. If code changes the order or type of commands issued for an in-flight execution, replay can fail. This rule applies on both sides of the migration. Workers that serve the Cloud namespace must replay histories written by the self-hosted Service, so workflow definitions must either match or be versioned in a way that keeps old histories replayable. Choose the versioning approach your team will use, such as patching or worker versioning, and test it against histories exported from non-production namespaces before any production worker switches.

Versioning decisions matter most during a parallel run, when some workers still poll the self-hosted namespace while others poll the Cloud namespace. Each side must run code that can finish the executions it owns. Decide which build starts new executions, which build completes in-flight executions, and when the old workers are drained and retired. Record those decisions in the cutover plan with named owners. Also confirm that the server and SDK versions on your self-hosted side are supported as a migration source by the current migration documentation, and check those prerequisites before you assume the parallel run will work as planned.

Automated replication or a manual cutover: how to choose

Automated replication keeps a target namespace in Temporal Cloud aligned with the self-hosted source while the source continues to serve workflows. Conceptually, the migration tooling copies namespace state across over time, so the team's main work shifts from moving data to verifying that the target reflects the source. Traffic moves only after that verification, and the source remains available for a period if you need to return to it.

This approach suits:

Large namespaces or many running workflows, where pausing all activity for a full copy would extend the period of unavailability.
Low tolerance for downtime, where a short, rehearsed switch is preferred over a planned stop.
A need for a rollback window, because the source can stay in service while you check the target.
Teams that can run two environments in parallel for the duration of the sync.

It demands more from workers and clients. Both endpoints must be reachable during the window, credentials and namespace access must be ready for the target before the switch, and workers should be able to change connection settings without a code change. Control duplicate execution by agreeing on exactly when the source stops starting new work.

Before choosing, confirm in Temporal's current migration documentation which server versions, namespace settings and visibility configurations the replication path supports, what it replicates, and how it handles workflows started during the sync.

How the migration runs from inventory through decommission

This sequence moves each namespace from the self-hosted Temporal Service to Temporal Cloud in controlled stages, with a written go or no-go decision and a named owner at each gate. It ends with a verified finalize step and a decommissioned cluster.

Inventory namespaces, workflows and dependencies
The platform owner records every namespace, workflow type, worker fleet, codec and authentication setting, and visibility dependency on the self-hosted cluster. Note which namespaces use a custom codec server, mTLS, a ClaimMapper or an Authorizer, because each setting must be reproduced in Temporal Cloud. Each namespace is assigned a business owner. The step closes with a signed inventory and a go or no-go decision from the migration sponsor to begin the work.
Bring the self-hosted server to a supported version
The platform engineering lead upgrades the self-hosted server one minor version at a time, moving to the latest patch of each current minor line first. Schema upgrades run before server upgrades when the release notes call for them. Check the Helm chart version against the server image before each step. The step closes when the cluster runs a version the team has confirmed as supported for the migration tooling, with a go or no-go decision recorded by the platform owner.
Run a pilot on a non-production namespace
The application lead and platform engineer replicate one non-production namespace with representative workflows, including long-running, signal-heavy, and child-workflow patterns. They confirm that workers connect with the same codec, authentication and task queue behavior, and that visibility queries return expected results. Record every gap, such as a setting that differs between the two environments. The pilot closes with a written go or no-go decision from the platform owner before any production namespace is scheduled.
Estimate action volume and storage
The finance and platform teams use production history from the self-hosted cluster to estimate actions and active and retained storage for each namespace. Temporal Cloud pay-as-you-go pricing is published per million actions and per GB-hour for active and retained storage, so the estimate should use those units. Ask the vendor to confirm how replication traffic and retained history are counted. The step closes with a volume estimate signed off by the budget owner.
Run a parallel period under the chosen cutover approach
The team runs the chosen cutover approach, either automated replication or a manual cutover, with both environments active for a defined period agreed in advance. The migration engineer compares workflow outcomes, task latency, error rates and visibility results between the two clusters. Confirm with the vendor how replication behaves for each namespace before starting. The period ends with a parallel-run report reviewed by the application leads and a go or no-go decision from the migration lead.
Cut over traffic namespace by namespace
The migration lead moves client and worker traffic for one namespace at a time, starting with the lowest-risk namespace from the inventory. Each application team switches its workers and clients to Temporal Cloud endpoints and confirms that new workflows start and complete there. The on-call engineer watches error rates and stuck tasks before the next namespace moves. Each namespace closes with a written go or no-go decision from its business owner.
Finalize only after verification
Finalize is irreversible, so it runs only after every namespace has passed verification and no workflows remain open on the self-hosted cluster. The security lead confirms that access controls and encryption match the inventory, and the platform owner confirms that no traffic still reaches the old endpoints. Ask the vendor to explain exactly what finalize changes for your replication setup before the decision is made. The step closes with a go decision signed by the migration sponsor and the security lead.
Decommission the self-hosted cluster
After finalize, the platform team shuts down the self-hosted Temporal services, removes persistence and advanced visibility stores according to the retention rules agreed with the data owner, and revokes related credentials and network rules. Keep backups for the period your records policy requires. The step closes with a decommission record listing each removed component, its owner and the date it was removed, reviewed by the platform owner.

What drives the cost and duration of the move

This table compares the drivers that change the effort and recurring cost of moving namespaces from a self-hosted Temporal Service to Temporal Cloud. Read each row as a question to answer during inventory, then use the last column to shape your quote request. Costs are marked one-time for inventory, pilot and cutover work, or recurring for Temporal Cloud consumption and support tier.

Driver	Why it changes the effort	One-time or recurring	What to ask for in a quote
Namespace count	Each namespace needs its own cutover plan, testing and owner sign-off, so effort grows with the number of namespaces moved.	One-time	A per-namespace migration plan, the proposed move order and the non-production namespaces used for testing.
Running and long-lived workflow volume	Open executions must finish on the old service or be carried across, which sets the cutover window and rollback options.	One-time	An inventory of running and long-lived workflows by namespace and the cutover approach proposed for each.
Action volume	Temporal Cloud bills by actions. Pay-as-you-go starts at 50 US dollars per million actions (Temporal pricing page), so history and worker traffic set the spend.	Recurring	An action estimate per namespace from recent history, the growth assumptions used and the pricing model quoted.
Storage size and retention	Active and retained storage are billed per GB-hour, so history size and retention settings drive the bill. Active storage starts at 0.042 US dollars per GB-hour and retained storage at 0.00105 (Temporal pricing page).	Recurring	Current persistence size, retention settings and the storage assumptions behind the estimate for each namespace.
Workflow code and versioning complexity	Workflows with many versions, patches or determinism constraints need more replay and regression testing before cutover.	One-time	A versioning review of workflow code and a test plan that replays existing histories against Temporal Cloud.
Worker fleets, languages and codec setup	Each worker fleet and SDK language must connect to Temporal Cloud with the same payload codec and encryption setup, which adds configuration and test cycles.	One-time	A list of worker fleets and languages, the codec and key handling changes, and the test sequence for each fleet.
Identity, SSO and network connectivity	Temporal Cloud SSO and private connectivity replace the self-hosted mTLS, ClaimMapper and network rules, so access design and connectivity testing are new work.	One-time	Confirmation of supported SSO options, the private connectivity method proposed and the access model mapped to namespace roles.
Observability, alerting and compliance evidence	Dashboards, alerts and audit evidence built for the self-hosted deployment must be rebuilt for the managed service and documented for assessors.	One-time	A list of dashboards and alerts to rebuild, the evidence pack for assessors and the owner for each control record.
Pilot scope and support tier	The pilot on non-production namespaces is one-time work. Support recurs, with the Business add-on starting at 500 US dollars per month (Temporal pricing page), and Enterprise and Mission Critical quoted by sales.	One-time pilot, recurring support	The pilot scope and exit criteria, the support tier proposed and the P0 response times included in that tier.

How Temporal Cloud pricing shapes the migration estimate

Temporal Cloud pricing has several separate cost lines, and the migration estimate needs to carry each one. Temporal's pay-as-you-go pricing starts at 50 US dollars per million actions, with active storage at 0.042 US dollars per GB-hour and retained storage at 0.00105 US dollars per GB-hour. These figures are list starting points from Temporal's pricing page. They are not a quote for your account. Actions recur with your workflow volume, so the action count for the namespaces you plan to move is usually the largest variable. Count actions from your current self-hosted history over a representative period that includes your busiest months, not from a single quiet week.

Storage is billed by time as well as by size, so a namespace's footprint at cutover is only part of the picture. Active storage covers the data for workflows that are still running, and retained storage covers data kept after workflows close, for as long as the namespace retention setting requires. A longer retention period keeps retained storage accruing for the life of that data. Ask Temporal how it measures storage for your namespaces and which retention settings it assumed. Also ask how any overlap period is billed, because during replication or a manual cutover, your self-hosted service and Temporal Cloud may both hold workflow data for a time.

The service level is the second recurring decision. Temporal Cloud's pay-as-you-go pricing lists a 99.9% SLA, or 99.99% with high availability. Match the tier to how much your business depends on each namespace and to the availability target your self-hosted deployment currently meets in practice. Confirm with Temporal whether the high availability option changes the price for your volume, and confirm which SLA applies to each namespace you migrate. The same pricing page lists SAML SSO under pay-as-you-go, so identity planning for the Cloud namespaces does not by itself require a support add-on. Confirm that the SSO setup you need is covered on the plan you select.

Support add-ons are a separate recurring cost. Temporal lists Business from 500 US dollars per month, with a 2-hour P0 response during business hours. Enterprise and Mission Critical are quoted by sales, offer 30-minute or 15-minute P0 response around the clock, and include SCIM for identity provisioning. Compare these tiers with your current on-call model. If your self-hosted platform is covered by your own staff around the clock, the question is whether a vendor response target adds enough value to justify the monthly charge. If it is not, the add-on may be needed before you cut over production namespaces. Keep the support tier in the annual budget alongside usage.

DeployOpen does not set or estimate Temporal Cloud prices. Our implementation quote covers the migration work, and Temporal's commercial terms cover the service. To reconcile the two, request the following from Temporal in writing for your expected volume: an action estimate for each namespace, a storage estimate that states the retention settings used, the SLA tier and the cost of high availability, the support tier and whether SCIM is included, any charges for overlap or replication during migration, and the commitment term and any minimums. Attach that quote to the migration scope so the cutover plan and the cost assumptions match.

What usually goes wrong in a Temporal Cloud move and how to prevent it

Most difficult Temporal Cloud moves trace back to a few predictable gaps: a cutover that happens before the evidence supports it, clients that keep calling the old cluster, and workflow code, keys or identities that do not carry over intact. Each card pairs one risk with a check you can place in the migration sequence. Visibility query differences and server version prerequisites are covered in the prerequisite and test steps.

Finalizing before the parallel run is verified

Finalize is irreversible, so it should follow a parallel run whose results you have compared against the self-hosted namespace. Before finalizing, confirm that workflow counts, open and closed states, and sampled workflow results match on both sides across a period that covers your normal business cycle. Record who signs off and which evidence they reviewed. If a discrepancy appears, pause and investigate before finalizing on the planned date.

Workers and clients on the old endpoint

Workers, starters, signal senders and any service calling the self-hosted frontend keep connecting to the old address after cutover unless every configuration changes. Build an inventory of each worker deployment, client configuration, certificate reference and CI job that points at the namespace or endpoint. Switch them in a planned order, confirm that new executions appear in the Temporal Cloud namespace, and keep the self-hosted cluster reachable until the inventory shows no remaining traffic.

Workflow code changes breaking in-flight executions

Workflows running during the move replay against the code that executes them. If a deployment changes workflow logic without versioning, replay can fail with a non-determinism error. Freeze workflow code changes for the migration window, or apply Temporal's versioning APIs before the first target worker connects. Test replay of recent histories exported from the non-production namespace using the exact worker build that will run after cutover.

Codec and encryption keys missing on the new side

If payloads are encrypted through a custom codec, every worker and codec server that decrypts them needs the same keys in the target environment. Missing or mismatched keys can leave workflows unable to read inputs and results, often only after cutover, when older histories are read. Inventory each codec and key reference, confirm the codec server endpoint and access policy for the target namespace, and test decryption of a sample history from the self-hosted namespace before any worker switches.

Identity and role mapping gaps

Self-hosted Temporal may depend on a ClaimMapper that maps JWT or certificate claims to namespace roles, plus an Authorizer plugin for access decisions. Each user, service account and application needs an explicit role in the target environment before cutover. Map every existing claim-to-role rule, confirm SAML SSO for Web UI users, and test that each worker identity can start, signal and read only the namespaces it needs. Confirm with Temporal which plan includes SCIM if you rely on it.

Underestimating action volume

Temporal Cloud is metered by actions, and pay-as-you-go pricing starts at 50 US dollars per million actions, according to the Temporal pricing page. Parallel runs add load on both sides, and the replication or manual cutover approach can generate more actions than steady-state operations suggest. Measure action counts from your self-hosted namespaces over a representative period, estimate the parallel-run duration, and ask Temporal to confirm how actions are counted for your workload before you commit.

What do teams ask before moving self-hosted Temporal to Temporal Cloud?

What drives the cost of moving self-hosted Temporal to Temporal Cloud?

Migration cost is driven by how many namespaces move, how much workflow state must carry over, how many workers and clients must be repointed, and how much testing your team requires before cutover. DeployOpen's work is fixed-scope, so the written scope should list each of these items separately. The recurring cost is Temporal Cloud itself. Temporal's pricing page lists pay-as-you-go pricing starting at 50 US dollars per million actions, with active storage at 0.042 US dollars per GB-hour and retained storage at 0.00105 US dollars per GB-hour. Support add-ons are priced separately, with Business starting at 500 US dollars per month. Ask Temporal for a quote based on your action volume and storage profile, and confirm whether self-hosted infrastructure costs end at cutover or overlap during a transition period.

How long does a self-hosted Temporal migration take?

The duration depends on scope, so no fixed timeline applies to every team. It depends on how many namespaces move, how much history must carry over, and whether you use automated replication or a manual cutover. Each namespace follows its own sequence: confirm prerequisites, test on a non-production namespace, cut over, then complete the finalize step. Teams with a few low-volume namespaces and a single owner usually move faster than teams with many namespaces across several business units, because each additional namespace adds testing and sign-off. Schedule risk also comes from change windows and from worker redeployments that must follow cutover. A short discovery step can inventory namespaces and dependencies, and the written scope then sets the timeline. Confirm with Temporal which migration approach fits your namespaces and server version before committing to dates.

Can our own engineers migrate self-hosted Temporal without a partner?

Yes, if your team already has Temporal operations experience and the capacity to run the work. The migration needs people who know your namespaces, your worker code, and how your workflows are versioned, along with people who can complete the server prerequisites on your current deployment. Teams that have not run Temporal in production, or that depend on one person who holds all the knowledge, often find cutover and rollback planning hardest to staff. A partner adds capacity and an independent review of the plan under a written scope. Before deciding, name who owns each cutover, who signs off on test results, and who is on call during the change window. Any empty role is the gap to fill, either internally or through a partner.

What do our engineers and security staff need to provide?

Engineers need access to the current server configuration, persistence and visibility stores, deployment manifests, worker code, and a list of namespaces. They also need test workers that can run against the new endpoint and time in change windows for cutover. Security staff should review authentication and authorization before and after the move. If no Authorizer is configured, self-hosted Temporal uses a default that allows every API request without authentication or access control, so confirm your current access model first. Security staff should also review the network path between your workers and Temporal Cloud, how client certificates or JWT claims map to namespace roles, and how payload encryption through custom codecs works with the cloud service. Temporal's pricing page lists SAML SSO for Temporal Cloud, so confirm how identity will be configured for your administrators.

Can the finalize step be reversed after moving Temporal namespaces?

No. The finalize step is irreversible, so treat it as the point of no return and plan for it before it happens. Before finalize, keep the self-hosted namespace available, confirm that workers connect to the Temporal Cloud endpoint, and verify workflow completion, retries, timers, and visibility queries during the test window. Ask Temporal to document exactly what state exists before finalize, what rollback options remain before that point, and whether any data stays in the self-hosted service afterward. Require a written go or no-go decision from the business owner and the platform owner. Do not schedule finalize on the same day as the first production cutover, so that problems found during cutover can be investigated first.

Which self-hosted Temporal version should we run before migrating?

Run the latest patch of the minor version your environment already supports, and upgrade one minor version at a time before migrating. Temporal's upgrade guidance says backward compatibility is guaranteed only between two successive minor versions, so skipping several minors adds risk. Schema upgrades must run before server upgrades when release notes call for them. Temporal's GitHub releases list Server v1.32.1, published on October 8, 2026, with patch releases v1.31.4 and v1.30.8 published on October 12, 2026 for earlier minor lines. Check Helm chart versions too, since chart versions below 0.73.1 do not work with server images 1.30 and later. Use the release notes and upgrade documentation to choose the target, then confirm with Temporal which server versions the migration supports.

Do we need a pilot on non-production namespaces first?

Plan for one. Temporal's migration guidance covers testing on non-production namespaces before production cutover, so a pilot is the expected path. Confirm the exact requirement with Temporal for your server version and chosen migration method. A useful pilot moves one representative namespace, runs production-like workloads through test workers, checks visibility queries, retries, timers, and payload handling, and rehearses both cutover and rollback. Write pass criteria before the pilot starts. Pilot length depends on how many workflow types the namespace runs and how long its longest workflows stay open, so ask for the test plan and exit criteria to be part of the written scope.

How DeployOpen scopes, delivers and supports the migration

DeployOpen starts each migration of self-hosted Temporal to Temporal Cloud with a written inventory of the namespaces, workflow and activity volume, visibility use and server version your team runs today. Work proceeds in your environment and in non-production namespaces first, with the cutover approach and the irreversible finalize step agreed before anything moves. Engagements are fixed-scope, and ongoing support is available as a retainer.

How we scope

The written scope lists each namespace to move, its workflow and action volume, and its visibility and access requirements.
It records whether each namespace moves by automated replication or a manual cutover, with the reason for the choice.
Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before the work starts.

How we build

We confirm the self-hosted server version and step it up one minor version at a time where needed.
We rehearse each cutover on non-production namespaces and record the timings, errors and recovery steps observed.
Client applications and workers are pointed at the Cloud namespace only after the rehearsal results are reviewed.

How we hand over

The finalize step is irreversible, so it runs only after the client signs off on the cutover checklist.
Handover covers a runbook for namespace access, worker configuration, and the self-hosted decommission sequence.
Access is set up through your identity provider, using the SAML SSO that Temporal Cloud offers, and documented.

How we support

Retainers cover ongoing support, upgrades and testing for the Cloud namespaces and any self-hosted components still in use.
Ask whether a Temporal Cloud support add-on is needed, since its response times depend on the tier chosen.
Quotes should separate one-time migration work from recurring Cloud action, storage and support charges.