Guarantee PaaS clients application portability of their workloads — standard OCI packaging, manifests portable to diverse targets (Compose self-hosted as priority, other PaaS, Kubernetes as an option), detachable managed services, tested relocation contract#

What this is, concretely#

For a PaaS provider — understood as any operator of a workload-execution platform that handles build, deployment, scaling, and a set of managed services (database, cache, message queues, observability, authentication) — reversibility cannot be reduced to a data export. The client has invested code and configuration specific to the platform: proprietary build pipelines (closed buildpacks, non-standard auto-detection conventions), specific orchestration APIs (triggers, webhooks, scaling), non-portable managed services (in-house auth, proprietary queues), proprietary packaging formats. At the moment of leaving, what looks like a “code migration” is in reality a project of partial rewrite — often multi-month, sometimes multi-year, and always at a cost incomparable with that of a SaaS data export.

The commitment consists of offering PaaS clients, from the contract onwards, an application portability guarantee structured around four elements:

• Standardised packaging formats. Client workloads are packaged according to open standards (compliant OCI image, public and reproducible Dockerfile) — not in a proprietary binary format that only the platform can read back, nor under a commercial label that does not correspond to any open spec.
• Deployment manifests portable to diverse targets. The deployment configuration (environment variables, secrets, allocated resources, inter-service dependencies) is exportable in several standard formats suited to the client’s profile — a Docker Compose file for the priority target light self-hosted (executable on a VPS or a standard machine fitted with Docker or Podman, without a cluster to orchestrate), and on demand a Helm chart, Kubernetes manifests, or a Kustomize overlay for clients whose complexity or volume justifies an orchestrator. The Compose target is the priority because it is itself the least dependent on a third-party provider: it runs on any Linux host.
• Detachable managed services. For each managed service provided by the platform (PostgreSQL, Redis, Kafka, MinIO/S3, OpenSearch, etc.), the provider publishes a documented self-hosting procedure (official or upstream community image, compatible schema, data-migration and replication scripts); proprietary managed services (for example, an authentication system specific to the platform, an in-house queue, a specific event orchestrator) are explicitly identified as such and accompanied by a replacement strategy (recommended open source alternative and mapping scripts).
• Tested relocation contract. The client contract carries a numerical commitment on the relocation timeframe (typically 90 to 180 days for a standard workload), paired with a periodic documented test — at least once a year, the provider publicly demonstrates (anonymised) that a representative workload can be relocated. The reference demonstration is carried out in self-hosted via Compose, because it is the most accessible target and the one most independent of any other provider; the other targets (another compliant PaaS, managed Kubernetes, self-hosted Kubernetes) are documented in addition for clients who need them.

This commitment falls within domain 5 of the Sovereignty Profile (continuity) and directly complements pub-009-standard-reversibility-clause (which covers data for SaaS) by covering application workloads for PaaS. It forms part of condition 3 “Standard reversibility clause” among the conditions of equivalence for the proprietary publisher (cf. About page), but declines its PaaS-specific version — the condition remains conceptually unique, its operational declarability splits into two according to the service model.

Why this commitment matters#

Thesis 13 of the manifesto grounds this commitment: “Technological sovereignty is not an end in itself. It is the condition under which an organisation — a business, an administration, an individual — can continue to operate its data and conduct its operations, whatever happens: provider failure, geopolitical conflict, sanctions, hostile takeover, unilateral flip by a publisher. It is a right, not a comfort.” This thesis applies to PaaS with particular force: the lock-in is structurally deeper there than at the SaaS level, because it bears on the code and on the execution architecture, not only on the data. A SaaS client who wants to change provider exports their data and migrates their users; a PaaS client who wants to change provider, without an explicit portability arrangement, must reinstrument their build pipelines, rewrite their deployment configuration, replace each proprietary managed service with an equivalent and re-prove the whole set — several European companies hosted on US PaaS platforms discovered, at the moment of an unfavourable pricing decision, that migrating elsewhere represented six to twelve months of engineering work, with no equivalent immediate managed alternative.

An important note on the relocation target. Most PaaS providers implicitly assume that a client leaving them will go to Kubernetes — managed at another provider or self-hosted. This commitment rejects that assumption as a priority target, for two reasons. First, Kubernetes is itself a project under American governance (CNCF, hosted by the Linux Foundation, with predominantly US sponsors and contributors), with no established European alternative: making it the sole portability target reproduces, at the orchestrator layer, the dependency one is trying to break at the platform layer. Second, self-hosted Kubernetes is a heavy infrastructure to set up, secure, and maintain: for the great majority of application workloads, it is overkill the client does not need and whose maintenance falls back on them. The priority target of this commitment is therefore self-hosted via Docker Compose: sufficient for the majority of application workloads, executable on a standard VPS, without a cluster or dependence on an orchestrator under foreign governance. Kubernetes (managed or self-hosted) and other PaaS remain options, not prescriptions.

