Temporal workflow versioning and deployment guide

How do teams change Temporal workflow code while executions are still running?

Changes to Temporal workflow code must stay deterministic for executions already in progress, and teams handle this with patching or versioning, replay testing and controlled worker rollouts. The reason is that Temporal does not store a workflow's state as a snapshot. It stores the event history, and when a worker resumes an execution, it runs the workflow code again from the start and checks that the code issues the same commands in the same order as the recorded history. If it does not, the execution fails with a non-determinism error. A change that looks harmless, such as reordering two activity calls, adding a timer before an existing one, or changing a condition that gates a call, can break every open execution that started before it shipped.

Three factors make this harder than it looks. First, the history of every running execution is replayed by whatever code the worker runs, so the new code must reproduce decisions that the old code made. Second, a change can alter command order in ways that are not obvious from a diff, especially when it touches loops, conditional branches, or non-deterministic calls such as reading the clock or generating random values directly in workflow code. Third, old workers may still be polling the same task queue after new workers start, so one deployment can have two code versions handling tasks at the same time. Teams should plan for that overlap as a period with both versions live, not as an instant switch.

Patching and versioning are the two main tools for branching. A patch marks a code path so that executions started before the change keep the old branch while new executions take the new one. The exact API differs by SDK language, so read the documentation for your SDK and confirm which features it and your Temporal Server release support before you design around them. Worker versioning, where workers are tagged with a build identifier and task routing is set per workflow, is a deployment-level alternative that keeps each execution on the code version that started it. Whichever tool you choose, record the decision for each workflow type, because patch markers or build routing must remain in place until no execution still needs the old branch.

Before any rollout, replay recorded histories from production through the candidate code. Export or sample histories for each open workflow type, run them against a worker built from the new code, and treat any non-determinism failure as a release blocker. Then roll out in stages: start new workers on the task queue only after replay passes, watch for workflow task failures and stuck executions, and drain old workers before stopping them. Plan the retirement step too. Remove a patch branch only after visibility queries confirm that no open execution started before the change. Ask your team who owns that check and how long each long-running workflow type may stay open, because that answer sets how long the old code must remain deployed.

Which Temporal parts a workflow change touches

A workflow change reaches further than the code file it sits in. Each part below has its own compatibility rule, and a change that is safe for one part can break another. Check all six before deciding how to roll a change out.

Workflow definitions in worker code

The workflow definition is the code that decides what a workflow does next, step by step. Any edit to its control flow, such as reordering calls, adding a branch or changing how a result is used, changes the path a replay takes. Running executions were recorded against the old path, so the new code must still reach the same decisions for them. Check each edit against the executions still open, not just new starts. Confirm the exact versioning mechanism in the SDK documentation for your language.

Workflow history replayed on recovery

Temporal stores the event history of each execution and rebuilds workflow state by replaying that history when a worker resumes it. The history is a fixed record of past decisions, so it cannot be edited to match new code. Compatibility means that the current code, when given a history recorded by older code, reaches the same decisions. Replay testing against captured histories from your own environment is the main way to catch a break before rollout. Confirm how your SDK supports replay testing.

Task queues that workers poll

Workers poll task queues for workflow and activity tasks, and the queue name links each task to the workers allowed to run it. Renaming a queue or moving a workflow type to a new queue can leave open executions waiting on a queue that no worker polls. Changing which workers sit behind a queue also changes which code version runs each task. Plan queue changes so that workers for every version still in use keep polling the queues where their executions wait. Confirm routing options in your SDK documentation.

Worker build or image

The worker build is the packaged binary or container image that holds the workflow and activity code and the SDK. Each new build is a new code version, so a rollout is really a change in which build polls which queue. Keep every build traceable to a specific commit so you can tell which version handled a given execution. Old builds must stay runnable until no open execution depends on them. Retire them only after that check passes.

Temporal Server version and schema

