What a copy does not settle
We work with investors, owners and managers in mission-critical B2B software. A recent buyer brief put the question plainly: is the target’s clearing engine genuinely differentiated technology, or a highly replicable structure? It is the right question, asked a stage too early.
For mission-critical B2B software, reaching feature parity is a smaller achievement than establishing economic substitutability, and the support for even that is thin: no case we reviewed shows a copy alone taking a customer. Wykeham applies five tests to establish which barrier, if any, survives the copy.
The path after the copy
Software has two kinds of asset. Features and code move with engineering spend. The non-code assets build up through elapsed use and through third parties: the system of record, first-party data, live integrations, workflow ownership and reference customers. Only some of them can be bought.
That split sets a sequence. A challenger has to match the features, then the security and scale an enterprise buyer expects, then reach the non-code assets, win acceptance, move the customers, reach a scale that sustains the product, and only then earn a return at the price it took (see Exhibit 1). Both cases below leave the incumbent’s technology out of that role.
Exhibit 1
Copying the product clears only the first stages of the path
Features and code
Non-code assets
Outcome
| Stage number | Stage | What the challenger must achieve | Asset type | How far engineering spend compresses it |
|---|---|---|---|---|
| Features and code | ||||
| 01 | Feature replication | Match the visible functionality | Features and code | Largely |
| 02 | Enterprise-grade replication | Match security, scale and controls | Mainly features and code | Largely, with time for hardening |
| Non-code assets | ||||
| 03 | Access to non-code assets | Obtain data rights, integrations, workflow knowledge, permissions | Non-code assets | Partly; some can be bought or licensed |
| 04 | Customer acceptance | Win reference customers and buyer trust | Non-code assets | Less; depends on elapsed use and third parties |
| 05 | Migration | Get customers to move | Non-code assets | Less; depends on the customer's own migration risk |
| 06 | Competitive scale | Reach an installed base that sustains the product | Non-code assets | Less; depends on calendar time and network position |
| Outcome | ||||
| 07 | Entrant economics | Earn a return at the price needed to win | Outcome | Not directly |
Source: Wykeham analysis of the substitution path described in this article.
Notes: Features and code move with engineering spend. Non-code assets build up through elapsed use and third parties, and some can be licensed. Feature parity and economic substitutability are different states, and clearing the first does not establish the second.
Limits: A framework, not a ranking or a finding. It defines the sequence; it does not establish which stage holds the barrier for any asset.
The commercial question
Given that path, the question for a deal team, an investment committee or a board is which barrier stays durable over the hold period once a credible rival has matched the product. Which barrier ranks highest, and how fast one weakens, remain open questions on the evidence we reviewed. Similarly, mid-market assets, and custody and clearing software in particular, sit outside the reach of those sources.
The five tests
The five tests are ordered so that the one most likely to reverse the answer comes first: switching dynamics, the entrant’s starting position, the non-code assets that remain after parity, the incumbent’s technical architecture, and durability over the hold period. Each follows the same sequence, from the mechanism behind the test, to the evidence the public record supplies, to its meaning for the decision.
Retention is not the reason
Substitution only happens if customers move. Retention shows only that they stayed. It does not show why, or whether switching costs or simple inertia kept them. Investors and sellers should look for documented replacement attempts, finished or abandoned, and what drove their cost and elapsed time.
Birmingham City Council’s first Oracle go-live failed in April 2022. Auditors put the overrun above £90m by February 2025, and by January 2026 the forecast reached £144.4m out to 2027/28. On the auditors’ account the friction sat mostly on the council’s side, in processes, data migration, controls and readiness, making it an organisational cost and not a technical one, though that reading rests on one review.
The council is now rebuilding on standard configuration instead of the customisations that failed, and as at January 2026 that rebuild had slipped past its April date and wasn’t live. Still, what matters is friction that appears after parity. Retention on its own proves little.
Where the rival starts
A competitor that already owns the platform, the licences or the counterparties starts several stages along. So the test begins with what the credible rival already owns before it builds anything.
Salesforce held its own platform, saw its non-compete with Veeva lift on 1 May 2023, and expanded its IQVIA partnership in April 2024. Of the eighteen decided top-20 accounts, six then moved.
However, that count was put to Veeva at an investor conference and not disputed, rather than disclosed, so it leaves open which advantage decided any account, and the twelve retained accounts stay equally unexplained. Investors and management teams should worry most about a rival that already owns the non-code assets before it starts.
The assets underneath
Engineering spend closes a feature gap more readily than it builds the assets underneath. So this test assumes the product is copied and works through what remains: first-party data, integrations, workflow ownership, references and network position.
IQVIA’s data became usable with both vendors after a settlement in August 2025, on the parties’ own account, and that is an integration barrier dissolved by settlement, not by engineering. Research houses agree that what survives is in the non-code layer, but each of them names a different asset, so they agree only at category level.
Epoch AI’s MirrorCode benchmark had models reimplement command-line programs from behaviour alone, with no source code. One rebuild of a 16,000-line toolkit passed 2,000 of 2,001 tests, work Epoch put at two to seventeen weeks for a person. Whether the vendor owns a permission a substitute must obtain is left open, and a barrier that can be bought, licensed or rebuilt will hold only until someone pays for it.
Technical architecture
An incumbent can lower its own customers’ switching costs without a competitor acting, which makes the architecture and the roadmap part of the commercial question.
Veeva triggered its own re-platforming, and on our reading of the filings that narrowed the gap its customers faced. However, filings cannot settle the technical question. That needs independent technical diligence. A roadmap that forces customers to reimplement may hand a challenger a window that would otherwise stay closed, and investors and owners will want that window shut for the length of the hold.
Does it last?
A barrier worth paying for has to hold over the years the asset is owned, tested against retention, pricing and win-loss once the copy is in the market, and the public record we reviewed stops short of any hold period.
Morningstar’s moat review for the first half of 2026 puts technology at the head of its downgrades. But Morningstar rates moats over a decade or more, a horizon well beyond a sponsor’s hold or a corporate planning cycle. Birmingham’s move to standard configuration and those downgrades point the same way. How fast a barrier weakens stays an open question.
Of the five, a case resting on retention or on a rating built for a different horizon offers the weakest basis. The screen tests all five dimensions and singles out none (see Exhibit 2).
Exhibit 2
Public evidence tests five dimensions and singles out none
Units: Account counts, dates and source horizons as labelled. Not converted into a common score.
The five tests
| Test number | Dimension | Test | Look for | Discount when |
|---|---|---|---|---|
| 01 | Switching dynamics | Documented replacement attempts and what drove their cost and time | Friction evidenced after parity | Retention is the only evidence |
| 02 | Entrant's starting position | What the credible rival owns before it builds | Rival still lacks consequential non-code assets | Rival owns or can contract for them |
| 03 | Non-code assets after parity | Whether each remaining asset is the operative barrier | A late-stage dependency hard to compress over the hold period | Every asset purchasable, licensable or rebuildable |
| 04 | Incumbent's technical architecture | Maintainable, scalable, secure; no forced reimplementation | No forced reimplementation over the hold period | Roadmap forces re-platforming |
| 05 | Durability over the hold period | Win-loss, retention and pricing after the copy | Asset-level behaviour shows the barrier persisting | Retention or a long-horizon rating offered as proof |
What the public record shows
| 01 | Switching dynamics | Birmingham first go-live failed April 2022; overrun above £90m by February 2025 and forecast £144.4m by January 2026; friction largely organisational on the auditors' account; standard-configuration rebuild slipped past April 2026 and was not live |
|---|---|---|
| 02 | Entrant's starting position | Platform ownership; non-compete lifted 1 May 2023; IQVIA partnership expanded April 2024; six of eighteen decided top-20 accounts moved, a figure put to Veeva and not disputed |
| 03 | Non-code assets after parity | IQVIA data usable with both vendors after the August 2025 settlement; research houses name different assets; Epoch's MirrorCode rebuilt a 16,000-line toolkit to 2,000 of 2,001 tests from behaviour alone |
| 04 | Incumbent's technical architecture | Veeva triggered its own re-platforming. Independent technical diligence: not reached |
| 05 | Durability over the hold period | No hold-period evidence. Morningstar's first-half 2026 review puts technology at the head of its moat downgrades, on a horizon of a decade or more |
Source: Veeva filings and investor remarks; Birmingham City Council auditors via Computer Weekly and The Register; IQVIA and Salesforce releases; Morningstar; Epoch AI; Wykeham analysis.
Notes: Birmingham shows implementation failure, not a rival reaching feature parity. Retention shows that customers stayed, not why. The Veeva account count was put to the company and not disputed, rather than disclosed. Signals listed are generic diagnostics, not findings about any asset.
Limits: No barrier ranked, no decay measured. Pricing and retention durability, mid-market magnitude, and transfer to custody and clearing software are all outside what these sources reach.
Where the case breaks
These are the red flags. Discount a defensibility claim when the entrant already owns the non-code assets or can contract for them, when every named barrier looks purchasable or commoditised, when regulated describes the customers instead of the product, when retention or a long-horizon rating stands in for cause, and when the incumbent’s own roadmap forces a re-platforming.
What a strong case looks like
A case supported by evidence names its mechanism rather than claiming a moat. The strong version shows three things: a dependency that survives credible feature parity, evidence that the barrier changes replacement decisions, and an incumbent able to hold it. The weak version relies on feature differentiation, retention or category multiples, and any of them can describe a business that simply hasn’t been tested. Across the sources we reviewed, each candidate barrier is missing at least one of the three, and we stop short of a ranking here.
The decisive test
Assume the visible product is copied, name the rival, and test whether any dependency that survives parity stays durable over the hold period, checking your findings against replacement behaviour and technical architecture. Whether a competing engineering team could rebuild the clearing engine matters less than what that team would still have to buy or license once it had. Until that is evidenced on the asset, defensibility belongs in diligence, not in the premise.
On a named asset
For a given asset, the answer comes from diligence, not from published sources. For an acquirer, the tests set the diligence scope and the price of an unevidenced claim. For an owner preparing an asset for sale, they identify which defensibility claims need evidence before a buyer asks. For a management team, they show where the advantage actually is and where the next investment belongs.
On a live asset, commercial due diligence with an architecture review inside it reaches the dependency map, the data rights and the entrant’s path. The public record does not.
To discuss how these tests apply to a specific asset, please get in touch.
