Can You Keep Snowflake and Move Your Data to a European Cloud?

Imagine a manufacturing company whose finance team relies on Snowflake, a cloud platform for analysing business data. Its board wants more control over where that data lives, but the people producing daily reports want to keep the tools they know. The useful question is how much control the company could gain while preserving that working routine.

The partnership announced by Snowflake and STACKIT on 17 September makes that question timely. The companies describe a staged integration involving European storage, encryption keys and open data formats, with deeper hosting integration ahead. Schwarz Digits' announcement provides a direction to investigate; it does not establish that an entire existing Snowflake environment can move to STACKIT today.

For buyers assessing the proposal as of 29 September 2026, we would separate three decisions: where the data is stored, where calculations happen, and what the business could still do if a supplier became unavailable. This article explains the distinction and how to turn it into a manageable evaluation.

What the partners have announced

STACKIT is the cloud platform of Schwarz Digits, the IT and digital division of Schwarz Group. Its announcement describes an initial phase in which customer data would reside on STACKIT in Apache Iceberg, an open table format, with encryption integrated into STACKIT's key management system. Running Snowflake's platform directly on STACKIT appears as an ambition for subsequent phases. Source: Schwarz Digits.

Snowflake's own account describes the collaboration as an ongoing roadmap. It also explicitly qualifies statements about planned integrations, availability and timing: these are subject to development and other conditions, rather than commitments to deliver particular features or dates. Neither announcement gives us a sufficient basis to promise a production migration on a customer's preferred schedule.

Our reading is that the collaboration creates a potential route for companies that want to retain Snowflake while changing aspects of their infrastructure. That is worth evaluating, particularly when replacing a reporting platform would broaden an already demanding project. The buying decision should nevertheless attach to a named service, a supported configuration and a written availability statement.

Ask the partners to identify the phase they can demonstrate for your company now. Record separately what is generally available, what requires participation in a trial, and what remains planned. Give each unresolved dependency an owner and a date for review before including it in a migration plan.

Follow the data through a complete report

Storage is where information rests between uses. Processing is the work of reading that information, combining it and calculating results. Snowflake's supported cloud platforms documentation currently lists AWS, Microsoft Azure and Google Cloud as its hosting platforms; it does not list STACKIT as a standard deployment destination.

There is already a technical basis for separating Snowflake from the storage it reads. Snowflake documents connections to S3-compatible external storage, meaning storage that uses a commonly supported interface originally associated with Amazon S3. That documentation establishes a general capability, not the availability or full behaviour of the announced STACKIT integration.

For our illustrative manufacturer, we would trace one report from the source system to the screen used by finance. Ask where the original records, table files, calculations, temporary results and exported spreadsheet reside. Include the systems used for login, administration and support in that discussion, and request an explanation of any copies created along the way.

This gives the board a more useful description than simply saying that its data is in Europe. A proposed design might meet a requirement to hold particular files on European infrastructure while leaving other requirements unresolved. Write the actual requirement first, then ask the suppliers to show how every relevant part of the design meets it.

For example, if the requirement is that specified data must remain on infrastructure operated by an EU-owned company during both storage and processing, ask for evidence covering both. Do not treat a storage location as evidence about the place where a report runs. Have the people responsible for the original requirement accept the documented design before proceeding.

Open tables provide a foundation for choice

Apache Iceberg defines an open way to organise analytical data into tables that different processing tools can use. Its supported ecosystem includes tools such as Spark and Trino. In plain language, a shared table format can give more than one application a way to understand the same stored information.

The surrounding arrangements still matter. Snowflake's Iceberg documentation explains the role of a catalog: a service that connects a table's name to the information describing its current contents. Snowflake can manage that catalog, or connect to an external one. We would therefore check access to both the files and the catalog when assessing an alternative way to read the data.

There are also configuration-specific limits. The documentation for external processing tools using Snowflake Horizon Catalog currently excludes S3-compatible non-AWS storage from that feature's supported commercial-cloud storage options. This is a limitation of that particular access route; it is not evidence that every possible STACKIT arrangement is unsupported.

Our practical recommendation is to ask the partners to demonstrate the exact alternative route they propose. Which tool reads the tables, which catalog does it consult, and which organisation supplies the login and permissions? If continued access is a project objective, include a controlled test in which the proposed alternative does not depend on the Snowflake services assumed unavailable.

For the manufacturer, a sensible test would be reproducing its daily order summary with the agreed alternative tool. Compare totals, permitted users and the freshness of the records. Treat any extra work needed to recreate calculations or reports as part of the project scope, rather than declaring success when a file can merely be opened.

Ask what control of encryption keys means

Snowflake says the planned integration would hold encryption-key ownership and control within STACKIT's EU infrastructure. Its announcement presents this as part of the intended approach to data control. Buyers should request implementation details for their proposed configuration before relying on that description. Source: Snowflake.

We would ask who can authorise use of the keys, who can change those permissions, and what evidence records each action. Request a demonstration of what happens when permission is withdrawn, including the effect on work already running. Ask separately how the design handles temporary copies and results that have already been produced.

Also agree who restores service if a key becomes unavailable or an administrator makes a mistake. Put those responsibilities alongside the access controls so the business can assess protection and continuity together. The outcome should be a short explanation that the head of IT and the person responsible for data protection can both approve.

For contractual or regulatory requirements, we would have the responsible legal or compliance adviser assess the proposed service and its terms. A product announcement is useful background for that review; the evidence should describe the arrangement the company will actually use.

Start with one reporting workload

We would begin with a bounded pilot: one reporting workload, meaning one complete flow from incoming records to a useful business result. For the manufacturer, that could be the daily order summary already chosen for the access test. Use synthetic or appropriately approved data and keep the existing production report available throughout the evaluation.

Before the pilot, agree the result it must deliver. Specify how recent the data must be, when the report must finish, which users may read it and how discrepancies will be investigated. Assign a business owner to confirm that the result is usable, alongside the technical owner checking the infrastructure.

Ask the suppliers to demonstrate the required actions on the proposed storage arrangement, including updates, access changes and any sharing that the report needs. Snowflake documents differences between Iceberg storage choices, including customer responsibility for protection and recovery when using customer-managed external storage. Those responsibilities deserve explicit attention when designing the pilot. Source: Snowflake's Iceberg documentation.

Then introduce a controlled interruption in the test environment. Check who notices, who receives the support request and who has authority to fix the problem. Practise the agreed return to the existing reporting process, including how to account for records added while the test was running.

Finally, ask an internal colleague who did not build the pilot to follow its operating instructions. Record any help they need, any supplier access they require and any manual steps that would recur. For a small IT team, we would make this handover part of acceptance: the proposed arrangement must be something the team can understand and operate.

Make a decision the business can explain

At the end of the evaluation, we would produce a brief decision record linking each requirement to evidence. It should name the configuration tested, the responsibilities accepted and the dependencies that remain. Planned capabilities belong in a separate section with a clear explanation of whether the decision relies on them.

A company seeking a different home for selected analytical data may find enough benefit to proceed with a limited scope. A company whose requirement covers the entire processing environment may need a different design or further evidence. Those are valid outcomes of the same evaluation, provided the requirement was explicit from the start.

Keeping Snowflake while changing where selected data lives is a credible direction to investigate. Our recommendation is to choose one important business result and require the proposed arrangement to demonstrate it, including access, recovery and day-to-day ownership. That gives the board a decision it can explain and the IT team a scope it can deliver.

Thinking about migration? Book a free consultation to discuss your situation.