The Temporal Server stores workflow history, dispatches tasks to workers and manages its own database schema. A server upgrade changes how it stores and routes that data, so it has a separate compatibility rule: upgrade one minor version at a time, moving to the latest patch of the current minor first. Schema changes must run before the server upgrade when the release notes call for them. If you deploy with Helm, chart versions below 0.73.1 do not work with server images 1.30 and later.

SDK version in each worker

Each worker links a Temporal SDK for its language, and the SDK determines how workflow code is executed and replayed. Workers on different SDK versions can run side by side during a rollout, so the SDK version belongs in the compatibility check alongside the application code. An SDK upgrade can change replay behavior, so test it against captured histories before it reaches production workers. Confirm which SDK versions support your server version in the documentation for your language.

Choosing between patching, versioning and new workflow types

This table compares the main ways to change a workflow while executions are running, with replay testing and retirement as the checks that connect them. Read each row for when the option fits, what it leaves your team to operate, and which SDK documentation to confirm before choosing. The main takeaway is that the right option depends on how long existing executions live and whether the change alters the sequence of commands a workflow issues.

Option	When it fits	Operational cost	Confirm in SDK docs
In-place patching with a version marker	A small logic change in flight, such as one added activity, where old executions must keep their original path.	Marker branches stay in code until no open execution needs the old path. Tests must cover both paths.	Patch API names, how the marker is recorded in history, and the removal steps for your language SDK.
New build or worker set versioning	Larger or structural changes where old workers can stay running for executions pinned to them.	Operators run more than one worker set. Routing, pinning and drain timing must be watched until old executions close.	Whether build-ID routing and pinning are supported for your SDK and server versions, and how drained workers are retired.
New workflow type for new work	Business process changes where new starts can use new logic and existing runs finish on the old code.	Two code paths and two type names are maintained. Callers must switch to the new type, and the old type stays until its last run closes.	How starters select a workflow type, and how to count open executions by type in visibility.
Terminate or migrate running executions	Executions are invalid under the new rules, or the business accepts compensation or restart of that work.	Progress in flight may be lost unless compensated. Migration scripts need testing against captured histories and run in batches.	Whether the CLI or SDK offers batch termination or reset, and exactly which state is preserved.
Replay testing before rollout	Any change that touches workflow code, whichever option is chosen.	Production histories become test fixtures that need refreshing as code changes. Nondeterminism errors surface here, not in production.	How to export workflow histories and run the replayer in your SDK language and test framework.
Retiring old code paths	After the last execution on the old version has closed and no replay of it can occur.	Cleanup needs visibility queries to prove no open runs remain. Removing code early can break replay of older histories.	The retirement criteria the SDK documents for markers and build IDs, and any deprecation period it recommends.

How to roll out a workflow change without breaking running executions

This sequence lets a team change Temporal workflow code while executions that started on the old code keep running correctly. Each step ends with a check, so old and new code are shown to agree before any old path is removed. Platform engineers and the developers who own the workflow code usually share the work.

