Sovereign AI services in Luxembourg: where SMOX fits
SMOX is a locally hosted AI platform operated by Datacenter Luxembourg. This guide explains what its API offers and how to assess a sovereign AI service.
From 12 January 2027, the EU Data Act bans defined switching charges for a cloud switch. The engineering work, however, remains. Here is how to prepare.
From 12 January 2027, the EU Data Act bans defined switching charges for a cloud switch. The engineering work, however, remains. Here is how to prepare.
The EU Data Act has applied since 12 September 2025. Its cloud-switching rules require providers of covered data-processing services to remove specified contractual, commercial, technical and organizational obstacles to switching. A customer can move to another provider or to its own on-premises infrastructure.(1)
The next milestone is 12 January 2027. From that date, providers may not impose switching charges for the switching process. The legal definition includes data-egress charges. It excludes standard service fees and early-termination penalties.(1)
This distinction matters. The law reduces provider-side lock-in costs. It does not make every cloud exit free, automatic or technically simple.
The standard contractual timeline has three separate phases:
A notice period of no more than two months.
A transition period of no more than 30 calendar days in the normal case.
A data-retrieval period of at least 30 calendar days after the agreed transition period.
If completing the switch within 30 days is technically unfeasible, the provider must notify the customer within 14 working days, explain why and state an alternative transition period of no more than seven months. The customer also has a separate right to extend the transition period once.(1)
The 30-day rule is therefore not a promise that an entire migration project will finish in 30 days. Preparation, target design and testing should happen before the formal switching request.
The Act also refers to functional equivalence. This means a minimum level of functionality and materially comparable results for features shared by both services. It does not require the source provider to rebuild an application on the target platform.(1)
A defensible exit plan should answer five questions.
Inventory applications, databases, object stores, virtual machines, identities, certificates, encryption keys, logs and dependencies. Record which formats and interfaces are available for export. “We can download the data” is not enough if the target cannot use it.
Test restoration in an isolated target environment. Verify user access, key handling, database consistency, monitoring and the most important business transactions. A backup is evidence of a copy. A successful restore is evidence of recover-ability.(4)
Plan with measured end-to-end transfer rate, not the advertised port speed. A simple lower-bound estimate is:
Transfer time in seconds = data volume in bytes × 8 / measured transfer rate in bits per second
For example, 100 TB transferred at a sustained, measured 8 Gb/s takes about 27 hours and 47 minutes. This excludes preparation, validation, delta synchronisation and cutover. Real tests must use representative data, encryption and realistic source and target load.(3)
Define the final write freeze, delta transfer, integrity checks, DNS or routing change, monitoring window and rollback trigger. Lowering a DNS time to live helps, but does not move existing sessions or invalidate records already cached.
Agree measurable acceptance criteria before migration. Examples include zero unexplained record-count differences, successful restore tests, approved recovery time and recovery point objectives, valid certificates, working alerts and completed business-journey tests. Keep the evidence with the exit record.
A durable cloud contract should identify the exportable data and digital assets, available formats and interfaces, known technical restrictions, notice and transition periods, retrieval period, deletion process, possible fees and support responsibilities. The Data Act requires written switching terms and information about methods, formats, restrictions and technical limitations for covered services.(1)
Do not wait for termination to request this information. The cheapest exit is the one designed before the first production workload is deployed.
Do not wait for termination to request this information. The cheapest exit is the one designed before the first production workload is deployed.
Consider a company moving 12 Linux virtual machines, an 8 TB PostgreSQL database and 16 TB of files from a public cloud to a private-cloud cluster in Luxembourg. The total initial dataset is 24 TB.
A transfer test over the intended connection achieves a sustained end-to-end rate of 1.5 Gb/s. Using data volume in bytes × 8 ÷ measured transfer rate, the calculated minimum for the first full copy is about 35 hours and 33 minutes. This is not the outage window: the source application remains live while the initial copy runs. Preparation, validation and cutover must be added.
The migration then proceeds in four controlled steps:
Build the private-cloud network, access controls, virtual machines, monitoring and backup jobs.
Copy the 16 TB file store and restore an initial database backup at the target.
Replicate subsequent database changes and changed files until the target is nearly current.
Freeze writes briefly, transfer the final changes, verify the data and switch DNS or routing to the private environment.
The move is accepted only after the team has matched record counts and file checksums, tested user login and critical transactions, confirmed monitoring and completed a restore from the new backup. If these checks fail, traffic stays on—or returns to—the public-cloud environment according to the agreed rollback plan.
This example is deliberately specific, but not universal. The real duration depends on measured transfer rate, change volume, database design, service dependencies and the time needed for validation
Will a cloud exit be free from 12 January 2027?
Not necessarily. Defined switching charges, including defined data-egress charges for the switch, will be prohibited. Standard service fees, early-termination penalties, destination costs and the customer’s own engineering work are not automatically removed.(1)
Does legal portability guarantee technical portability?
No. Open formats and documented interfaces help, but architecture, managed services, identities, security controls and operational processes may still differ. Interoperability and portability must be tested at every relevant layer.(2)
When should an exit plan be tested?
Before production dependency becomes critical, after material architecture changes and before relying on a contractual migration window. The test should include restoration, data validation, connectivity, observability and rollback.
Legal note: This article provides general technical and regulatory information. It is not legal advice. The application of the EU Data Act depends on the specific service and contract.
[2] ISO/IEC 19941:2017 — Cloud computing: Interoperability and portability
[3] IETF RFC 6349 — Framework for TCP Throughput Testing
[4] NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems