The Incumbent Lock-In Read: Displace Now, Seed, or Leave

This guide is for founders, account executives, SDR leads and partnerships teams who can see that a target account runs a rival open-source tool, or its relicensed upstream, in its public repos. It gives you a six-dimension scoring model that measures how far the account's own code has drifted toward leaving or away from it. It also gives you a rule that turns the scores into one of three verdicts: Displace Now, Seed, or Leave. The worked examples are Terraform to OpenTofu and Redis to Valkey, because those cases have the most public evidence.

What does the Incumbent Lock-In Read decide?

It decides whether one account that already runs a competing open-source dependency gets an AE's week now, a cheap nurture track until a dated trigger, or nothing. It does not tell you whether the account uses the competitor. You already know that. What you need to know is whether its code is moving.

Terms, defined once:

• Incumbent: the tool the account runs today and the one you want it to leave.
• Relicensed upstream: an open-source project whose owner moved it to a more restrictive license. HashiCorp moved Terraform from MPL 2.0 to BSL 1.1 on 10 August 2023.
• Reference release: the last version under the old permissive license. For Terraform it is 1.5.7. Valkey is a fork of Redis 7.2.4 under the BSD license, so 7.2.4 is the reference line for Redis.
• Pin: a version constraint in code that holds the account at or below a given release.
• Root module: a top-level infrastructure configuration that is planned and applied on its own. Count root modules, not repos.
• Lock file: the file that records the exact provider versions and the registry each one came from.

Licenses keep changing, so confirm the reference release each time you start a new list. Redis 8 added AGPLv3 in May 2025. For a Redis account, what counts as "the relicensed upstream" depends on which version it runs.

Why is "evaluating" the base case and not a buying signal?

Because in every survey that reports both numbers, stated intent to leave a relicensed tool runs roughly 5x to 10x ahead of completed migration. An account that says it is evaluating the alternative is a typical account, and typical accounts stay in Seed until their code says otherwise.

Read the third row with caution. The 38% figure only appears second-hand, I could not find the primary Spacelift source, and the ratio divides one survey by another. I found no comparable figures for the Elasticsearch relicense.

All three sources have a stake in the outcome. Percona's own report says its audience "could be biased as the research is conducted by Percona who are a participant in the Valkey fork", and Firefly and Spacelift are vendors too. The gap points the same way in every source, but don't quote the exact ratio in a forecast.

For the model, this means anything that only measures interest cannot lift an account above Seed on its own. That includes conference talk, survey answers and skill tags. Only code motion and a named engineer can do that.

The six dimensions and how to score each one

Score each dimension 0, 1 or 2 from evidence you can link to. A 2 always means closer to leaving. Five dimensions measure drift toward the alternative. The sixth, coupling, measures what holds the account in place, so it scores in reverse.

1. Version pin against the reference release

What it proves: the account chose not to follow the incumbent past the license line. A required_version of = 1.5.7, ~> 1.5.0 or < 1.6 holds Terraform on the MPL 2.0 line. A Redis package or image pinned at 7.2.x does the same for Redis. Score 2 when git blame shows the constraint was written or tightened after the relicense. Score 1 when the pin exists but you can't tell where it came from. Score 0 when the code allows or requires a post-relicense version, because that account has already accepted the new license.

When it lies: the pin may belong to the hosting platform rather than the account. Hosted platforms that compete with HCP Terraform stopped at 1.5.7. A ~> 1.5.0 copied from a template says nothing about intent either.

One more trap. Through OpenTofu 1.11, a constraint such as ~> 1.5.0 or < 1.6 also rejected tofu. From OpenTofu 1.12, required_version in a plain .tf file is ignored, and constraints are enforced only in .tofu files or in a language block with compatible_with. Don't read a constraint as "tofu-safe" or "tofu-blocking" until you know which engine version reads it.

2. Pin age and provider drag

What it proves: the pin has started to cost something. Terraform 1.11.0 shipped on 27 February 2025 with write-only attributes. That was about 18 months after the freeze, and it was the first feature a 1.5.7 pin could not use. Once an account's providers adopt such features, the pin starts failing outright. In one live case, an open issue on code0-tech/mensa says the repo is "pinned to 1.5.7 which is the last version before the license change to BUSL" and that "providers are starting to use features only available in newer terraform versions like actions and write-only attributes." That issue appeared roughly 26 months after the relicense.

Score 2 when the account's own providers already need a newer engine: a failing upgrade, an open issue, or a provider held back on purpose. Score 1 when the pin is older than about 18 months and the providers it uses have releases it has not taken. Score 0 when nothing is pushing on it.

Score drag by the date the account's specific providers first needed 1.11, not by the age of the pin. Nobody has published a typical holding period across accounts, so 18 months is a starting point, not a measurement.