Inventory running and retained executions
List every workflow type in the affected namespaces, with the code version or build each open execution started on and the retention period for closed ones. Use the visibility queries your Temporal deployment supports to group open and recently closed executions by workflow type and version. Platform engineers usually run this with the developers who own the workflow code, since they know which types are in use. Done means you have a written inventory that shows every version still in use, the executions that may wait on timers or signals for a long time, and the owner of each workflow type.
Classify the change as compatible or breaking
Compare the old and new workflow definitions and decide whether replaying existing histories would still produce the same commands. Reordering, removing or changing the type of an activity, timer, signal handler or child workflow call usually counts as breaking, because replay of a recorded event history would no longer match. Adding a new branch that only new executions reach is usually compatible. Developers and a reviewer who knows the SDK should make this call together and record it in the change ticket. Check: every changed workflow type has a written classification, and each breaking change has a versioning method assigned in the next step.
Choose and implement the versioning method
Pick the mechanism your SDK supports for branching workflow code by version. One option is an in-code patch marker that old executions skip during replay, which keeps a single code path that handles both old and new histories. Another is worker versioning that pins executions to a build, which keeps old code in separate workers. Confirm the exact API and its behavior in the documentation for your SDK version before writing the change. Check: the change passes code review, and the review names the marker or build identifier and the condition under which old executions take the old branch.
Add replay tests against recorded histories
Export a sample of production workflow histories for the affected types, including long-running and recently closed executions, and store them as fixtures in the test suite. Run the new workflow code against each history with the SDK replayer, so a nondeterministic change fails in CI before deployment. Include histories that started before each patch marker or build change, since those are the most likely to break. Developers own the test suite, and the platform team usually manages access to production histories under the organization's data handling rules. Check: replay of the sampled production histories passes on the new code, and the test blocks merge when it fails.
Deploy new workers alongside old ones
Start the new worker deployment on the task queue or build strategy you chose in the versioning step, while the existing workers keep polling. Old workers continue to complete executions that started on old code, and new workers take work according to the routing rules you configured. Confirm that both worker sets connect to the same namespace and that metrics show polling from each version. Check: both versions show healthy task polling, and a test workflow started on each version completes end to end in a non-production environment before any production traffic moves.
Shift new starts to the new code
Route new workflow starts to the new version by updating the start path, the build assignment or the default version for the workflow type. Make the change in small steps where your mechanism allows, and watch failure rates, retries and workflow task latency on the new workers. Keep the old workers running so that rollback only requires routing new starts back to the old version. Check: all new executions of the type start on the new version, confirmed with the visibility query from the inventory step.
Let old executions drain
Wait while executions started on the old version finish on their own. Some may run for a long time because they wait on timers, signals or human steps, so set no removal date based on typical run times alone. Re-run the inventory query on a schedule and track the open execution count for each old version. Signal, cancel or terminate an execution only when the business owner approves it, and record each decision. Check: the open execution count for the old version is zero, confirmed by the same visibility query, before the next step begins.
Retire old code paths and workers
Remove the old branches, patch markers or build assignments from the workflow code once no open execution depends on them. Then scale down and delete the old workers, and keep them available until the removal is merged and deployed in case a late execution needs them. Update runbooks and replay test fixtures so they reflect the new baseline. Check: the old version has no open executions, the replay suite passes without the retired paths, and the old worker deployment no longer exists in the environment and the inventory is updated.

Why replay testing catches nondeterminism before production

Replay testing catches workflow changes that would make Temporal rebuild a running execution differently from how it originally ran. When a worker resumes a workflow, it re-executes the workflow code against the recorded event history, and the commands the new code produces must match what that history already contains. Reordering activity calls, adding or removing a timer, changing the order in which signals are awaited, or altering a branch that depends on earlier results can all break this match. The failure appears only on executions that were already in flight, which may be days or months old, so a normal test suite will usually miss it. A replay test moves that discovery into the pull request, where the change can still be fixed.

A replay test set starts with histories. Export the event histories for the workflow types you are changing, or sample running and recently closed executions from the namespace. Choose a spread: executions that stopped early, executions waiting on a long timer, executions that already received signals, and executions that went through retries or child workflows. Store the selected histories as fixture files in the same repository as the workflow code, and record which SDK version and workflow type each one came from. Before exporting, confirm with your data governance owner how histories containing business payloads are handled, and whether a codec or redaction step is required. Also confirm how your chosen SDK loads histories for its replayer.

Certain kinds of change fail replay more often than others. Reordering, inserting or deleting activities, timers, child workflows or signal waits usually shifts the command sequence that history expects. Branching on values that the workflow did not obtain through Temporal APIs, such as local time, random values or environment reads, can produce different decisions on each run. Changes to the arguments or options passed to commands may also fail, depending on how your SDK compares commands. Treat any edit to the body of a workflow function as suspect until the replay suite has run against representative histories, and do not assume that a change limited to activity implementations is safe, because activities are not replayed.

