It migrated to cloud 5-8 years ago. It let go of or lost its system engineers, network administrators, DBAs. It has a competent DevOps team on AWS or GCP — but with no bare-metal culture. It pays growing egress fees. It read the Terms of Service and discovered California jurisdiction. It wants to leave.

It cannot. Not alone. Its DevOps know how to deploy on EKS. They do not know how to configure a physical switch, dimension an IP addressing plan, choose a storage array, install a hypervisor, configure bare-metal monitoring. The competence left with the engineers who departed. This is "The Departure of the Last One Who Knows" applied at organisational scale.

The Sovereign Interface is an architecture. It does not implement itself — engineers are needed to write it.
The Gentle Exit is a principle. It does not execute itself — engineers are needed to migrate.
The Foundation of Iron is training. It takes 6 to 26 weeks — and the organisation does not have 26 weeks of runway before its next AWS bill.

The managed service provider is the missing engineer. They have the bare-metal competence the organisation abandoned. They know the migration path because they have done it dozens of times. And — fundamental difference from a hyperscaler — their business model is not to create a new dependency but to make the organisation capable.

Upon contract signature, a meeting brings together three parties: Ecritel teams (migration project manager + system engineers), the previous host's teams, and the client's teams. The objective is not to criticise the existing setup — it is to understand it precisely.

Two scenarios for access to the existing infrastructure:
Scenario A — Export by the previous host: the previous host produces data exports (databases, file systems, configurations), network diagrams, service lists. Ecritel receives and works from the exports.
Scenario B — Direct root access: when the previous host does not cooperate or when the timeline requires it, Ecritel teams request direct root access to the machines and carry out the inventory and exports themselves. They take operational responsibility for operations performed on the existing infrastructure.

The inventory covers all OS types (Linux distributions, Windows Server, BSD as applicable), all databases (MySQL, PostgreSQL, Oracle, SQL Server, MongoDB, Redis — each engine has its own export and migration procedures), middlewares, network configurations (VLANs, firewall rules, load balancers), certificates, cron jobs, operational scripts. Nothing is assumed — everything is verified and documented.

The analysis of the existing setup produces a dependency map — which services depend on which others, in what order they must be migrated to avoid breaking the chain.

Migration does not happen overnight. It is phased according to dependencies and risks. Each phase has a schedule, success criteria and a rollback procedure. Follow-up meetings are organised throughout the project — weekly during active migration, bi-weekly during stabilisation. The client monitors progress. They test proper functioning step by step. They validate before moving to the next phase. This validation is not passive — it is on-the-job training.

At the end of the migration, Ecritel teams write the Technical Architecture Document (TAD) — an exhaustive photograph of the infrastructure put in place: network diagrams, detailed configurations, operational procedures, backup and restore procedures, escalation contacts. This document belongs to the client. It is the first Runbook of the new infrastructure. And depending on the contract type, Steering Committees (COPILs) are organised — at Ecritel or at the client — to present SLAs, performance indicators, monthly incidents, planned developments.

Documentation as a transmission act: the TAD written by the managed service provider is not a bureaucratic document — it is the first act of transmission. The client's DevOps who read the TAD learn how their infrastructure works. Those who participate in writing it learn even faster.

COPILs as disguised training: when the provider presents monthly SLAs, they explain what happened, why, how it was resolved. The client's technical teams who attend these meetings are in continuous training without it being called training.

Shared on-call: in some contracts, the provider's engineers are available to the client's teams during incidents — not to replace them but to accompany them in resolution. A 3am incident resolved with the provider's engineer online teaches more than a full day of classroom training.

Formal knowledge transfer: in well-drafted contracts, a knowledge transfer phase is explicitly planned — training sessions on the client's specific infrastructure, handover of operational procedures, support for the first operations performed autonomously by internal teams.

Lived experience at Ecritel: a client has two machines — prod and preprod. They want to promote preprod to prod without transferring code, simply by swapping roles. Solution proposed: a file deposited via FTP by the client containing machine1=prod ; machine2=preprod. A script reads the file every X minutes and automatically reconfigures the HAProxy backend. The client remains in full managed services but is completely autonomous on deployments, with no provider intervention required per cycle.

What this illustrates: the provider wrote the script. They adapted the infrastructure to the business need. The opposite of cloud: "adapt your architecture to our managed services."

Ecritel accompanied clients to obtain a CSP licence in China from Paris. Infrastructures were synchronised between China and France via Unison or lsync for images. Pseudo-L2 configurations at international scale were set up to ensure network continuity between distant sites. Dedicated fibre links can connect client offices or another site — something cloud cannot do physically. Traffic is included in the contract or at very reasonable rates. No egress fees discovered at end of month.

You pick up the phone. A technician answers. They know your infrastructure. They can act immediately or escalate to an engineer — included in the standard contract, not in an overpriced Premium plan. For housing clients, physical proximity actions are possible: a technician can go into the server room to cable, reboot, inspect. This is not comparable to AWS support — form, ticket, delay measured in days, Premium plan at tens of thousands of euros per year to get a human on the phone.

Managed AWS / Google Managed Services / Azure Managed Services: they manage your cloud infrastructure for you — but on AWS, GCP or Azure. Dependency on the hyperscaler is maintained, sometimes reinforced. California jurisdiction remains. Egress fees remain. Application lock-in remains. These are not sovereign MSPs — they are subcontractors of the hyperscaler.

Sovereign MSPs (Ecritel, DRI, OVH, Scaleway, Claranet, Infomaniak): they manage your infrastructure on their own datacentre or neutral infrastructure, under French or European law. Their contracts are terminable. Documentation produced belongs to you. Data stays in Europe under European jurisdiction. And their certifications (HDS for health, SecNumCloud for critical infrastructure operators, ISO 27001 for general security) cover regulatory requirements that hyperscalers struggle to fully satisfy.

HDS (Health Data Hosting): mandatory for hosting health data in France. Major French MSPs are HDS-certified. AWS and GCP are too — but under contractual conditions that may conflict with GDPR and the CLOUD Act.

SecNumCloud (ANSSI): the French cloud sovereignty label. Requires that operating companies are subject to French law, with no possibility of extra-European takeover. AWS and GCP cannot obtain it. This is the label that makes the difference for critical infrastructure operators and sensitive public administrations.

ISO 27001: international information security management standard. Most serious MSPs are certified. Minimum condition for public tenders and major accounts.

Three questions to qualify a managed service provider:
1. Do you have documented experience of migrations from AWS/GCP/Azure? (Ask for references.)
2. What is your documentation policy? (Does the TAD and all documentation produced belong to the client from the end of the engagement?)
3. How do you organise knowledge transfer to our internal teams? (If there is no precise answer, this is a warning signal.)