The annexes of the device also document the case of SecNumCloud / Cloud Temple PaaS OpenShift, S3NS managed Kubernetes, and other redistributions of US stacks under a French label: even “sovereign” providers do not guarantee application portability by construction, and the jurisdictional qualification says nothing about technical portability. This commitment fills that blind spot. The new section “Conditions of equivalence for the proprietary publisher” of the About page cites this commitment as the PaaS declension of condition 3, alongside pub-009: the condition remains unique, but its operational proof splits according to the service model.

A concrete example#

A French container PaaS provider for web applications and APIs, around 50 employees, around 200 ETI/SMB clients, takes this commitment in May 2026 with an 18-month horizon. The concrete actions unfold as follows:

• Internal audit of the platform’s proprietary dependencies in the third quarter of 2026: the in-house authentication system is identified as proprietary; the in-house queue is flagged for eventual replacement by documented NATS and/or Redis Streams; the orchestrator, already based on upstream Kubernetes, is natively portable on the OCI image side.
• Publication on the website of a “Leaving the platform” documentation in the fourth quarter of 2026: for each managed service, its self-hosted equivalent (upstream PostgreSQL, upstream Redis, S3-compatible MinIO, upstream OpenSearch, Authelia or Keycloak as a replacement for the proprietary auth) with official OCI image, base schema, and migration script; a reference docker-compose.yml file assembles the whole for execution on a standard VPS.
• Integration into the standard contract, early 2027, of a 120-day relocation clause for standard workloads, 180 days for workloads with intensive proprietary services, with a commitment to free delivery or capped-cost delivery of the artefacts.
• In September 2027, first public anonymised relocation test on a representative workload (e-commerce, around 50 GB of database, queue, cache, delegated authentication). The demonstrated target is self-hosted via Docker Compose on a standard European VPS: relocation is achievable in 78 days, including 18 days writing the mapping Compose file (upstream PostgreSQL, upstream Redis, MinIO for object storage, Authelia for auth replacing the proprietary system) and 60 days of progressive data switchover. The feedback report also documents alternative paths for those who justify them: porting to another compliant PaaS in 95 days, porting to managed Kubernetes in 110 days, porting to self-hosted Kubernetes in 130 days (the additional complexity coming from orchestration and not from the workload itself).

By the 18-month horizon: the clause appears in 100% of new contracts, a Compose self-hosted relocation demonstration has been published, two clients actually trigger a relocation study (one to migrate to a peer, the other to bring it in-house on Compose self-hosted) and both operations confirm the announced timeframes. The sales team observes that mention of this detailed arrangement is now explicitly a positive in tender defences against US PaaS competitors with vague portability messaging.

Anti-pattern to avoid#

Five classic traps empty the commitment of its force:

• Reducing portability to packaging alone — “your containers are yours, you can export them” — without addressing managed services or deployment configuration: Docker packaging is only a minor part of the lock-in, and most of the migration cost lies in proprietary managed services and in rebuilding the configuration.
• Declaring a proprietary format “standard” under a commercial label that corresponds to no open spec (for example a slug specific to the platform): a format is only standard if it is readable and reconstructible by a third party without permission.
• Prescribing Kubernetes as the sole relocation target: this is shifting the dependency by one notch (from the PaaS to the orchestrator under American governance) while needlessly weighing down the infrastructure the client will have to maintain; the priority target must remain light self-hosted via Compose, the rest being offered in addition.
• A self-hosting documentation written but never maintained or tested: it becomes inoperable at the first version change and its purely formal existence misleads the client.
• A relocation test conducted on a toy workload rather than on a representative one: the demonstration loses all value if the test does not bear on a realistic load — base size, inter-service dependencies, proprietary services actually used.

Success indicators#

By the 18-month horizon, you can reasonably consider this commitment fulfilled if the portability clause appears in 100% of your new contracts; if the “Leaving the platform” documentation is published and kept up to date, with a verifiable reference Compose file; if at least one public relocation test has been conducted on a representative workload with Compose self-hosted as the principal demonstrated target, and its feedback published in anonymised form; if the contractual relocation deadline is met when actual exit requests come in.

JSON schema category: publication. Default horizon: 18 months. Applicable to: businesses.