Wire the replay suite into CI as a required check for any pull request that touches workflow packages. The job should build the workflow code with the same SDK version that the workers will run, load every fixture history, and fail the build on the first nondeterminism error. Keep the fixture set current by adding histories whenever a new workflow path ships, and by reviewing the set when the SDK is upgraded. Ask your team to confirm that the check reports which history and which workflow type failed, because that detail decides how quickly an engineer can act on the result.

When a replay failure appears, choose one of three responses and record the decision. You can add a guard that branches on a version marker, so histories recorded before the change follow the old path while new executions follow the new one. You can version the workflow code with the SDK's versioning support, which has similar effect and is easier to reason about when several changes stack up. Or you can treat the change as breaking, keep the old worker build running until existing executions finish, and route new starts to the new code. Guards and versions add code that someone must remove later, so put a retirement plan in the ticket. The right choice depends on how long your longest executions run and how much business risk a stalled process carries.

What drives the effort of versioning and worker rollouts

This table lists the factors that change how much work a Temporal versioning and worker rollout takes, why each one matters, and how to keep it manageable. Read each row as a lever: the first column names the driver, the middle column explains its effect on effort, and the last column gives the practice that reduces it. The main takeaway is that long-lived executions and frequent changes compound, so controlling them early lowers the ongoing cost more than any single rollout tactic.

Driver	Why it raises effort or cost	How to keep it down
Workflow types and open executions	Each workflow type with running executions must stay compatible with every code path that can replay it. More types and more open executions mean more versions to reason about and more replay checks before each release.	Limit the number of active workflow types, group related logic, and track open execution counts per type so the team knows which versions are still in use.
Execution lifetime (days, months or longer)	Long-running executions keep old code paths alive for as long as they run, so patches and version markers must stay in the code and the team must maintain them across many releases.	Prefer shorter-lived workflows where the business process allows it, use Continue-As-New to bound history, and set a retirement date for each patch once no open executions depend on it.
Change frequency per quarter	Every change to workflow logic needs a compatibility decision, a replay test run and a rollout plan. A high change rate multiplies this review work and raises the chance of an unplanned incompatibility.	Batch workflow logic changes into scheduled releases, classify each change as compatible or breaking before it is merged, and keep a log of every versioning decision.
Number of environments and workers	Each environment needs its own worker fleet, configuration and rollout sequence. Running old and new worker versions side by side during a deployment adds coordination work and more places where a version mismatch can occur.	Standardize worker images and configuration across environments, roll out in a fixed order from lower to higher environments, and confirm worker build IDs or versions in each one before shifting traffic.
Depth of the replay test corpus	Replay tests confirm that new code can still process recorded histories. A thin corpus leaves gaps that surface only in production, while a deep corpus takes time to build and keep current as histories change.	Capture histories from representative executions in each active version, store them with the code, and run the replay suite automatically in the pipeline on every change to workflow code.
Audit trail requirements for code changes	Regulated organizations often need evidence of who approved each workflow change, what tests ran and which version reached each environment. Assembling that evidence by hand adds recurring effort at every release.	Tie versioning decisions and replay results to the same change records used for other production changes, and confirm with your assessor or internal audit which artifacts they expect to see.
Integration with existing CI/CD	If the Temporal worker pipeline is separate from the organization's standard pipeline, the team must maintain two release processes, duplicate approval steps and extra tooling for replay tests.	Add replay tests and worker version checks as stages in the existing pipeline, reuse the same approval gates, and document one standard rollout runbook that every team follows.
Standard rollout runbook	Without a written runbook, each release depends on the knowledge of whoever runs it, which increases mistakes, slows incident response and makes audits harder to answer.	Write a runbook covering pre-release replay checks, the rollout sequence, the rollback path and the criteria for retiring an old version, then review it after each release that uses it.

How worker rollouts differ by deployment model

