When Your Customer Goes Sovereign, Can Your Product Follow?
Share this:
A few days ago it was announced that Airbus is moving 70 of its most sensitive applications off AWS. The replacement is Scaleway, a French provider owned by the iliad Group, on a contract worth more than €50 million over as much as ten years. The workloads making the move are the ones that run the company: ERP, manufacturing, CRM, and the product-lifecycle software that spans aircraft design through the factory floor. Airbus keeps AWS for systems it considers non-critical, like its Skywise aviation platform and some customer-support tooling. The critical data goes to a European provider, and the stated reason is to keep those data assets outside the reach of foreign extraterritorial law.
What this means for software vendors
Airbus is relocating its own systems here, not buying software, but the sovereignty policy behind the move reaches both. A company that pulls its crown-jewel data out from under US jurisdiction is not going to hand that same class of data to a SaaS vendor whose product runs in a US-operated account. The rule that governs where Airbus runs its own ERP is the rule its procurement applies to what it buys. For a software vendor, that turns an internal migration into a purchasing requirement: if your product touches that class of data, it has to run inside the customer’s jurisdiction to be a candidate at all. Airbus is one visible example, and the same reasoning is spreading across regulated and public-sector customers in Europe.
We recently wrote about running your product on your customer’s cloud as the fastest path to a deal, where the driver is commercial: committed spend, marketplace drawdown, and co-sell. Sovereignty is the same translation problem applied to a harder constraint. This post assumes you read the mechanics in that earlier post, so we won’t repeat how the translation works. What we want to cover here is why a sovereignty requirement behaves differently from a normal procurement ask and why it reduces to the self-hosting problem.
A sovereignty requirement is a hard constraint
Most security and compliance requirements have a configuration answer. A customer asks for SOC 2 and you send the report. They ask for encryption at rest and you enable it. They ask for data residency and, in the soft version, you point at a region in their country and move on.
Data sovereignty is a legal requirement about jurisdiction, not a technical setting. The customer’s concern is which government can compel access to the data under its own law. Under the US CLOUD Act, US authorities can require a US-headquartered company to produce data it controls regardless of where the servers physically sit. Putting the data in a US hyperscaler’s in-country region, such as AWS in Paris, moves it onto local soil but leaves a US company operating it, so it stays reachable. No region choice, encryption option, or compliance attestation changes who holds legal authority over the operator.
For the customers who raise this requirement, mostly European enterprises and public-sector organizations, a deployment in a US-operated account does not qualify; the product has to run on infrastructure operated within the customer’s own jurisdiction.
It reduces to the self-hosting problem
We build for software vendors delivering into their customers’ own environments: the self-hosted model where your product runs inside the customer’s infrastructure rather than your account. A sovereignty requirement is a specific case of that. The customer wants your product running on infrastructure they control, in a jurisdiction they trust, with the data staying inside that boundary. The destination can be an on-prem Kubernetes cluster, a private VPC in the customer’s own account, or a sovereign provider like Scaleway or OVHcloud. In every case the technical task is the same one the portability post described: take a product built for AWS and run it somewhere that is not AWS.
What to plan for
If a sovereign deployment is on your near-term roadmap, get in touch and we can assess your stack service by service: which dependencies map to an equivalent on the target, which run through the compatibility layer, and where the coverage gaps are.