When it lies: drag forces a decision but doesn't pick the direction. The account may simply upgrade to the incumbent's current release. The alternative can hit the same wall: Cloudflare's provider v5.6 failed on OpenTofu with "WriteOnly Attribute Not Allowed". When drag comes with commercial coupling, expect the account to stay with the incumbent.

3. Migration branches, pull requests and issues

What it proves: someone has started the work. Look for branches and PRs whose names or diffs mention tofu, opentofu or valkey and touch production root modules or cache configuration. Also look for internal issues that have an assignee. Score 2 for a dated branch or PR on production code. Score 1 for an issue or discussion with no code, or a branch with no recent commits. Score 0 for nothing.

When it lies: one engineer's abandoned spike looks like a migration. Check the last commit date and whether the diff touches anything that ships. This is also the dimension code search cannot see. See the warning in the procedure.

4. CI configs and lock-file references

What it proves: the alternative actually runs. After a switch, the lock file records entries such as provider "registry.opentofu.org/hashicorp/aws", and .tofu files appear. The CI config shows which binary each pipeline calls. Score 2 when at least one production root module or production pipeline runs the alternative. Score 1 for a sandbox, demo repo or test matrix only. Score 0 for none. If every production root module has already switched, the account drops out of this read. The displacement is done, and the account belongs to a different motion.

When it lies: one sandbox lock file looks like a switch. Score the share of production root modules, not whether a lock file exists. I have no source on how well code search covers CI setup actions and Docker base images, so open those files directly.

5. Upstream activity by the account's own engineers

What it proves: a named person inside the account cares enough to work on the alternative in public. That is the closest thing to a champion that repo evidence offers. Score 2 when a verified current employee has opened or commented on issues in the alternative's repo about their own usage. Score 1 for activity on the incumbent's tracker about the license or the pin, for activity by someone whose employer you can't confirm, or for a profile skill tag alone. Score 0 for none.

This dimension counts double. In public write-ups of Fidelity's migration, the technical changeover took little effort but governance alignment was a significant hurdle, which makes the intent gap organisational. Whether upstream activity predicts migration has not been established publicly, so the double weight is my judgement.

When it lies: vendor staff look like customer interest. Spacelift sponsors five engineers dedicated to the OpenTofu project, and contributions also come from Gruntwork, env0 and dozens of independent engineers. Every issue author needs an employer check before they count.

Skill tags are the weakest form of this evidence, which is why they cap at 1.

Compare that with Spacelift's own report that 58% of Terraform stack runs on its platform over a 30-day window were OpenTofu. That figure comes from one vendor's own customers, but the contrast still holds. In a 25-profile US sample, the most common OpenTofu title is Senior DevOps Engineer (3). The German 25-profile sample is led by SAP (2), Siemens, Bosch, Hetzner Cloud and Capgemini. That suggests adoption in regulated enterprises rather than startups, but n=25 is too small to rely on.

6. Depth of incumbent coupling

What it proves: how much the account would lose by leaving. HCP Terraform-only features such as Sentinel and Stacks don't run on OpenTofu, and leaving HCP-specific workflows can be the largest hidden cost of a migration. Score 2 for the open-source CLI only with self-run CI. Score 1 for open-core use, meaning a hosted platform or managed service on top of the engine with no commercial-only features. Score 0 when Sentinel policies, Stacks or HCP-specific workflows appear in repos or CI.

When it lies: some coupling is organisational and never shows in a repo, as in Fidelity's case. How often coupling actually blocks migrations has not been established publicly. Treat a 0 as a cost, not a wall. That is why it blocks Displace Now but only produces Leave when there is also no champion.

How do six scores become a verdict?

Add the scores with dimension 5 counted twice, for a total out of 14, then apply three gates. I set the thresholds so that Displace Now needs both code motion and a named person. They have not been calibrated against closed deals, so log your outcomes and adjust them.

Total = D1 + D2 + D3 + D4 + (2 × D5) + D6

Two overrides sit above the table:

• Already out: every production root module runs the alternative. Remove the account from the displacement list.
• Managed service: if the account uses the incumbent as a managed service, any Leave verdict is provisional. The provider may move the account without the account doing anything (see the failure modes below).

Account:
Incumbent and reference release (license):
Scored by / date:

D1 Pin vs reference release (0-2): __  evidence:
D2 Pin age and provider drag (0-2): __  evidence:  first provider needing newer engine:
D3 Branches, PRs, issues (0-2): __  evidence:  last commit date:
D4 CI and lock files (0-2): __  evidence:  production root modules switched: __ of __
D5 Own engineers upstream (0-2, counts x2): __  named, employer confirmed:
D6 Incumbent coupling (0-2, reverse): __  evidence:

Total (out of 14): __
Gates: D3 or D4 >= 1 [ ]  D5 >= 1 [ ]  D6 >= 1 [ ]
Overrides: Already out [ ]  Managed service [ ]
Verdict: Displace Now / Seed / Leave
Re-check date:            Trigger that would move it:

"Uses the competitor" is a fact. "Halfway out the door" is a score, and it needs links.

Step-by-step: grading one account

The full read takes about 70 to 80 minutes split across a rep, an SDR and an AE. The order puts the cheap file checks first, so a clear Leave can stop before the AE spends any time.

Step 6 is the slowest, and it is where most false positives get in. Each issue author is just a GitHub handle until you know who employs them today. Refolk resolves a handle to a current employer and title in one query, which is what turns "someone at the company" into a named champion. It also lets you start from the other end, by searching for people at accounts that already show the pin.

Public migration write-ups disagree about the order of the work, and that affects which evidence appears first. Fidelity's account starts with consensus building, phased adoption and enablement, so the first signs may be issues and people (D3 at 1, D5) before any code. env0's checklist starts with confirming the OpenTofu registry has every provider the project depends on, so the first sign may be a provider audit in an issue. Either one is a legitimate start.

How the read goes wrong: failure modes and false positives

Most bad verdicts come from evidence that looks like intent but is really a vendor's default, leftover boilerplate, or blind spots in your own tools. Run the check for each failure mode before a score of 2 goes on the card.

1. The pin is a vendor artifact. A 1.5.7 pin can come from the hosting platform freezing at that version, not from the account's view on licensing. Check: the CI config and any Spacelift or env0 references. If the platform set the pin, D1 is 1 at most.
2. The pin is stale boilerplate. A ~> 1.5.0 constraint copied from a template looks the same as one written on purpose. Check: git blame. If it predates the relicense and nobody has touched it since, score 1.
3. The signal changed meaning. required_version semantics changed in OpenTofu 1.12, so a constraint that once blocked or allowed tofu now means nothing in a plain .tf file on newer releases. Check: look for .tofu files or a language block with compatible_with instead.
4. Branches are invisible. Code search scores an account with a migration in progress as zero, because the branches it would need are not indexed. Check: always run the branch and pull request pass.
5. A sandbox lock file. One registry.opentofu.org entry in a demo repo gets counted as a migration. Check: score the share of production root modules, not whether a lock file exists.
6. Vendor staff counted as champions. Issue authors on the OpenTofu repo who work for Spacelift, Gruntwork or env0 look like customer interest. Check: confirm each author's employer in Refolk before scoring D5.
7. Biased surveys set your prior. Percona participates in the Valkey fork, and Firefly and Spacelift are vendors. Check: use their numbers to set the base rate, never to score one account.
8. The provider decides for the account. An account scored Leave can be moved by its managed provider anyway. Of Aiven's roughly 15,000 Redis-to-Valkey migrations, about 11,000 ran automatically during scheduled maintenance, about 73%. Check: for managed-service accounts, find the provider's version plans and re-check around its maintenance windows.

Failure modes 1, 2 and 5 inflate the score, so they produce false Displace Now verdicts and waste AE weeks. Failure modes 4 and 8 deflate it, so they produce false Leave verdicts and lose deals to whoever looked at the branches. Treat both kinds as equally serious.

Before the AE gets the account: the handoff check

An account is ready for an AE when every score has a link and every check that inflates or deflates the score has been run. The checklist below is the minimum. For accounts scored Seed, the template after it is a first touch that leans on the drag mechanism without overclaiming.

Subject: {repo} and the 1.5.7 pin

Hi {first name},

{repo} pins Terraform at 1.5.7, the last MPL 2.0 release. Providers have started adopting features that need 1.11 or later, write-only attributes first, and a 1.5.7 pin can't use them.

When {provider} gets there for you, the choice is to upgrade under the BSL or to move the engine. I wrote up what the second path involves for an estate with {number} root modules.

Want it? A one-word reply is enough.

{name}

How long does a verdict stay true?

Not long once code starts moving. A small estate can go from first branch to cutover in weeks, so a Displace Now verdict goes stale fastest. A Seed verdict holds until a dated trigger, usually provider drag. No one has published a measure of the time from first migration branch to cutover, so the speeds below are case evidence, not norms.

Fidelity's estate covered more than 50,000 state files and more than 4 million resources, yet it still moved 70% of its projects in two quarters. The small-team estimate is secondary and unattributed, so use it only to size the window. For an estate with a few dozen state files, assume the window from first branch to done is shorter than a normal sales cycle.

My default re-check cadence, which is not measured:

• Displace Now: re-score within two weeks. If the branch has merged and every production root module has switched, apply the Already out override.
• Seed: re-score at the earlier of 90 days or the date the account's next provider needs a newer engine than the pin allows.
• Leave: re-score at six months, or when a managed provider announces a version change or end of life.

Re-run the reference-release step at the start of each new list as well. Upstream licenses have changed more than once, and a verdict built on the wrong reference release has every score wrong.