On a single host, the Temporal Server, its database and every worker often share one machine, started with Docker Compose or Go binaries. The rollout is simple to describe, but a change to one component can affect all the others, so each release needs a clear record of which server image, SDK version and workflow code version is running.

Building: Package each worker as a container image or binary tagged with its SDK version and the workflow code version it contains.
Side by side: Run the new worker set beside the old one only when your versioning approach keeps both safe on the same task queue. Otherwise, plan a short window for the switch.
Draining: Send a stop signal and let in-flight tasks finish within the SDK's graceful shutdown period before removing the container.
Server constraint: The Compose file pins the server image. Changing that tag is a separate server upgrade with its own schema and minor-version order.

Before each rollout, confirm that the server image tag, SDK version and workflow code version are recorded together and that the previous set can be restarted.

How to test that old executions finish and new ones fail safely

Each check in the verification plan should have a stated meaning for failure before the rollout starts. The first check is replay testing. Run the changed workflow code against histories that look like production, including executions that started before the change and have already passed the branch points the change touches. A nondeterminism error here means the new code would fail when a worker replays that history, so the rollout halts until the change is patched or versioned correctly. Ask your team or partner which history sources your SDK's replay tooling accepts and how histories are exported from the production namespace without exposing sensitive payloads.

The second check is a staging run. Start a set of executions on the current build, deploy the new worker build to staging, and let those executions advance to completion. Include long-running executions that are waiting on timers or signals, since those cross the change most often. A workflow that fails with a nondeterminism error, or an execution that stops advancing past the point where it should continue, is a halt condition. A single activity failure caused by a downstream dependency in staging is usually noise to triage, not a reason to halt, provided the workflow history shows the workflow code still progressed as designed.

The third check confirms that new workers poll only the task queues and namespaces they were meant to poll. Verify the worker configuration, the deployment labels or build identifiers your SDK and server version support, and that old workers drain as planned. A new worker that picks up tasks for executions still running an unpatched code path is a halt condition. A worker polling an unexpected queue that receives no tasks is lower risk, but it signals a misconfigured deployment and should be corrected before cutover. Confirm which worker versioning features your SDK version and Temporal Server version support before designing this check.

The fourth check rehearses rollback with executions in flight. After rolling back in staging, confirm that every in-flight execution still replays on the restored build and that the new code wrote nothing the old code cannot read. Any execution that cannot be recovered after rollback is a critical defect, and the rollout must not proceed. Rollback of worker code is separate from rollback of the Temporal Server. Schema upgrades must run before server upgrades when release notes call for them, so confirm the reverse path for each component before the production change.

The fifth check sets alerts for workflow failures, nondeterminism errors, and executions that stop progressing after deploy. Route these alerts to the on-call path before cutover, and agree in advance which signals trigger a rollback decision. A nondeterminism alert in the first hours after deploy should lead to a rollback decision, not repeated retries of the same workflow tasks. Confirm which metrics your observability stack exposes from the Temporal Server and workers, and set the alert thresholds with the people who will be paged.

What to monitor, document and retire after each change

A versioning change is not finished when the new worker is live. Operations need to see which workflow code is still running, whether old and new workers are draining cleanly, and whether the decisions behind the change are recorded well enough for the next engineer. The cards below cover what to watch, what to write down, and when old branches can be removed safely.

Monitor failures and backlog per version

Break workflow failures, workflow task failures and task queue backlog down by build or worker version, not only by task queue. A non-determinism error or a stuck task usually shows up first as a spike on one version's workers. Set alerts on schedule-to-start latency and backlog age for each queue that serves more than one version, and confirm that your observability stack can filter Temporal metrics by build ID or deployment version label.

Check worker health and capacity

Track CPU, memory, poll success and worker count for each deployed version separately. During a rollout, old and new workers both poll the same queues, so a slow or crashing version can starve the other. Confirm with your SDK and Temporal documentation which worker metrics and build-ID routing options are available for your language and server version before you rely on them in alerts.

