OpenTofu vs Pulumi: when each one is the right choice
Choose OpenTofu when your infrastructure is already written in HCL, your platform team works in Terraform workflows and you want to keep that code and those habits with minimal change. Choose Pulumi when application developers will own infrastructure code and want to write it in TypeScript, Python, Go, .NET or Java. The typical reader is a platform team with a large Terraform estate, or a software engineering group starting infrastructure as code from scratch. OpenTofu fits the first case because it is a drop-in replacement for Terraform that preserves existing workflows and configurations, according to the OpenTofu website. Pulumi fits the second because its code is ordinary general-purpose software with stable support for several mainstream languages.
On licensing and governance, OpenTofu is released under the Mozilla Public License 2.0 and operates under the Linux Foundation's stewardship, and it was accepted to the CNCF at the Sandbox maturity level on April 23, 2025. Pulumi is licensed under Apache-2.0. Teams with a strict requirement for file-level copyleft or foundation-hosted governance should confirm which of these terms their legal and procurement reviewers accept. Teams that want a permissive license with a single vendor-run roadmap should review the Pulumi project's own governance documents directly.
The decision turns on four things: how much existing Terraform code you must carry forward, which languages your engineers already write in, what your state and encryption requirements are, and whether the providers you need are covered well in each ecosystem. OpenTofu's registry lists more than 3,900 providers and 23,600 modules, so confirm your specific providers and modules are present at search.opentofu.org. Pulumi supports more than 300 providers, so check the ones on your list against its registry. Also confirm that OpenTofu state encryption with your chosen key provider meets your policy, since that feature is built into the tool.
Which fits your team: OpenTofu vs Pulumi by scenario
This table maps common team situations to the platform that usually fits better, based on code reuse, skills, governance and migration effort. Read each row as a starting point, then check the condition in the last column against your own estate before you decide.
| Team scenario | Better fit and why | Condition under which the other platform wins |
|---|---|---|
| Large existing Terraform estate (illustrative) | OpenTofu. It is described as a drop-in replacement for Terraform that preserves existing workflows and configurations, so HCL modules, state and team runbooks carry over with the smallest change. The migration overview describes a four-step process designed to be safe and reversible. | Pulumi wins if the estate is small enough to rewrite and the team wants application developers to own infrastructure in a general-purpose language. Also check any terraform_remote_state dependencies first, since the migration guide flags them for extra care. |
| Greenfield project led by developers who write TypeScript or Python (illustrative) | Pulumi. It supports TypeScript, JavaScript, Python, Go, .NET, Java and YAML at stable support level, so loops, functions, unit tests and shared libraries follow the language developers already use. | OpenTofu wins if the platform team expects to hire HCL-fluent operators, or if the organization wants declarative configuration that reviewers can read without running a program. |
| Platform team standardizing on HCL modules across many business units | OpenTofu. Module reuse, the OpenTofu Registry with more than 3,900 providers and 23,600 modules, and a shared HCL vocabulary reduce the review burden for a central team. | Pulumi wins if the platform team already publishes reusable components as language packages and consumers are developers who prefer to import them rather than read HCL. |
| Regulated team that must keep a stable upgrade path | OpenTofu, if the priority is continuity with Terraform and a Linux Foundation-stewarded, MPL-2.0 project. Note that the FAQ aims for feature parity but does not guarantee compatibility with future Terraform releases, so plan a version-testing step either way. | Pulumi may fit better if the compliance team prefers a single vendor-backed roadmap and its Apache-2.0 license, provided the team confirms the support and release terms it needs in writing. |
| Team that must encrypt state and plan files with its own key service | OpenTofu. Its documentation describes state and plan encryption at rest for local and remote backends, with key providers including AWS KMS, GCP KMS, OpenBao and Azure Vault, introduced in v1.7. | Pulumi wins if the team's key management and state handling already match its model. Confirm the encryption scope, key rotation and backend options against the current Pulumi documentation before deciding. |
| Team with a mixed cloud footprint on Kubernetes and VMs (illustrative) | Pulumi, when Kubernetes resources are authored alongside application code in one language. The provider catalog covers AWS, Azure, Google Cloud, Kubernetes and more than 300 providers. | OpenTofu wins when most of the work is provider-based HCL across a shared module library and the team wants one syntax across all platforms. |
| Organization that needs a community-governed project under a foundation | OpenTofu. It is under the Linux Foundation's stewardship and was accepted to the CNCF Sandbox on April 23, 2025, which is a useful governance signal for buyers who weigh neutral stewardship. | Pulumi wins if the buyer's governance review centers on the company behind the tool and its commercial support contract rather than foundation stewardship. Ask both vendors for their governance documents. |
| Small team that wants the lowest learning curve for infrastructure changes | OpenTofu for operators who already know Terraform. The four-step migration and the small test change recommended in the migration overview let a team validate workflows before committing. | Pulumi wins for a developer-only team with no operations staff, because it removes the second language and lets the same people write application and infrastructure code. |
Where OpenTofu and Pulumi differ in how infrastructure is defined
OpenTofu and Pulumi both provision infrastructure from code, but they ask different things of the team: one configuration language and a shared provider ecosystem on one side, and general-purpose programming on the other. The cards below cover the differences that shape daily operations, from how configurations are written and reviewed to where state lives, how it is encrypted and how each tool runs inside CI.
Declarative HCL or general-purpose code
OpenTofu uses HCL, a declarative configuration language, so a change is usually reviewed as resource blocks and variables that plan tooling can diff. Pulumi defines infrastructure in TypeScript, JavaScript, Python, Go, .NET, Java or YAML, so loops, functions and tests come from the language itself. The team must own the skills question: an HCL-literate operations group can read OpenTofu changes directly, while a Pulumi program needs reviewers who can read the chosen language and its package dependencies.
Provider and module ecosystem size
The OpenTofu Registry lists more than 3,900 providers and 23,600 modules, and OpenTofu states it aims to keep feature parity with Terraform. Pulumi targets more than 300 providers across AWS, Azure, Google Cloud, Kubernetes and others. Counts do not settle fit. Check that the specific provider, version and resource you depend on exist in the registry you will use, and confirm who maintains each one, because the team inherits the upgrade work when a provider changes.
State storage and encryption
Both tools keep state that must be stored, locked and protected. OpenTofu encrypts state and plan files at rest for local storage and remote backends, with key providers including PBKDF2, AWS KMS, GCP KMS, OpenBao and Azure Vault, a feature the website tags as introduced in v1.7. The team owns key custody, rotation and backend access control. Confirm how Pulumi state is stored and encrypted in your chosen backend before choosing, since the answer depends on your deployment.
Migrating existing Terraform code
OpenTofu is positioned as a drop-in replacement for Terraform that keeps existing workflows and configurations. Its migration path has four steps: back up state and code, install OpenTofu, initialize and verify the configuration, then test with a small change. Configurations that share data through terraform_remote_state need extra care. Pulumi is a different engine, so moving Terraform code means rewriting it, and the effort scales with the number of modules and the state each stack owns.
Fit with existing CI pipelines
OpenTofu runs as a command-line binary, so plan and apply steps slot into any CI system with the same review gates the team already uses for Terraform. Pulumi also runs from CI, but its programs need the language runtime, package restoration and dependency pinning in the pipeline image. Ask which pipeline images, secret stores and approval steps each option needs, and who keeps those images patched. Runner choice for either tool is covered in the sibling comparison.
Governance and project stewardship
OpenTofu is MPL-2.0 licensed, stewarded under the Linux Foundation and accepted to the CNCF at the Sandbox level on April 23, 2025, after forking from Terraform. Pulumi is Apache-2.0 licensed. Governance affects long-term planning: the OpenTofu FAQ says future Terraform compatibility is not guaranteed, so the team must track both project roadmaps. Ask each vendor for its release and support policy in writing before committing to a multi-year codebase.
Capability comparison: language, state, encryption and governance
This table sets OpenTofu against Pulumi on license, governance, language, provider reach, state encryption, Terraform compatibility, CNCF status and release cadence. Where the supplied facts do not cover a Pulumi point, the row tells you what to confirm in Pulumi's own documentation before you decide.
| Capability | OpenTofu | Pulumi |
|---|---|---|
| License | Mozilla Public License 2.0 | Apache-2.0 |
| Governing body | Linux Foundation stewardship; created by a group including Gruntwork, Spacelift and Harness after HashiCorp moved Terraform to the Business Source License | Confirm governance model, company stewardship and contributor policy in Pulumi's project documentation and repository |
| Language support | HCL, the Terraform configuration language, with existing Terraform workflows preserved | TypeScript, JavaScript, Python, Go, .NET, Java and YAML with stable support, using general-purpose languages |
| Provider and module availability | More than 3,900 providers and 23,600 modules listed in the OpenTofu Registry | More than 300 providers across AWS, Azure, Google Cloud, Kubernetes and others; confirm module reuse model and registry counts in Pulumi's docs |
| State encryption at rest | Encrypts state and plan files for local and remote backends, with PBKDF2, AWS KMS, GCP KMS, OpenBao and Azure Vault key providers since v1.7 | Confirm how state is encrypted, which secrets providers apply and where keys are held in Pulumi's state management documentation |
| Terraform compatibility | Aims for feature parity with Terraform in future releases, but compatibility with future Terraform releases is not guaranteed | Not a Terraform fork; existing HCL must be rewritten or converted to a Pulumi language |
| CNCF status | Accepted to the CNCF at the Sandbox maturity level on April 23, 2025 | Confirm current CNCF status, if any, on the Pulumi project and CNCF pages before relying on it |
| Release cadence | OpenTofu v1.13.1 released October 1, 2026, following 1.13.0; check the GitHub releases page for the current support window | Confirm release cadence and supported versions in the pulumi/pulumi repository and Pulumi release notes |
What each license allows and what is paid for
OpenTofu is licensed under the Mozilla Public License 2.0, according to its GitHub repository, and its project website describes it as a drop-in replacement for Terraform that preserves existing workflows and configurations. The project is under the Linux Foundation's stewardship and was created by a group including Gruntwork, Spacelift and Harness in response to HashiCorp's switch to the Business Source License. OpenTofu was accepted to the CNCF on April 23, 2025 at the Sandbox maturity level. Stewardship describes who governs the project, not what the license permits, so the license text and your own use case still need review.
- Internal use: MPL-2.0 places its main obligations on distribution. Running OpenTofu inside your own infrastructure is usually a different question from shipping it, but confirm how this applies to your deployment model.
- Modification: If you change files covered by MPL-2.0 and distribute them, those files stay under MPL-2.0. Larger works that combine OpenTofu with your own code can carry other terms, so the file boundary needs a clear answer.
- Redistribution: Shipping OpenTofu or a derivative to customers or partners requires you to supply the license and source for covered files and keep the notices intact.
- Governance: Linux Foundation stewardship does not change license terms, and it does not promise any particular roadmap decision.
- Terraform compatibility: The OpenTofu FAQ states an aim of feature parity with Terraform for future releases, while the community decides which features OpenTofu adopts. Compatibility with future Terraform releases is not guaranteed, so record which Terraform version your modules and providers depend on.
Before committing, ask counsel to map your internal, modified and distributed uses to MPL-2.0 obligations, and document the Terraform version your code tracks.
Pulumi is an Apache-2.0 infrastructure as code tool that defines cloud infrastructure in general-purpose languages, according to the pulumi/pulumi GitHub repository. Apache-2.0 is a permissive license, so the open-source engine can be used, modified and redistributed under its terms. No edition, hosted service or support tier facts were established for this comparison. Confirm with Pulumi directly which paid offerings exist, what each includes and how support is delivered before assuming any capability is covered.
- Internal use: Apache-2.0 allows you to run the engine inside your organization. Your own infrastructure code is not automatically subject to the license's distribution conditions when you only operate it internally.
- Modification: You may change the source. Modified files must carry notices stating that you changed them, and you must keep the license and any NOTICE content in what you distribute.
- Redistribution: Shipping the engine or a derivative requires including the license text and required attributions. The license includes an express patent license from contributors, subject to its conditions.
- Paid offerings: Any hosted service, support agreement or enterprise tier is a separate commercial matter. Ask Pulumi for the current edition list, what each includes, the support terms and any contractual limits on use.
- Dependencies: Providers and third-party packages your code imports carry their own licenses. Inventory each one, since they may differ from Apache-2.0.
Ask counsel to review the Apache-2.0 notice and attribution requirements against your distribution model, and to check the license of every provider package your code pulls in.
What drives the running cost of each tool
Running cost for OpenTofu and Pulumi comes from the same few places: who runs the pipelines, who holds the state and keys, who supports the tool, and how often the team must retest after upgrades. The cards below separate one-time work from recurring spend and name what to ask for in a written quote from each vendor or partner.
CI runners and state backends
Both tools run from a pipeline, and the runner plus the state backend are usually the first recurring infrastructure line. With OpenTofu, teams often pair the CLI with a self-run runner or a Git-based pull request workflow and an object storage or database backend. Pulumi commonly uses its own state service or a self-managed backend. Ask who provisions and patches runners, where state lives, how many environments and workspaces you expect, and whether backend storage, backups and runner minutes are priced separately from any license.
Skills premium of HCL
OpenTofu uses HCL, the configuration language Terraform teams already know, so the main cost is training for new modules and review practices rather than new languages. Pulumi lets engineers write infrastructure in TypeScript, Python, Go, .NET or Java, which can reduce friction for application teams but may move cost into developer time and library governance. Estimate this in your own staff plan, not from a generic rate. Ask a partner to name the languages their engineers will use and how they will review code.
State and key management setup
OpenTofu can encrypt state and plan files at rest with key providers such as AWS KMS, GCP KMS, OpenBao, Azure Vault or PBKDF2, so key custody becomes a recurring duty tied to your cloud or secrets platform. Pulumi state handling depends on the backend and secrets provider you choose. Setup is largely one-time, but key rotation, access reviews and backup testing recur. Confirm which key provider you will operate, who holds the keys, and whether a quote includes rotation runbooks and recovery testing.
Paid support and managed offerings
Support is where the vendor or partner model differs most. Pulumi's commercial offerings and OpenTofu's community support route should both be confirmed directly with each vendor, since neither answer should be assumed. A fixed-scope implementation from DeployOpen is a separate, one-time engagement, and ongoing support is available as a retainer. Ask each party what support tier is included, response expectations in writing, whether licenses scale with users or resources, and what happens to pricing at renewal.
Upgrade and testing effort per release
OpenTofu ships on its own cadence, and the project states an aim of feature parity with Terraform while noting that future Terraform compatibility is not guaranteed. Each release means a provider and module compatibility check, plan diffs across environments and a rollback rehearsal. Pulumi upgrades bring SDK and language runtime changes that must be tested in each application codebase. Plan a recurring test window for both, and ask for a written upgrade procedure and the test coverage included in any retainer.
Cost of migrating code later
Switching later is a one-time cost that grows with the amount of existing code. OpenTofu's migration guide describes a back up, install, initialize and verify, then test with a small change approach that is designed to be safe and reversible, but it warns that configurations using terraform_remote_state need extra care. Moving from HCL to Pulumi is a rewrite of the code, not a configuration change. Ask a partner to inventory your modules, remote state dependencies and pipelines before quoting, and to state what is excluded from a fixed scope.
Moving existing Terraform code to OpenTofu, and what a move to Pulumi involves
The OpenTofu path is a short, reversible sequence that keeps existing HCL, while a Pulumi move is a rewrite whose size depends on how the current code is organized. Walk through both before you commit to either.
Back up state and code first
Before anything changes, the platform team takes a full copy of the current state files and the Terraform configuration repository, including the lock file and any variable files used in CI. Store the backup where the existing Terraform workflow cannot overwrite it. The step is complete when someone other than the author can restore the state from the backup and run a read-only plan against it. OpenTofu's migration overview describes the process as designed to be safe and reversible, and this backup is what makes that reversibility real.
Install OpenTofu alongside Terraform
The engineer who owns the pipeline installs the OpenTofu binary on the CI runners and on the workstations that run plans, keeping the existing Terraform binary available until verification finishes. Pin the OpenTofu version in the pipeline definition so every run uses the same release, such as v1.13.1 as published on the OpenTofu GitHub releases page. The step is done when the pinned version reports correctly on every runner that will execute the configuration.
Initialize and verify the configuration
Run initialization against the existing backend and providers, then run a plan on each root module or workspace. Compare the output with the most recent Terraform plan for the same state. Expect no resource changes if the code and state are unchanged. Any unexpected diff must be resolved before moving on, because it usually points to a provider version, a backend setting or a language feature that behaves differently. The step closes when every root module produces a clean plan and the team has recorded the results.
Review state for remote data sharing
Find every configuration that reads another stack's outputs through the terraform_remote_state data source and list the producer and consumer pairs. The migration overview warns that these configurations typically need additional care during migration and links a separate guide for that case. Confirm the sequence in which producers and consumers are migrated and verified, and agree on a freeze window if outputs change during the move. The step is complete when the dependency map is written down and reviewed by owners of each affected stack.
Test with a small, reversible change
Make one low-risk change in a non-production workspace, such as a tag update on a test resource, and apply it with OpenTofu. Confirm the apply succeeds, the state updates correctly and the next plan shows no drift. Then repeat the test on one production-adjacent stack under change control. The step is done when the team has seen a full plan and apply cycle complete in both environments and has rolled back the test change if needed.
Decide on state encryption and CI changes
Once the configuration runs cleanly, the team decides whether to enable OpenTofu's state and plan file encryption for local storage and remote backends, and which key provider to use among PBKDF2, AWS KMS, GCP KMS, OpenBao and Azure Vault. Confirm that the key material is managed outside the state store and that recovery procedures exist. Update pipeline definitions and access controls to match. The step is complete when the encryption setting, key owner and recovery steps are documented in the change record.
Estimate a move to Pulumi as a rewrite
A move to Pulumi is not a binary swap because Pulumi programs are written in a general-purpose language such as TypeScript, Python, Go, .NET or Java, so each HCL module must be rebuilt in the chosen language, then checked against the live resources. Inventory modules, resource counts, custom providers and the current state layout, then decide whether to import existing resources or recreate them. The effort depends on module count and state layout, so ask a Pulumi implementation partner for a written estimate based on that inventory. Plan a parallel run where both tools produce a plan for the same stack until the outputs match.
Where OpenTofu and Pulumi projects usually run long
Most OpenTofu overruns start before any resource changes. Teams usually underestimate the work of validating existing modules against the OpenTofu version they will run, checking provider versions in the lock file, and deciding who owns the state encryption key. State encryption is configured per state and plan, and the key provider you choose (for example, AWS KMS or OpenBao) determines which roles need decrypt access in CI and on operator workstations. Teams also need to align CI runners so every pipeline uses the same OpenTofu binary and can reach the key provider. Ask the implementer to list each state file, its backend, its key provider and the principals that need access before work starts, and confirm how the scope handles modules that have not been touched in a long time.
Most Pulumi overruns come from the software engineering around the code. The work is less about syntax and more about choosing a language standard (for example, one TypeScript version and one lint and test setup across all stacks), building shared component libraries that encode your naming, tagging and network rules, and training developers who previously wrote HCL to model infrastructure as a program. Each of these decisions is one-time work, but the library and its versioning recur as platform teams publish changes. Ask for the expected number of component libraries, who reviews them, and how training is delivered and measured, and confirm these items in the written scope rather than assuming a generic onboarding package covers them.
Three risks cut across both tools and cause the most rework. The first is cross-stack data sharing: configurations that read another stack's outputs, such as the terraform_remote_state data source in OpenTofu or stack references in Pulumi, need a deliberate migration plan because they break if one side moves first. The second is unclear state ownership, where two teams can apply the same resources and neither knows which stack is authoritative. The third is unreviewed provider upgrades, which can change resource behavior and force replacements in production. Plan a review gate for each provider bump, pin versions, and require a plan or preview output in every change request. Treat any effort figure you receive as an estimate that holds only for the scope you wrote down.
Questions teams ask before choosing or migrating
Is moving an existing Terraform estate to OpenTofu safe?
The migration is designed to be safe and reversible, and OpenTofu's migration overview describes four steps: back up state and code, install OpenTofu, initialize and verify the configuration, then test with a small change. Most teams start with a non-production workspace so that a plan diff can be reviewed before any apply. Configurations that share data through the terraform_remote_state data source need extra care, and the migration guide covers that case separately. Confirm that every provider and module in your estate resolves in the OpenTofu Registry, which lists more than 3,900 providers and 23,600 modules, and check any Terraform features your code depends on against OpenTofu's release notes before you rely on them.
How long does a migration take, and what drives the effort?
No supplied source gives a duration for moving a Terraform estate, so treat any figure you hear as a question to verify. The effort is driven mainly by the number of workspaces and state files, the number of providers and modules that need version checks, how much shared state crosses workspace boundaries, and whether your CI pipelines call Terraform by path or by binary name. Pulumi adds a separate question: converting HCL into a general-purpose language is a rewrite, not a rename, so its effort scales with the amount of logic you want to re-express. Ask any implementation partner for a written scope that lists the workspaces, the pipelines and the verification steps included.
What does the team need to supply for a fixed-scope implementation?
DeployOpen's engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. In practice the client supplies access to the state backends, the cloud accounts or clusters the code targets, the repositories and CI runners, and a named owner who can approve plan output. Secrets handling, key provider choices for state encryption and the approval flow for production applies should be decided by your security and platform owners before the work starts. Ask for the list of required inputs in the written scope so that delays caused by missing access are visible early.
Can developers maintain Pulumi programs without platform help?
Developers who already write TypeScript, Python, Go, .NET or Java can usually read and change Pulumi programs without learning a new configuration language, because Pulumi supports those languages with stable support. That benefit is real only when the team has the testing habits and dependency management discipline to keep those programs maintainable. Platform help still matters for shared component libraries, provider version policy, state backend setup and review standards. OpenTofu, by contrast, keeps the HCL workflow that many operations teams already know, so the skills gap is smaller for Terraform-trained staff. Test the decision with a pilot module written by the people who will own it.
How is state encryption set up in OpenTofu?
OpenTofu encrypts state and plan files at rest, both for local storage and remote backends, and it supports key providers including PBKDF2, AWS KMS, GCP KMS, OpenBao and Azure Vault. The feature was introduced in v1.7, according to the project website. Configuration is declared in the OpenTofu code and the key provider is chosen per environment, so the key lifecycle, rotation and access policy belong to your security team. Confirm the exact configuration keys against the state encryption documentation for the version you run, and test that a lost or rotated key is recoverable under your backup process before production use.
Will OpenTofu stay compatible with future Terraform releases?
Compatibility is not guaranteed. The OpenTofu FAQ states an aim to maintain feature parity with Terraform for future releases, but the community decides which features OpenTofu adopts. OpenTofu has also added its own features since the fork, including early evaluation of variables and locals in v1.8 and provider for_each and the -exclude flag in v1.9. Those additions are useful, but they mean a configuration written against one tool may not run unchanged on the other. If you plan to stay on OpenTofu long term, pin versions, read each release note, and keep a test environment that runs your full plan before upgrading.
What should we confirm about governance and support before choosing?
OpenTofu is licensed under the Mozilla Public License 2.0, is under the Linux Foundation's stewardship and was accepted to the CNCF at the Sandbox maturity level on April 23, 2025. Pulumi is an Apache-2.0 tool. Confirm which support options each vendor or community channel offers, what their release cadence is in your environment, and who signs off on security fixes for the version you run. Ask whether your provider set depends on any feature that differs between the two ecosystems, and document the answer in your decision record.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For OpenTofu vs Pulumi, we start by testing which tool fits your existing Terraform code, your team's languages and your state and encryption requirements before any migration work begins.
How we scope
- Inventory existing Terraform configurations, modules, providers and remote state dependencies before recommending either tool.
- Define which languages and skills the platform team will maintain, and record that decision in the written scope.
- Agree in writing which state backends, encryption key providers and governance controls the engagement will cover.
- Engagements are fixed-scope, so deliverables and timelines are confirmed in writing before work starts.
How we build
- Run a pilot migration of a small, non-critical configuration to OpenTofu or Pulumi and compare plan output.
- Configure state and plan encryption, backends and access controls in your own environment, not ours.
- Test provider versions, module sources and CI pipeline behavior against your real account structure.
- Document each design choice so your team can review the reasoning without relying on the implementer.
How we hand over
- Deliver runbooks for state recovery, key rotation and rollback, written for your operations staff.
- Provide migration records showing which configurations moved, what was verified and what remains on Terraform.
- Walk your engineers through day-to-day workflows so they can run plan, apply and review without assistance.
- Hand over source code, configuration and documentation in repositories you own and control.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Review tool version upgrades and provider changes on a schedule agreed in the retainer scope.
- Confirm with your team which support hours, escalation paths and response commitments apply, as these are set per agreement.
- Re-test state encryption and backup restores after significant changes to the tool or its backends.
