What this domain covers#
The second domain extends the first by asking, for each strategic third-party component identified in domain 1, whether a workaround plan exists in the event of failure, license flip, unilateral price hike, or jurisdictional blockage. The plan can take several forms: an identified and named alternative, an estimate of migration time and cost, a level of testability (never tested, PoC carried out, working test environment, partial migration already conducted).
The domain does not ask that you have tested everything — it asks that you have thought through the question for each strategic component, and that you declare it honestly, including by mentioning the components for which no alternative is identified to date. This honesty is explicitly valued.
Why this domain matters#
Thesis 5 of the manifesto founds the requirement of domain 2: “an open source project whose contributions, artefacts or roadmap depend on a single sponsor is a revocable free project.” Revocability is not hypothetical — it has materialised on several occasions in recent years on massively used components. MongoDB SSPL in October 2018, Elastic SSPL in January 2021, HashiCorp BSL in August 2023, Redis BSL/SSPL in March 2024, MariaDB under K1 Investment Management in September 2024, the IBM acquisition of HashiCorp finalised in 2025: each event caught off guard a substantial number of organisations that had not anticipated the situation and found themselves in a position of weakness when reacting.
The cost of a migration carried out under time pressure is typically several times higher than that of a migration planned cold. Having a workaround plan, even an unexecuted one, transforms a vague risk into an operational option. For a client assessing your solution, the existence of the plan is a concrete guarantee that you offer them: if the situation changes abruptly, you know what to do. For you as a provider, it is also a protection against tariff or contractual escalation by a publisher that knows itself to be without a tested alternative.
At the collective scale, the publication of workaround plans reveals where the field actually has credible alternatives — Valkey or KeyDB for Redis, OpenTofu for Terraform, OpenBao for Vault, OpenSearch or PostgreSQL for Elasticsearch — and where the blank zones remain. This information feeds the observatory of gaps.
What is asked, by category of declarant#
For a software publisher. For each strategic component in domain 1, an identified alternative (named where possible), an estimate of migration time in person-days and of calendar duration, and the level of testability achieved to date. Explicit mention of the components for which no alternative is identified, with assumptions about the course of action in the event of failure.
For a hosting provider. Migration plan for the central components of the stack in the event of unavailability. The VMware-Broadcom case is emblematic: with price hikes of up to 1050% observed for some clients (AT&T cited publicly) from January 2024 onwards, the question of the alternative to VMware vSphere — Proxmox VE, OpenStack, bare KVM, other — becomes a legitimate question that all hosting providers must ask themselves and declare publicly.
For a distributor or integrator. Plan in the event of unilateral changes to conditions by the original publisher, of massive price hikes, or of cessation of service to the European market. Does the distributor have the technical skills to ensure continuity of service on its own? Can it propose a migration to an equivalent alternative? Are clients warned upstream of the structural risks associated with the distributed solutions?
An example of an honest, well-done answer#
A French publisher of document management software, 35 staff, declares in domain 2 its strategy component by component. For PostgreSQL: no workaround plan necessary, distributed governance not revocable. For its Valkey cache: KeyDB alternative identified, migration estimated at 2 person-days, not tested to date. For its Elasticsearch search engine (which it still uses in certain client configurations): OpenSearch alternative identified and functionally tested in a pre-production environment over 3 days in September 2025, migration estimated at 12 person-days per client, reversible switchover. For Keycloak (in case of Red Hat / IBM tightening): no formalised plan to date, Authentik alternative to be explored within 12 months, declared as a blind spot in domain 7. For its hosting with Outscale (SecNumCloud-qualified): OVHcloud alternative identified but migration not tested, estimated at 30 person-days.
An anti-pattern to avoid#
A domain 2 that boils down to “we follow market developments and will adapt our strategy as needed” is a pious wish that brings no security. Symmetrically, an over-ambitious declaration (“we are capable of migrating each component in less than 24 hours”) without concrete testing is a false reassurance that will turn against the declarant the day the situation arises. Honesty weighs more than performance: “alternative identified but not tested, estimated at 15 person-days” is a perfectly acceptable answer.
Articulation with the other domains and commitments#
Domain 2 logically depends on domain 1 (the components must be identified before their workaround can be described). It is articulated directly with the user commitment user-004-study-migration-single-vendor: what you seriously study as a migration on the user side corresponds to what your provider ideally declares in domain 2. It is also articulated with domain 5 (continuity in the event of failure): workaround plans are part of the answer to the failure scenario, but not the whole of it.
How to fill in the form#
For each strategic component listed in domain 1, you document a substitution plan: which alternative, at what cost, and whether it has been concretely tested.
Component concerned#
- Component concerned (reference or name): ideally use the exact name as it appears in domain 1, to ease reconciliation by the reader.
Identified alternatives#
A library proposes the most common substitutes by category. You can add others freely.
- Name: precise name of the candidate substitute (e.g.: MariaDB as an alternative to MySQL).
- Publisher or foundation: who controls this substitute.
- Qualification status: where do you stand? Suggested values: identified, technically evaluated, prototype validated, in production. Be precise.
- Comment: known limits, functional gaps, retraining required on the team side.
Migration estimate#
- Effort (person-months): how many person-months in total to perform the switchover. A rough estimate is worth more than nothing.
- Lead time (calendar months): between the trigger and going live. Includes training, parallel running, cutover.
- Main cost items: where the effort goes (dev, training, licences, re-tests, data migration…).
Concrete test#
This is what distinguishes a credible plan from good intention.
- Test status: Fully tested (complete migration already played in a sandbox or real switchover), Partially tested (functional subset), Not tested (paper only).
- Date of the last test: a three-year-old test no longer has the same value as a recent test.
- Comment on the test: what worked, what did not work, scope covered, pitfalls encountered.
Sales discourse and internal skills#
- Sales discourse qualified with regard to risks: does your client relationship honestly mention these dependencies and risks? Yes / Partial / No. The comment provides detail (transparency page on the site, mention in the contract, etc.).
- Internal skills for continuity: do you have the profiles needed to conduct a migration without depending solely on the outgoing provider? Be honest: “no” is more useful to the reader than a façade “yes”.