Record which versions are still in use

Keep a live inventory of every workflow code version that has open executions, the worker build that runs it, and the namespace and task queue it uses. Use the visibility store to query open workflows by version marker or build ID where your setup records them. Without this inventory, nobody can tell whether a branch is safe to delete, and the answer to that question should come from a query, not from memory.

Keep a versioning decisions changelog

Log each change to workflow logic with the reason, the approach used (patching, explicit versioning or a new workflow type), the affected workflow types, the date the change shipped and the owner. Store it next to the code so reviewers see it in the same pull request. Entries should explain why a patch was chosen over a new workflow type, because that reasoning is what gets lost first.

Maintain the replay test corpus

Save histories from representative executions, including long-running and failed ones, and replay them against every new worker build before deployment. Add a history to the corpus whenever a production replay failure is found and fixed. Assign an owner to the corpus, review it when workflow types change, and keep it in source control so a failing replay can be traced to the commit that introduced it.

Back up and verify persistence before large rollouts

Before a rollout that changes many workflow types or affects long-running executions, take a verified backup of the persistence store that holds execution history, and confirm the restore procedure works on a copy. Check the store version against the Temporal persistence documentation, because supported databases and versions are listed there. Record the backup time, location and the person who verified it in the changelog entry for that rollout.

Retire old version branches safely

Remove an old version branch only after the visibility store shows zero open executions on that version, the replay corpus no longer depends on it, and no retry or timer path could resume it. Work through a written checklist: confirm the query result, confirm workers for that version are stopped, remove the branch in a separate change, run replay tests again, and update the inventory and changelog. Keep the removal separate from the feature change so a rollback stays simple.

How much effort does safe workflow versioning take, and what must we supply?

How much effort does safe workflow versioning take for a Temporal project?

The effort depends mainly on how many workflow types are live, how long each one runs, how many worker fleets and SDK languages are involved, and how much replay testing already exists. Main drivers:

Number of workflow types with executions in flight
Longest execution lifetime per type
Quality of existing history samples for replay tests
Number of environments and worker deployments
Change frequency and the review process around it

Setup work, such as the inventory, test harness and deployment strategy, is largely one-time. Each later workflow change repeats part of the process, so ask whether the quote covers the method only or also the first changes. Ask for effort broken down by workflow type.

Can our internal team handle Temporal workflow versioning without a partner?

Yes, a team can do this alone if it already has working Temporal SDK experience, automated tests in CI and enough on-call capacity to watch deployments. The most common gap is replay testing against realistic execution histories, since a change can look correct in unit tests and still fail on a workflow that started weeks earlier. Check three things before deciding: whether someone has built a replay test that runs in CI, whether worker deployments can run old and new code side by side, and whether a named owner can approve each change. If any of these is missing, an outside review of the first versioning cycle can close the gap while your team keeps ownership.

What inputs do we need to provide before versioning work starts?

The work needs direct access to the people and systems that show how your workflows behave in production. Typical inputs:

An inventory of workflow and activity types, with running counts and owners
Workflow histories or sanitized samples for replay testing
CI access to the repositories and pipelines that build and test workers
Access to the environments where workers and the Temporal service run
On-call coverage during cutover windows
A change calendar showing release freezes and business peaks

Histories can contain personal or payment data, so agree on sanitization and access rules in writing before anyone shares them. Confirm the Temporal server and SDK versions in use, since they determine which versioning methods are available.

How long does versioning work take compared with our longest workflows?

The timeline is tied to your longest-running execution, because old code paths must keep working until every execution that started on them has finished or been handled. A workflow that runs for several months keeps its previous logic alive for at least that long unless you decide to terminate, restart or migrate it. Plan the work around three phases: preparing tests and inventory, rolling out the first change with old and new code running together, and retiring old versions after the last execution on them completes. Ask the partner to show how each workflow type maps to a retirement point, and confirm the duration of each phase against your own execution history before agreeing a schedule.

Is patching always required when changing a running Temporal workflow?

No, patching is one of several approaches, not the only one. Code changes that alter the sequence of commands a workflow issues can break replay of executions that already started, so they need a version-aware approach. In-code patching adds branches that keep old executions on their original path. Worker versioning, which routes new executions to a new build, can avoid some in-code branches, but it does not remove the need for replay tests. The right choice depends on the SDK language, the server version and how long your executions live. Confirm which methods your SDK and server versions support before selecting one, and record the decision per workflow type.

What happens to running executions that cannot be migrated safely?

Some executions cannot move to new code without changing their outcome, so each workflow type needs a documented handling rule before cutover. Common options include letting the execution finish on workers that still run the old code, cancelling it with compensating steps, or restarting it with new input after business owners agree. The choice is a business decision as much as a technical one, especially for payments, provisioning or customer-facing processes. Record the rule for each type, the owner who approves it, and the monitoring that shows how many executions are affected during the rollout. Do not retire old workers until this list is complete.

How does Temporal Cloud change versioning responsibilities compared with self-hosting?

Temporal Cloud moves the operation of the Temporal service to the provider, but versioning of your workflow code stays with your team in both models. Your team keeps in both models:

Workflow and activity code, and the decision on how to version it
Replay tests and CI gates
Worker deployment, scaling and rollback
Retirement of old versions

Self-hosting adds:

Server upgrades, made one minor version at a time with any required schema changes first
Helm chart or deployment compatibility checks
Persistence and visibility store operations
On-call coverage for the service itself

The Temporal server is open source under the MIT license, so self-hosting is possible, but the operating work must be budgeted explicitly.

What should a written quote for versioning work include?

A quote should follow from a written scope that names what is covered and what is excluded. DeployOpen does not publish a price list, and most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask that the quote state:

The workflow types and worker fleets in scope
The versioning method for each type and the reason for it
Replay test harness and CI changes delivered
Runbooks, handover sessions and named deliverables
Client inputs, access and on-call assumptions
Which items are one-time and which are ongoing, such as a support retainer
Exclusions, such as server upgrades or new workflow development

Ask for each assumption to be confirmed in writing, so changes in scope can be priced openly.

How DeployOpen scopes, builds and hands over Temporal change management

DeployOpen plans and implements self-hosted open-source platforms inside the client's own infrastructure, including Temporal. For workflow versioning and worker deployments, the work is scoped in writing before it starts, built against the client's running workflow histories, and handed over with runbooks and tests the client's team can operate.

How we scope

Inventory the workflow types, SDK versions and worker fleets that are live today and expected to change.
Agree in writing which versioning approach applies to each workflow type, and which changes need patching instead.
Define the replay test suite, the worker rollout strategy and the criteria for retiring old workflow versions.
Confirm who owns the workflow code, the deployment pipeline and sign-off for production changes on each side.

How we build

Add versioning guards to changed workflow code and check each change against recorded histories with replay tests.
Build worker deployment pipelines that run old and new code side by side while executions drain.
Test rollback paths, including stopping a rollout and keeping workers on the previous build for in-flight runs.
Document each versioning decision so later changes follow the same rules and do not break running executions.

How we hand over

Deliver the change procedure, replay test suite and deployment pipeline with the source in the client's repositories.
Walk the client's engineers through a live versioned change, a failed rollout and a worker retirement.
Record which workflow versions are still in use, when each can be removed and who approves removal.
Provide the written list of open items, owners and the checks to run before the next workflow change.

How we support

Engagements are fixed-scope, and the written scope sets the deliverables and timelines before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer, including review of new workflow changes.
Confirm with DeployOpen which support hours and response terms the retainer includes before signing.
Retainer scope can cover re-running replay tests when the Temporal SDK or server version changes.

Temporal workflow versioning and worker deployments