Why ecommerce for EU data sovereignty needs a different build
Moving a store that holds EU customer and order data off a US-hosted SaaS platform is about who can access that data, not only where it is stored. A retailer whose orders sit in an EU data center can still be exposed if a US provider controls the system, its administrators or its support tooling. That exposure drives the platform choice: the question is which product lets you run the storefront, database, backups and support access entirely under your own control, inside EU infrastructure you select and operate. Start by mapping every place personal data is read, copied or displayed, including the ERP, the email tool, the payment provider and vendor support sessions. The access question is sharper than many store owners expect. The EDPB Guidelines 05/2021 (version 2.0) treat remote access from a third country, even only displaying data on a screen for support or administration, as a transfer, and storage in a cloud outside the EEA as one too. The US CLOUD Act provision at 18 U.S.C. 2713 requires US providers to preserve or disclose data in their possession, custody or control wherever it is located. Hosting in Frankfurt on an American-controlled SaaS therefore does not remove the exposure. Confirm with counsel which vendor entities hold control, where support staff sit, and whether a Data Privacy Framework certification applies to each recipient, bearing in mind that the appeal in Case C-703/25 P is pending. For the short answer on platforms: self-hosted open-source commerce gives you the control that EU sovereignty requires, and the candidates differ mainly in operating burden. Magento Open Source (OSL-3.0) and WooCommerce (GPL version 2 or later) can run entirely in your own EU accounts, with WooCommerce often the smaller operational footprint and Magento the larger catalog and extension ecosystem. Saleor (BSD-3-Clause) and Medusa (MIT, with Enterprise Edition materials excluded) suit headless builds where you own the API and storefront. Confirm each project's current license terms and support windows before selecting one, because the platform decision must also satisfy the data portability rights in the Data Act.
Which GDPR transfer, access and accessibility duties shape the store
This table maps each duty to its source and to what it changes for hosting, support access, vendor contracts and the storefront build. Read each row as a question to answer before you pick a hosting region, a support model or a payment design. The main takeaway is that remote administrative access from outside the EEA can count as a transfer, so support access belongs in the scope from the start.
| Duty and source | What it means for the store | Evidence to prepare |
|---|---|---|
| GDPR Article 44 and Chapter V: transfers to third countries, including onward transfers | Every transfer of customer or order data outside the EEA needs a valid transfer basis, and onward transfers by your vendors count too. Map each sub-processor and its location. | Transfer map of data flows, transfer basis per recipient, and sub-processor list |
| EDPB Guidelines 05/2021: remote access and cloud storage outside the EEA are transfers | Support staff in a third country viewing order data on screen is a transfer, as is storing backups in a non-EEA cloud region. Restrict admin access and backups to EEA locations or document the basis. | Access logs, support access procedure, and backup region records |
| Article 48 and third-country orders: foreign court or authority demands | A non-EU court order to disclose data is recognized in the EU only under an international agreement such as a mutual legal assistance treaty. Assess whether your hosting or vendor could receive such orders at all. | Written assessment of vendor exposure to foreign legal demands and contractual notice commitments |
| US CLOUD Act (18 U.S.C. 2713): providers must disclose data they control | A US-headquartered provider may be obliged to disclose data it holds, wherever that data is located. EU hosting by a US parent company does not remove this exposure on its own. | Vendor ownership and jurisdiction review, and encryption key custody decisions |
| EU Data Act Article 32: safeguards against third-country governmental access to non-personal data | Cloud and data processing providers must take measures against conflicting third-country access to non-personal data held in the EU. Ask hosting and SaaS vendors how they meet this in their contracts. | Vendor attestations on Article 32 measures and contract clauses on government access |
| Data Act switching rights (Articles 25, 29 and 50) | Customers may switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition. Switching charges are banned from 12 January 2027, so exit terms in SaaS contracts should be checked now. | Export plan for catalog, orders and customers, and contract exit clauses |
| European Accessibility Act: storefront and checkout | Storefront themes, product pages and checkout must be usable by people with disabilities. Build the theme and checkout against WCAG-based criteria and test with assistive technology before launch. | Accessibility conformance report prepared against WCAG, test results and remediation backlog |
Which customer, order and payment data leaves the EEA by accident
The most common transfer problem in a store move is not the main database. It is the set of systems around it that hold a copy of customer data and were never listed in the migration plan. Before you choose a host, list every place that stores or displays customer and order data: customer accounts, orders, billing and shipping addresses, payment tokens and the processor references behind them, marketing consent records, application and web server logs, search indexes built from customer or order fields, session cookies, support tickets with attached order details, and the connectors that push orders to an ERP or email tool. Each row needs an owner, a location, and a named processor or sub-processor behind it.
Three flows deserve particular attention because they move data without anyone deciding to. First, remote support: under EDPB Guidelines 05/2021, a vendor engineer in a third country who only views personal data on screen during support or administration counts as a transfer, so a support contract with an offshore team needs the same Chapter V analysis as a data copy. Second, backups: an EEA host that replicates snapshots to a region outside the EEA, or a provider whose backup service is run by a non-EEA group, moves data as surely as a primary database. Third, the CDN, analytics and tag manager scripts on the storefront, which send visitor and sometimes order-confirmation data to servers you did not select. Ask each provider in writing where data is stored, where support staff can view it, and where backups and logs are replicated.
Map these flows before you choose a host, not after. Mark each flow as EEA only, EEA with a third-country access path, or outside the EEA, and treat the third category as a decision item for legal and security review. Your data protection officer should also check whether the processor is subject to third-country legal orders with extraterritorial reach. The EDPB notes that a request from a third-country authority to a processor can itself be a transfer, so the assessment covers the provider's legal exposure as well as its server locations. The output of this mapping is the input for your processor contracts, your records of processing and the storefront configuration review that follows.
Which open-source platforms fit EU-controlled hosting
Every platform below can be self-hosted in an EU region, so the licence is rarely the constraint. What separates them is how much hosting, payment and extension work sits with you, and how each one's extensions and update channel could pull data or code outside your control. A platform licence never settles where customer data is processed; that remains a hosting and processor decision.
Magento Open Source
OSL-3.0 licensed and the most common self-hosted option for larger catalogs. Version 2.4.9 is in standard support until May 31, 2029, and each 2.4.x release gets three years of standard support from general availability. The operational load is high: PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, nginx and Varnish all run in your EU environment. Check every third-party extension for outbound calls, such as license checks, analytics or remote assets, because these can move personal data to third countries without your team noticing. Adobe's cloud-hosted Commerce uses Fastly rather than Varnish, so an EU self-managed install is a different operating model.
WooCommerce
GPL version 2 or later, running on WordPress, with WooCommerce 11.2.1 as the current release. It fits smaller EU catalogs and teams that already run WordPress hosting in an EU region. The sovereignty risk sits in the plugin layer: payment, shipping, tax and marketing plugins are often distributed by third parties and may call external services at checkout. Your hosting provider becomes a processor for order and account data, so its contract, backup locations and support access matter as much as the software. Confirm which plugins send data to external services and where those services process it.
Saleor
BSD-3-Clause licensed headless commerce API, with 3.23.42 as the published release. Saleor suits EU merchants who want their own storefront and keep the commerce core in a controlled EU environment, since the API, database and admin all run in one place you choose. Operational load is higher than a hosted SaaS because you own the Python services, database, search and storefront deployment. Sovereignty risk comes mainly from the storefront framework, CDN and payment integrations you add around the API, so map every external call the storefront makes, not just the core service.
Medusa
MIT licensed except materials covered by its Enterprise Edition license, with v2.21.2 published on September 28, 2026. Medusa is a Node.js commerce engine that fits EU teams already running a TypeScript stack and deploying to their own EU cloud accounts. Confirm early whether any module your scope needs sits under the Enterprise Edition license, because that changes both the license terms and the upgrade path. Plugins and marketplace integrations are the main sovereignty exposure, so review what each one stores, logs and transmits before it reaches production.
Sylius
MIT licensed PHP commerce framework, with v2.3.1 published on October 14, 2026. Sylius is a framework rather than a finished shop, so an EU team builds the store, checkout and admin in its own codebase, which keeps the full data flow under its control. The cost is engineering effort and long-term maintenance of custom code. Sovereignty risk shifts to your own dependencies: confirm that Composer packages and any bundles you pull in do not phone home, and keep the build pipeline inside your EU environment.
PrestaShop
OSL-3.0 core with AFL-3.0 modules, and PrestaShop 9.2.0 published on September 30, 2026. It is a common choice for European merchants and fits EU hosting well because the core is established in that market. The sovereignty question is the module marketplace: modules are licensed separately and many connect to outside services for payments, translations or analytics. Read the licence and data flows of each module, and confirm whether updates are downloaded from a vendor endpoint outside your change control before you allow automatic updates.
How payment provider choice changes PCI scope when you host the storefront
The shopper leaves your storefront and enters card details on the processor's own payment page, then returns to your store with a result. Card data never passes through your servers, which keeps the storefront furthest from cardholder data handling. Scope narrows to the redirect, the order flow and the systems that build and return the shopper from the payment step.
- Hosting impact: Your servers still serve the cart, checkout steps and redirect, so they stay in scope for payment initiation and integrity.
- Script exposure: Fewer payment scripts run on your pages, so script inventory and change detection focus on the checkout pages you still serve.
- Processor location: Your store can run in an EU data center, but the hosted page sits under the processor's control, so its location and sub-processors must be confirmed.
- Return and webhook handling: Validate return URLs and payment notifications so a forged result cannot mark an order as paid.
Ask your processor which SAQ type it assigns to this design, and get the hosted page location and sub-processor list in writing.
The card fields are rendered in an iframe served by the processor, and your page wraps the frame. The card number is typed into the processor's frame, but your page still controls the surrounding scripts, the layout and the call that starts the payment. Scope therefore depends on whether your own page can alter the frame or read what is entered into it.
- Page scripts: Every script on the checkout page can affect the embedding page, so script inventory and authorization stay in scope.
- Content Security Policy: Magento Open Source and Adobe Commerce support CSP headers from 2.3.5, so restrict frame and script sources to the processor's domains.
- Restrict mode: From 2.4.7, CSP runs in restrict mode by default on storefront and admin payment pages, so review any custom policy before you upgrade.
- Caching layer: On self-managed installations, Varnish is the full-page cache accelerator, and its rules must not cache or alter checkout pages that load payment elements.
Ask your processor whether the card fields are isolated from your page's JavaScript, and check that answer against the PCI DSS SAQ eligibility guidance on this site.
Your storefront collects the card number, expiry date and security code in fields you build, then sends them to the processor or gateway. This places cardholder data inside your application and your hosting, so the widest set of controls applies. Stores often choose this design for customization, but it is the hardest design to defend under a self-hosted model.
- Full scope: Servers, networks, logs and admin access that touch card data fall into the cardholder data environment and a more demanding assessment.
- Script control: Any script on the page could read card fields, so controls for the payment page scripts under PCI DSS 6.4.3 and change detection under 11.6.1 become continuous work.
- Logging and CDN: Application logs, error reporting and CDN layers must never capture card data, which requires explicit configuration in your EU hosting.
- Extension burden: Every extension that touches checkout expands what you must patch, test and document.
Before you choose this design, ask a qualified assessor to describe the scope in writing, and confirm the processor's data location and contract terms.
Magento Open Source supports Content Security Policy headers from 2.3.5, and from 2.4.7 CSP runs in restrict mode by default on storefront and admin payment pages. The policy limits which scripts and frames a browser will run on checkout, so it is a central control for iframe designs and for redirect designs that still load scripts. A policy is only as reliable as its configuration, and upgrades can change defaults.
- Version baseline: Adobe lists 2.4.9 with regular support ending May 31, 2029, and it ships a full patch for the 2.4.x LTS line annually in May.
- Custom policies: Test every third-party extension that adds scripts or frames, because restrict mode can block them on payment pages.
- Sandbox testing: Verify policy behavior on staging with each processor's sandbox before go-live.
- Proxy and cache: Confirm that the reverse proxy and cache pass CSP headers through unchanged.
Confirm with your developer which policy mode is active on your version, and check that the processor's required domains appear in the policy.
Whatever checkout design you choose, the payment processor receives cardholder data and often customer data, so its location, sub-processors and contract terms belong in your EU data sovereignty plan. A processor based outside the EU may still be subject to third-country access rules, which affects the transfer analysis under Chapter V of the GDPR. Under Article 44, infringements of the transfer rules carry fines of up to EUR 20 million or 4% of worldwide annual turnover, so the answers need to be documented.
- Data location: Ask where card, billing and fraud-screening data is stored and processed, including backups and support access from outside the EEA.
- Transfer basis: Confirm the transfer mechanism, such as standard contractual clauses, and whether remote access from a third country counts as a transfer under EDPB guidance.
- Government requests: Ask how the processor responds to third-country authority requests, since complying with one can itself be a transfer.
- Sub-processors and exit: Get the current sub-processor list, change-notice terms and token or data export options in writing.
Store these answers in your processor contract file and review them whenever the processor changes its data flows.
How the move off US-hosted SaaS is phased
The sequence turns a US-hosted commerce SaaS into an EU-controlled store in stages, with each stage producing a decision or evidence item that the next one depends on. Nothing goes live until the data map, transfer assessment and rollback plan are signed off.
Map data flows and assess transfers
Your privacy lead, the store owner and the current SaaS vendor's documentation identify every place customer, order, payment and support data goes today, including ERP, email, analytics, search, fraud tools and support desks. Each flow is tagged as stored, processed or accessed from a third country, including remote support sessions, which EDPB Guidelines 05/2021 treat as transfers. The output is a signed data map and a transfer assessment that names the Chapter V mechanism or the decision to avoid the transfer, plus a list of processors whose third-country law exposure must be reviewed before you engage them.
Decide platform and hosting location
Choose the open-source platform (Magento Open Source, WooCommerce, Saleor, Medusa or Sylius, depending on catalog, B2B and integration needs) and the EU hosting model, whether your own cloud account in an EU region, an EU data center or a partner-run environment under your contract. Confirm with each hosting provider where backups, logs, monitoring and support access sit, since storage outside the EEA is itself a transfer. The output is a written platform and hosting decision record, with the versions and support windows checked against the vendor's published lifecycle, and a list of supplier contracts still to be signed.
Build the EU environment with CSP and payment design
DeployOpen's engineers provision the environment inside your EU accounts, apply the supported software stack for the chosen release, and set up Content Security Policy headers, script control on the payment pages and separation of admin access. The payment provider and checkout design are fixed here, because they decide the PCI DSS scope of the hosted storefront. The output is a staging environment with documented configuration, a payment flow diagram agreed with your acquirer or PSP, and a list of third-party scripts approved for each page.
Remediate theme and checkout accessibility
Testers audit the storefront theme, product pages, cart and checkout against WCAG-based criteria, then the development team fixes defects in the theme and extensions before migration, not after. Where a legacy SaaS theme cannot be remediated, the team documents the gap and the replacement plan. The output is an accessibility audit report, a remediation log with each defect closed or accepted, and a retest result on the checkout path, which supports your position under the European Accessibility Act.
Migrate catalog and customers with rollback
Catalog, customer accounts, order history, tax settings, redirects and product media are extracted from the SaaS, transformed and loaded into the EU environment in repeated trial runs. Each run is reconciled by counts and sample checks, and passwords and payment tokens are migrated only where the vendor export and the new platform's security model allow it, otherwise customers reset credentials. A rollback plan is written and rehearsed, covering DNS, the SaaS account, and the order data captured during the window. The output is a reconciliation report from the final trial run and a rollback runbook approved by the business owner.
Cut over and deliver the evidence pack
The team switches DNS and payment callbacks to the EU environment during an agreed window, watches orders, payments and error logs, and confirms that the SaaS no longer receives new personal data. The SaaS account is then closed or restricted according to the contract and the Data Act switching rights where they apply. Within the cutover, the team assembles an evidence pack: the data map, transfer assessment, processor contracts, configuration baselines, payment flow, accessibility report, reconciliation results and decommissioning record. The output is the signed go-live record and this pack, which you hand to your auditors or assessors, who make their own determination.
What a regulator or auditor asks for after the move
This table lists the records a privacy regulator, auditor or customer assessor typically asks for once a store runs on EU-controlled hosting, and which component produces each one. Read it as a checklist to prepare before the move, since several items (transfer assessments, processor locations, switching documentation) are hard to reconstruct later. DeployOpen prepares evidence and controls for assessment but does not issue audit reports or certifications.
| Evidence | What it shows | Produced by |
|---|---|---|
| Transfer impact assessments | Whether any remote access from outside the EEA, backup copies or support tooling count as transfers, and the supplementary measures applied | Assessor, with input from the controller's legal team and DeployOpen's infrastructure records |
| Records of processing and data flows | Which systems hold customer and order data (storefront, ERP, email, analytics) and where each one runs | Controller's register, maintained against infrastructure inventory |
| Processor and sub-processor contracts | Who processes data, the hosting location of each, and whether third-country sub-processors are involved | Contracts held by the controller, checked against the hosting provider and payment provider records |
| Access logs for support sessions | Who reached production data, from which location, when, and under which approval | Magento admin logs, bastion or VPN logs, and the ticketing system that approved each session |
| Encryption and key custody evidence | Where encryption keys are generated and stored, who can use them, and rotation history | Infrastructure tooling (key management service or HSM logs) and the operator's key procedure |
| Data retention settings | How long orders, accounts and logs are kept, and how erasure requests are executed across the shop | Magento configuration and cron jobs, plus log retention settings in the logging stack |
| Data Act switching documentation | How the store could export data and move to another provider or on-premises infrastructure, including notice and transition steps | Runbook maintained by the operator, with export tests recorded in the ticketing system |
| Accessibility conformance records | Test results against the accessibility standard used for the storefront and checkout, with remediation tickets | Test reports from the accessibility tester, remediation tickets, and the assessor's review |
| Payment page script inventory | Which scripts load on checkout and payment pages, who owns each one, and when changes were approved | Storefront build pipeline, Content Security Policy reports, and change records in the ticketing system |
What buyers ask before moving a store to EU-controlled hosting
Does hosting our store in the EU make us GDPR compliant?
No. EU hosting addresses where data sits, not every obligation that applies to it. GDPR still requires a lawful basis for order and marketing data, retention rules, access and erasure handling across the shop, ERP and email tools, cookie consent on the storefront, and processor contracts with the hosting company and each payment provider. Hosting location matters most for transfers: under Article 44, every transfer to a third country, including onward transfers, must meet Chapter V conditions. The EDPB's Guidelines 05/2021 also treat remote access from a third country, even only displaying data on a screen for support, as a transfer. Ask your counsel and DeployOpen to map each data flow, including support access by vendors outside the EEA, before you treat the move as complete.
How does Data Privacy Framework status affect a US commerce vendor?
It decides whether a transfer to that vendor can rely on the adequacy finding in Commission Implementing Decision (EU) 2023/1795. That finding applies only to US organizations on the Data Privacy Framework List, and an appeal against the General Court's September 2025 judgment upholding it is pending as Case C-703/25 P. Standard contractual clauses remain an alternative route, as the Court of Justice confirmed in Case C-311/18, but they need a transfer assessment and supplementary measures. Where a provider must access data in the clear and foreign public authority powers go beyond what is necessary and proportionate, the EDPB says it cannot envision an effective technical supplementary measure. Also check the US CLOUD Act (18 U.S.C. 2713), which reaches data a provider controls wherever it is stored. Request the vendor's DPF listing status, its transfer impact documentation and its government access policy in writing.
What drives the cost of moving a store off Shopify?
The cost depends on scope, not on a single license fee, because most open-source platforms carry no license charge. Cost components include discovery and data mapping, catalog, customer and order migration, theme and extension work, EU hosting and managed infrastructure, payment integration, PCI DSS work for the checkout design, testing, cutover, and then recurring hosting, security patching, upgrades and monitoring. Costs rise with the number of storefronts, languages and currencies, the volume of historic orders you must keep, custom integrations with ERP or payment tools, and how many data processing agreements must be negotiated. Ask each bidder for a fixed-scope quote that separates one-time build work from recurring run costs, names who is paid for each item (DeployOpen, your hosting provider, extension vendors or your own staff), and states what is excluded.
How long does an EU store migration take, and what does it need from our team?
Duration depends on catalog size, integration count, the number of markets and how much historic data you keep, so no fixed timeline applies across stores. Your team typically needs to name a business owner who signs off on scope, provide access to the current store, ERP and payment accounts, supply a data inventory and retention policy, and decide on cutover windows and redirect rules. Plan for parallel running and a staged cutover so orders are not lost during the switch. Ask the implementation partner for a written schedule with milestones, the client responsibilities at each stage and the change freeze the cutover requires.
Can our in-house team move the store without an implementation partner?
Yes, if your team already runs production e-commerce and has the skills to operate it. Self-hosting shifts responsibility for hosting, patching, backups, PCI DSS scope, cookie consent and vendor contracts to you. Most teams underestimate the recurring work: keeping extensions upgradable, applying security patches on schedule, maintaining the search, cache and queue stack, and producing evidence for an assessment. A partner can plan, implement, harden, document and support the platform inside your own cloud account or data center, under a written scope. Compare an internal plan against a partner quote using the same list of deliverables, and confirm who owns the runbooks, credentials and the migration data at handover.
How do Magento Open Source support dates shape the decision?
They set how long a chosen release line receives vendor fixes, so they should drive the version you deploy and the upgrade plan you sign. Adobe gives each 2.4.x release three years of standard support from general availability. Regular support for 2.4.6 ended on August 11, 2026, 2.4.7 ends on May 31, 2027, 2.4.8 on May 31, 2028 and 2.4.9 on May 31, 2029. Adobe also ships a full patch for the 2.4.x LTS line annually in May. Deploying a line near its end date means an earlier forced upgrade. Confirm the system requirements for your target release too: 2.4.9 lists PHP 8.5, MySQL 8.4 or MariaDB, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3 and nginx 1.30, and Adobe supports only the listed combinations. Ask for an upgrade estimate in the quote.
Does moving to a self-hosted store change our PCI DSS obligations?
Yes. Self-hosting does not remove payment card obligations, and it can increase them when you host the storefront and checkout pages yourself. The validation you need depends on the payment page design: redirect or iframe pages keep fewer systems in scope than direct post or self-built card forms. Scripts on payment pages also need management under PCI DSS requirements for payment page scripts and change detection. Ask for the expected self-assessment questionnaire type in writing, a list of every script on checkout pages, and a description of who manages the hosting environment and its patching.
What to ask an implementation partner about EU sovereignty
Ask the partner to state, in the written scope, where every support engineer connects from and whether any of them sits outside the EEA. The EDPB guidelines treat remote access from a third country as a transfer even when the person only views data on a screen, so a support session from a non-EEA location can bring your store into Chapter V scope. Ask how remote access is requested, approved, time-limited and logged, who approves it on your side, and whether session recordings are kept and where. Ask for a sample access log from a recent maintenance window so you can see the fields actually captured, not just the policy describing them. Ask for the full sub-processor list with the processing location and the legal entity behind each one, covering hosting, backups, CDN, email, search, monitoring, error tracking and payment connectors. Ask which of these hold customer or order data in the clear, and whether any provider is subject to third-country law that could require disclosure, since the EDPB's Example 12 says complying with such a request would itself be a transfer. Ask for the processor contracts and the dates each sub-processor was last reviewed. Confirm that the partner will notify you before adding or replacing one.
Ask who maintains the payment configuration and the inventory of scripts on the checkout pages, and how that inventory is reviewed after each release, extension update and tag manager change. Payment provider choice affects both where cardholder data flows and which self-assessment questionnaire applies, so ask the partner to map the checkout design to that decision in writing before build. For accessibility, ask which WCAG success criteria the storefront and checkout are tested against, which tools and manual checks are used, whether testing uses assistive technology, and who signs off fixes. Ask whether retesting happens after each theme and extension change, and whether results are delivered as defect reports you can keep as evidence. Finally, ask the partner to document the exit path before go-live. Under the Data Act, customers have a right to switch to another provider or to on-premises infrastructure, with a maximum two-month notice period and a 30-day transition, and switching charges are banned from 12 January 2027 (Articles 25, 29 and 50 of Regulation (EU) 2023/2854). Ask for a written runbook that lists the database, media, order exports, configuration, infrastructure-as-code and DNS steps needed to move the store, and ask for a rehearsal date that you can attend. Confirm how the partner will handle any fee or effort associated with exit, and get that answer in the quote.
