Why Temporal upgrade planning decides whether a workflow platform stays current
A Temporal upgrade is a sequenced change across the server, the persistence schema, the Helm chart that deploys it, and the worker SDKs that run your workflow code. Most teams with strong Temporal skills can run that sequence in-house, especially when they stay within one or two minor versions of the current release. A partner earns its place when several minor versions must be crossed in one plan, when a support or security deadline sets the calendar, or when the cluster carries business-critical workflows that cannot tolerate a failed step. The platform makes this harder than a typical server upgrade for one reason: workflows are durable. An execution that started months ago may still be running, and its history must be replayed by worker code that matches what the server expects. A server change that looks routine can therefore affect workflows that nobody has touched in weeks. Worker code, server version and schema version have to stay compatible through every step, not just at the end. The upgrade docs for the self-hosted Temporal Server are explicit about the path. Backward compatibility is guaranteed only between two successive minor versions, so the safe route is to move one minor version at a time, landing on the latest patch of each minor line before moving on. Where release notes call for a schema change, the schema upgrade must run before the server upgrade. Planning starts by mapping your current minor version to the target, listing every intermediate release, and checking each release note for schema, configuration and SDK requirements. Chart compatibility adds another constraint. The researched deployment guidance states that Helm chart versions below 0.73.1 do not work with server images 1.30 and later, so a team running an older chart cannot simply change the image tag. Confirm which chart version, which server image and which database and visibility store versions each step needs before the first change is made. Visibility stores deserve the same check, because the supported Elasticsearch, OpenSearch and SQL versions differ by server release. Before committing to an in-house plan, ask four questions: how many minor versions separate you from the target, which deadline governs the work, which workflows would be affected if a step failed, and who will own rollback. The answers determine whether your team can carry the plan alone or whether an outside partner should review the sequence, run a rehearsal on a copy of production data and hold a rollback path ready for each change.
What a Temporal upgrade and support engagement includes
Each card covers one stage of a self-hosted Temporal upgrade, from inventory through handover, followed by the support a retainer can carry after go-live. The stages depend on each other: the inventory shapes the version path, the rehearsal tests the runbook, and the handover records what actually ran.
Current-state inventory
Record the running Temporal Server version, the persistence store and its version, the advanced visibility store, the Helm chart version if Kubernetes is used, and the SDK version in each worker fleet. Helm chart versions below 0.73.1 do not work with server images 1.30 and later, so an older chart is often the first blocker. Also record namespaces, custom codecs, and any Authorizer or ClaimMapper configuration, since these must survive the move. Confirm which facts your environment can supply before any plan is estimated.
Version path and schema plan
Temporal guarantees backward compatibility only between two successive minor versions, so the plan moves one minor line at a time and lands on the latest patch of each minor first. Each step lists its schema changes. Where release notes call for them, schema upgrades run before the server changes. The plan sets the order for Cassandra, PostgreSQL, MySQL and visibility store changes and names the point where the team stops if a step fails.
Staging rehearsal and production runbook
Rehearse every step on a staging copy of the cluster with production-like persistence and visibility stores, data volume and worker fleets. The rehearsal produces measured timings and a list of manual steps, which the production runbook turns into commands, owners and checkpoints. Agree the change window, the go or no-go criteria and the approver for each step before execution. Confirm with your change board whether a rehearsal record is required for production sign-off.
Worker SDK upgrade and compatibility
Workers run your application code, so SDK upgrades are checked separately from server upgrades. Confirm which SDK version each worker fleet runs against the server minor you are moving to, and read the release notes for every language your teams use. Test workflows started on older code, including replay of histories that contain pending activities and timers. Rolling worker deployments should keep old and new versions able to process their own task queues during the change.
Post-upgrade verification and handover
Verification checks server health, frontend and history service status, namespace access, visibility query results, task queue processing and a sample of running workflows after each step. Handover delivers the upgrade plan, the runbook, a change record of what ran and when, the updated Helm values or configuration, and a rollback procedure. Ask for the rollback steps to be exercised in staging before production, and confirm how long pre-upgrade schema and database state is retained.
Support retainer after go-live
A retainer can cover monitoring of upgrade readiness, review of new Temporal Server and Helm chart releases, patch application within an agreed window, configuration review, and incident response support for the self-hosted service. Scope, response expectations and the number of upgrade cycles included are set in the written agreement, so check them against your operating model. Ask how the rollback procedure and runbook are refreshed each time a new minor version is adopted.
What drives the cost and duration of a Temporal upgrade
This table lists the factors that change how much work a self-hosted Temporal upgrade takes, why each one adds effort, and how to keep it contained. Read it before requesting a quote so the written scope reflects your actual version gap, stores, deployment method and compliance needs.
| Driver | Why it raises effort | How to keep it down |
|---|---|---|
| Minor versions to cross | Backward compatibility is guaranteed only between successive minor versions, so each skipped minor line adds a separate upgrade, test and rollback cycle. | Ask for a written plan that steps through each minor version to the latest patch, and confirm the release notes for every step before scheduling. |
| Persistence store and its version | Schema changes must run before server upgrades when release notes call for them. Cassandra, PostgreSQL and MySQL each have their own tooling, supported version ranges and backup steps. | Confirm the store version is inside Temporal's tested range before starting, and make sure backups and a restore test are completed first. |
| Advanced visibility store and its version | Elasticsearch, OpenSearch and SQL visibility stores have separate version support, and index or schema changes can be needed alongside the server upgrade. Older Cassandra visibility is no longer supported. | Record the visibility store type and version in the scope, and plan any index changes as a distinct, tested step. |
| Deployment method | Helm charts on Kubernetes, Docker Compose, Go binaries and custom Go builds each need different artifacts, rollout steps and rollback methods. Helm chart versions below 0.73.1 do not work with server images 1.30 and later. | Pin the chart and server image versions together in version control and test the pairing in a non-production environment first. |
| Workers, SDKs and languages | Each worker service and SDK language must be checked for compatibility with the new server, and workers in several languages need separate builds, tests and rollouts. | Inventory every worker, its SDK language and version, and upgrade SDKs in a planned sequence with replay testing of running workflows. |
| Namespaces and running workflows | More namespaces and long-running executions increase the number of configurations to verify and the risk of disrupting in-flight work during the cutover. | Group namespaces by criticality, pause non-essential changes during cutover and confirm how running executions will behave before the change. |
| Security configuration | mTLS for internode and frontend traffic, an Authorizer, a ClaimMapper and OIDC for the Web UI each need to be retested after the upgrade, and a missing Authorizer leaves the default noopAuthorizer in place. | Document the current security settings, test each one against the target version in staging and confirm that no default allow-all configuration remains. |
| Environments and change control | Every environment, including development, staging, production and disaster recovery, needs its own upgrade run, validation and approval record, which multiplies the work. | Agree the environment order and the promotion criteria in the written scope, and reuse the same runbook in every environment. |
| Compliance evidence | Assessors and internal audit may ask for change records, test results, backup evidence, access reviews and proof that the platform stayed within a supported version range. Collecting this evidence after the fact takes extra time. | Define the evidence list before the work starts and capture it during each step, including the upgrade plan, test results and rollback records. |
How a Temporal upgrade runs from inventory to handover
The sequence moves a self-hosted Temporal Service from its current version to the target version without losing track of running workflows. Each phase closes with a written output that the platform owner signs off before the next phase starts, so every change can be traced and reversed.
Inventory the cluster and its compatibility
Your team and DeployOpen record the running server minor and patch level, the Helm chart version, the persistence store and its version (Cassandra, PostgreSQL or MySQL), the visibility store, every worker SDK version, namespaces, custom codecs and any authorizer or ClaimMapper configuration. Each item is checked against the persistence and visibility support lists in the Temporal docs for the target version. The output is an inventory register and a compatibility findings list. The step is done when the platform owner confirms that every gap has an owner and a decision.
Plan the minor version path
Move one minor version at a time, and move to the latest patch of the current minor before crossing to the next. Temporal guarantees backward compatibility only between two successive minor versions, so a jump across several minors is not treated as a single step. For each hop, read the release notes for schema changes, configuration changes and deprecations, and record which hops need a schema upgrade before the server upgrade. The output is a written path listing every hop, its release note findings and its checkpoints, approved by your architecture owner before staging begins.
Upgrade staging with schema changes first
Apply each hop to a staging environment that mirrors production topology and data volume as closely as practical. Where the release notes call for it, run schema upgrades against the persistence store before the server services are upgraded, and keep the migration scripts under version control. Run the server health checks and a set of representative workflows on each hop, then record which tests passed and what was observed. The output is a staging result log for every hop, with the schema version and server version recorded at each point.
Align the Helm chart with server images
Confirm that the Helm chart version and the server image version match before any deployment. Chart versions below 0.73.1 do not work with server images 1.30 and later, so a chart pinned to an older release will not deploy the newer server correctly. Render the chart for each hop, diff the output against the previous release, and review changes to values, service definitions and probes. The output is a pinned chart and image pair for each hop, with the rendered manifest diff attached to the change record and a clean deployment to staging.
Upgrade workers and run replay checks
Upgrade the Temporal SDK in each worker service along the target path, rebuild the workers and deploy them to staging. Confirm in the release notes that the SDK version pairs with the server version for that hop. Replay recorded workflow histories against the new worker code to confirm that workflow code still makes the same decisions for executions already in progress. Where a replay fails, the change needs a versioning or patching approach before it can ship, and the workflow owner decides the fix. The output is a replay test report covering each workflow type and a staging worker rollout that completes without unexplained failures.
Plan the production change window
Schedule the production hops with the owners of the affected workflows, and agree the window, the approvers and the escalation contacts before the date is fixed. Take and test a backup of the persistence store before each schema change, and write rollback steps for each hop. Where the release notes indicate that a schema change cannot be undone by redeploying an earlier server, record that and plan a restore instead. Rehearse the rollback in staging. The output is a signed change plan with a rollback runbook and a rehearsal record showing the team can execute the steps as written.
Run production hops and monitor
Apply each hop in production in the agreed order, with a go or no-go check before the next hop starts. Watch frontend error rates, history and matching latency, workflow task failures, task queue backlogs and worker health during the window and afterward, using the dashboards and alerts your team agreed in staging. Invoke the rollback plan if a checkpoint fails. The output is a production change log for each hop, a monitoring summary covering the observation period, and a closed change record once the platform owner confirms the environment is stable.
Hand over runbooks and agree support scope
Transfer the operating documentation to your team: the upgrade path used, the inventory register, the chart and image pins, the replay test suite, the rollback runbook and the monitoring baseline. Agree in writing who handles each area after go-live, including whether ongoing support, upgrades and continuous testing run under a retainer. The output is a handover pack, a recorded walkthrough in the project log, and a support scope document that names the incident contacts and the owner of the next minor upgrade.
Which parts of a Temporal upgrade teams keep in-house and which they outsource
This table compares the upgrade tasks that usually stay with the owning organization against those a partner often takes on, and lists the skills each one needs. Read each row as a split of accountability: the decision and the production access rarely move, while the preparation work is where outside help saves the most internal effort. Most teams find the riskiest gaps are in schema sequencing and worker SDK rollouts, not in the server binary itself.
| Upgrade task | Usually kept in-house | Often outsourced and skills required |
|---|---|---|
| Change window and go-live timing | Business decisions on change windows, freeze periods and acceptable downtime, owned by the service owner and operations leadership | Not typically outsourced. Input from a partner on sequencing risk can inform the decision, but the window belongs to the client |
| Workflow owner sign-off | Each workflow owner confirms that running executions and their business behavior are safe to move to the new version | Partner prepares test evidence and replay results. Skills: Temporal SDK language (for example Go), workflow determinism and versioning |
| Access to production | Production credentials, cluster access and the final call to start each step remain with the client's operators | Partner may run staged steps under a runbook with client-held access. Skills: Temporal server operations, Kubernetes, role-based access setup |
| Final approval and rollback decision | Client accountable for go or no-go and for invoking rollback during the window | Partner documents rollback criteria and tested rollback steps. Skills: Temporal server operations, database administration |
| Release-note review across versions | Confirm the target upgrade path and which intermediate minor versions apply | Partner reviews release notes for each minor step and flags schema, configuration and breaking changes. Skills: Temporal server operations, Go or relevant SDK language |
| Schema and Helm chart compatibility checks | Approve the schema and chart versions that will run in production | Partner checks that the chart version supports the server image and that schema upgrades run before server upgrades. Skills: Kubernetes, Helm, database administration for Cassandra, PostgreSQL or MySQL |
| Staging rehearsals | Provide staging environments that mirror production persistence, visibility and network paths | Partner runs repeated upgrade rehearsals and records timings and failures. Skills: Temporal server operations, Kubernetes, observability tooling |
| Runbook writing | Owners review and adopt the runbook and keep it current with their environment | Partner writes step-by-step runbooks with checks and rollback points. Skills: Temporal server operations, database administration, security configuration |
| SDK upgrade across worker fleets | Teams that own each worker service schedule their own deployments and confirm business behavior | Partner plans worker rollout order, compatibility with the server version and replay testing. Skills: Go or the relevant SDK language, Kubernetes, CI/CD pipelines |
| Security configuration after upgrade | Security owners confirm authorization, TLS and network settings still match policy | Partner verifies that mTLS, the Authorizer and network isolation settings survived the upgrade. Skills: Temporal security configuration, identity and certificate management |
What goes wrong in Temporal upgrades and how to prevent it
Temporal upgrades fail in predictable places: version paths, persistence schemas, Helm packaging, worker code, recovery plans and access controls. Each card names one failure mode, why it matters for a self-hosted Temporal Service, and the step that prevents it. Treat each one as a gate the upgrade plan must pass before the next step runs.
Skipping minor versions
Temporal guarantees backward compatibility only between two successive minor versions. A jump across several minor lines can leave the cluster in a state that no release was tested against, and the failure may appear only under production load. Prevention: write the upgrade path as a sequence of single minor steps, move to the latest patch of each current minor before stepping forward, and check every step against the upgrade documentation before running it in any environment.
Server ahead of schema and visibility
Release notes can require schema upgrades to run before the server is upgraded. A server that starts against an older persistence schema can fail in ways that are hard to diagnose. Advanced visibility stores carry the same risk, because a search store that lags the server version may make workflow searches in the Web UI and tooling unreliable. Prevention: run schema changes first in a staging copy, confirm that persistence and visibility versions match the target release, and gate the server rollout on that check.
Mismatched Helm chart and server image
The Helm chart and the server image are versioned separately, and chart versions below 0.73.1 do not work with server images 1.30 and later. A chart that renders the wrong service configuration can produce a cluster that appears healthy but fails on the first workflow execution. Prevention: pin the chart version and the image tag together in source control, check the chart's compatibility notes against the target server, and deploy the pair to a non-production cluster before production.
Workers on mismatched SDK versions
During a rolling change, old and new workers often run side by side, and a worker whose SDK does not match the workflow code can fail to replay running executions with non-determinism errors. The risk grows with long-running workflows that started before the change. Prevention: upgrade the SDK and workflow code together under an agreed patching or versioning approach, replay recorded production histories against the new code, and confirm which worker builds still serve each task queue before retiring the old ones.
Production upgrade without tested rollback
An upgrade that cannot be reversed turns a failed step into an outage. Rollback depends on what changed: a server binary can often be reverted, but schema changes may not be reversible in the same way. Prevention: for each step, record from the release notes which changes are reversible, restore a recent backup into a separate environment, rehearse the rollback there, and set the go or no-go criteria before the production window opens.
Unauthenticated cluster left in place
If no Authorizer is configured, self-hosted Temporal uses the default noopAuthorizer, which allows every API request with no authentication or access control. An upgrade is a common point to change network exposure or Helm values, so a cluster that was reachable only internally can become reachable by others without anyone noticing. Prevention: configure an Authorizer and ClaimMapper, enable mTLS for frontend traffic, keep services off public networks, and test that unauthenticated requests are refused after each upgrade.
What ongoing Temporal support covers after go-live
A support retainer for a self-hosted Temporal Service keeps the running system healthy after the first production workflows are live. The core work is monitoring the server, persistence and visibility layers together. That means watching the frontend, history, matching and worker services, the health of the persistence store (Cassandra, PostgreSQL or MySQL, depending on your choice), and the cluster health of your advanced visibility store. Before signing, ask the provider which metrics are watched, which alert thresholds they set, who receives each alert, and whether the provider or your team owns the first response to each one.
Patch and version work is the largest recurring item. A provider should track Temporal Server releases and move your cluster to the latest patch of the current minor version first, then plan periodic minor upgrades one step at a time, because backward compatibility is guaranteed only between successive minor versions. Each step includes schema changes, which must run before the server upgrade when the release notes require it. The retainer should also cover Helm chart updates, since chart versions must match the server images you run, and worker SDK maintenance across every worker fleet that connects to the cluster. Confirm how many upgrades per year are included and whether each one is a change request billed separately.
Security operations sit alongside the platform work. Expect the provider to handle access and certificate rotation for mTLS between services, client certificates, and the OIDC configuration for the Web UI, along with changes to the Authorizer and namespace role mappings. Backup and restore tests are the control most often skipped after go-live. A retainer should include scheduled restore tests of the persistence store, with a written record of what was restored, how long it took, and whether workflow state was intact. Ask who holds the backup keys and where restore evidence is kept.
Incident response hours are the part of the agreement that matters most in an outage. Temporal Technologies operates Temporal Cloud and sells support tiers separately. The Business tier starts at 500 US dollars per month for a 2-hour P0 response during business hours, according to the Temporal pricing page. With a self-hosted service, the response commitment comes from the written agreement with your implementation partner, not from a vendor tier, so response times, coverage hours, severity definitions and escalation paths must be spelled out in the scope. Response times and coverage are set in that agreement and are not promised here.
How a Temporal upgrade differs by starting point and deployment
A cluster several minor versions behind cannot jump straight to the newest server. Backward compatibility is guaranteed only between two successive minor versions, so the plan becomes a sequence of upgrades, each one moving to the latest patch of its minor line before the next step starts.
- Map the path: list every minor line between your current version and the target, such as the 1.30 line, then the 1.31 line, then the 1.32 line, and treat each hop as a separate change window.
- Check schema steps per hop: some hops require schema updates that must run before the server changes, so the schema sequence can differ from one hop to the next.
- Stage each hop first: run the full sequence against a copy of production-like data and workflow load before any production change.
- Track dependency versions per hop: the Helm chart, SDK and database versions may need to change at different hops, so confirm compatibility at each one.
- Set a rollback point before each hop: record the database state, configuration and artifact versions so each step can be reversed.
Check the release notes for every intermediate minor line, not only the target, along with the schema instructions attached to each one.
The official Helm charts run each Temporal Server service in its own Kubernetes pods, so the chart version and the server image version form a pair that must be planned together. Chart releases are tied to specific server lines, which means a chart upgrade can be the first change in the sequence.
- Pin the chart and image together: Helm chart versions below 0.73.1 do not work with server images 1.30 and later, so a chart upgrade may be required before the server image moves.
- Sequence the change: apply schema changes first when the release notes require them, then update chart values and image tags, then roll the services.
- Review values changes: chart defaults and value keys can change between chart versions, so compare rendered manifests against the running release before applying.
- Confirm external store settings: if persistence or visibility runs outside the cluster, verify that connection settings still match the new chart.
- Plan worker placement: SDK workers that run alongside the cluster need their own upgrade plan and should not be assumed to follow the server change automatically.
Check the chart release notes and the server release notes for the target line together, since either one can change the order of steps.
Docker Compose and Go binary deployments have fewer moving parts than a Kubernetes release, but the upgrade still follows the same schema and version sequence. The work concentrates on how images or binaries are replaced and how services restart on one host or a small set of hosts.
- Pin exact versions: set the server image tag or binary version explicitly in the Compose file or deployment scripts so every host receives the same build.
- Confirm service restart order: identify which services restart first and confirm that the cluster stays reachable through the change window.
- Review configuration files: compare static and dynamic configuration against the new release, since key names and defaults can change between versions.
- Check host dependencies: the Go toolchain for source builds or the container runtime version can limit which releases you can run.
- Rehearse restarts under load: a restart that succeeds on an idle test host can behave differently when active workflows and workers are connected.
Check the release notes for configuration key changes and confirm whether the schema step applies to the persistence store you run.
The persistence and visibility stores limit which server versions and schema steps apply to your cluster. Persistence and visibility are configured separately, and each supports its own range of database and search versions, so the store check should happen before any server change.
- Cassandra persistence: tested on Cassandra 3.11, 4.0 and 5.0.4 or later, so confirm your version falls in that range at every hop.
- PostgreSQL and MySQL persistence: tested on PostgreSQL 13 to 16 and MySQL 5.7 and 8.0.19 or later. A database major version change may need to happen in a separate window from the Temporal change.
- Elasticsearch or OpenSearch visibility: Elasticsearch 7 and 8 are supported, and OpenSearch 2 or later is supported from Temporal Server 1.30.1.
- Cassandra visibility is removed: it was removed in 1.24, so a cluster that still uses it needs a visibility migration plan before it reaches a current line.
- SQLite is for testing only: it is meant for development and testing, so a store check should flag any environment still relying on it.
Check the persistence and visibility pages for the exact versions your target server supports, and confirm whether the schema step differs for your store.
Two situations change where the upgrade artifacts come from. A custom Go build that imports the server package must rebuild against the new server version, and an air-gapped network must receive every patch, image, chart and schema file through an internal mirror before the change window opens.
- Rebuild the imported package: update the server package version, rebuild, and run your custom code paths against the new version, since changes in imported packages can alter behavior your code depends on.
- Review the toolchain requirement: confirm the Go toolchain version and dependency set that the target release requires, and record the versions used for each build.
- Mirror every artifact: copy server images, the Helm chart, schema files and any SDK packages into an internal registry or repository before the window.
- Mirror the full path: patch releases for earlier minor lines are published separately, so mirror the latest patch of every line in your upgrade path along with the target.
- Verify artifact integrity: check each artifact against published checksums or signatures where the release provides them, and record which mirrored version was deployed.
Check the release notes for imported-package and toolchain requirements, and confirm which checksum or signature information each release supplies.
What your team needs to provide before a Temporal upgrade starts
Start by assembling the configuration that defines your current Temporal Service. DeployOpen needs read access to the Temporal configuration and to whichever deployment files you use, whether that is a set of Helm values for the Kubernetes charts, a Docker Compose file, or Go binaries managed by your own scripts. The chart version matters as much as the server image. Helm chart versions below 0.73.1 do not work with server images 1.30 and later, so the chart version in use must be stated explicitly. Include the authorization settings too. If no Authorizer is configured, self-hosted Temporal uses the default noopAuthorizer, which allows every API request. That setting should appear in the files you share so the upgrade plan reflects your actual access posture.
Next, provide the exact versions of your persistence and visibility stores. Temporal is tested 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, and SQLite is intended only for development and testing. Advanced visibility supports Elasticsearch 7 and 8, and OpenSearch 2 or later from Temporal Server 1.30.1. Cassandra visibility was removed in 1.24. Confirm internally that each store version falls within the supported range for both your current and target minor versions. A store that works today may need its own upgrade before the Temporal Server can move. Ask whether your visibility store has capacity for your present workflow volume, since it is often the component that slows first under load.
Third, supply an inventory of every worker service with its SDK language, its SDK version and the namespaces each one uses. Worker SDK upgrades run on a separate schedule from the server, so this inventory shows how much application work the upgrade creates. Name one owner for the Temporal cluster, one for each namespace and one for each worker service. Confirm internally that each person can approve changes in their area and knows who to call when a workflow stalls. Also provide a staging environment that mirrors production in topology, store versions and configuration. Ask for backup and restore evidence from a recent restore test, not only a log showing that a backup job ran. Confirm the change window with the business owners who accept the downtime risk.
Finally, identify the decision-maker who signs off on the target version path. Backward compatibility is guaranteed only between two successive minor versions, so the path from your current release to the target may include several steps. Each step changes the schedule, the test effort and the rollback plan. The decision-maker should accept the path in writing before scoping begins. Before engaging a partner, confirm internally that configuration access, store versions, the worker inventory, staging parity, restore evidence, the change window and named owners are all ready. Log any missing item as an open action in the first planning meeting, and close it before the upgrade window is booked.
How much does a Temporal upgrade cost and how long does it take?
How much does a self-hosted Temporal upgrade cost?
The cost depends on the written scope, and DeployOpen does not publish a price list. A quote follows from the scope you agree to. The main cost drivers are the number of minor versions to cross, the number of environments, the number of workers and SDK codebases, the number of namespaces, and how much of the database and Kubernetes layer is in scope. Your own staff time is also a cost, even when no partner is involved. Ask for the quote to split one-time upgrade work from any recurring support so the two can be compared separately.
How long does a Temporal upgrade project take to complete?
Duration is set by the scope, and no fixed timeline applies to every environment. The biggest variables are how many minor versions separate your current server from the target, because the Temporal upgrade guidance says to move one minor version at a time to the latest patch of each. Schema changes must run before the matching server upgrade when release notes call for them, and each step needs testing in staging. Ask for the timeline in the written scope, with milestones for each minor step, staging validation and production cutover.
Is a Temporal upgrade a one-time project or an ongoing cost?
The upgrade project itself is one-time work with a defined end point. Support after go-live is recurring, and it is usually bought as a retainer. A retainer can cover monitoring response, later upgrades, patch releases and continuous testing, but the exact coverage is set in the written agreement. Ask which items are one-time, which recur, and how each recurring item is priced and renewed, so you can plan the budget for both the project and the years that follow.
What should a written quote for a Temporal upgrade include?
A useful quote lists the scope in concrete terms. Ask for these items to be stated:
- Versions: the current and target server versions, and each intermediate minor version
- Environments: which development, staging and production clusters are covered
- Workers: the number of worker services and the SDK upgrades they need
- Namespaces: which namespaces are in scope and how they are tested
- Databases and Helm: schema upgrades and chart compatibility checks
- Deliverables: a runbook, rollback steps and a handover session with your team
Also confirm what is excluded, such as workflow code changes, and who performs production cutover.
Can our in-house team upgrade self-hosted Temporal without a partner?
Yes, an in-house team can do the upgrade if it has the right skills and a tested staging path. The team needs working knowledge of Temporal server operations, the database engine used for persistence, and Kubernetes if the services run in pods. Staging should match production closely enough to rehearse each minor step, including schema changes and worker SDK upgrades. A partner is useful when the team lacks one of these skills, when the schedule is tight, or when a second pair of hands is needed for cutover and handover.
What do we need to provide before a Temporal upgrade starts?
Before work starts, you should provide a current inventory of the Temporal server version, the Helm chart version if you use one, and the persistence and visibility stores with their versions. Also provide a list of worker services with their SDK versions, the namespaces in use, and access to staging and production under your change process. Current backups and a rollback plan should be in place. Confirm these items with your own environment owners early, because gaps usually extend the schedule and change the quote.
Why does the Helm chart version matter during a Temporal upgrade?
Helm chart compatibility can block an upgrade even when the server image is correct. The Temporal deployment documentation states that chart versions below 0.73.1 do not work with server images 1.30 and later. Check the chart version against the target server version before any change, and record the chart version in your runbook. If your chart is older, plan the chart upgrade as a separate step in staging, and confirm the sequence with your own platform team.
Does DeployOpen issue audit reports for a Temporal upgrade?
No, DeployOpen does not issue audit reports, attestations or certifications. DeployOpen can prepare systems, controls and evidence for a compliance assessment, such as change records, configuration documentation and test results from the upgrade. Independent auditors and certification bodies perform the assessment and issue any report. Ask for the evidence list in the written scope so your compliance lead knows what will be delivered and what your auditor will still need to review.
How DeployOpen works on this
DeployOpen plans and carries out Temporal Service upgrades inside the client's own infrastructure, one minor version at a time, with schema, Helm chart and worker SDK changes handled as one controlled sequence. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts, and ongoing support is available as a retainer.
How we scope
- Inventory the current server version, Helm chart version, persistence store and visibility store before any change is proposed.
- Map the upgrade path from the current minor line to the target, listing each intermediate minor version and its release notes.
- Agree in writing which worker SDKs, namespaces and environments are in scope, and what the quote excludes.
How we build
- Rehearse each minor step in a non-production environment that mirrors the production persistence and visibility stores.
- Run schema upgrades before server upgrades wherever the release notes call for them, and record the order used.
- Test worker SDK upgrades against replayed workflow histories so running executions stay compatible throughout.
How we hand over
- Document the executed upgrade path, Helm values, schema versions and rollback steps for each environment.
- Provide a verification record covering server health, workflow throughput, visibility queries and worker connectivity after each step.
- Walk the operations team through the runbook so they can repeat the procedure for the next minor release.
How we support
- Review new Temporal server patch and minor releases against your environment and propose upgrades on a planned cadence.
- Keep Helm chart and server version compatibility under review, since chart versions must match the server line being run.
- Offer ongoing support, upgrades and testing as a retainer, with the covered services and response expectations set in the written agreement.
