Make EU or US zone: which should you pick, and can you move an account later?

When you create a Make organization, one of the first fields asks for a region. Most people pick whatever is preselected and move on. Months later, a client asks where their data is processed, or a data protection review asks the same question, and the firm discovers that its scenarios have been running in the US all along.

The direct answer: pick the zone that matches where your clients expect their data to be handled. For most European firms that is the EU zone; for most North American firms it is the US zone. Choose carefully, because Make says the location cannot be changed after the organization is created. If you picked the wrong one, the way out is a new organization in the right zone and a planned migration of your scenarios, connections and webhooks. And even in the EU zone, some AI features are processed in the US, so the zone is not the whole answer.

What a Make zone actually is

Make's organizations help page explains that each organization lets you select the geographical location of the data center where the organization's data will be stored and processed. It is a property of the organization, not of your account, your company address or where your team sits.

You can see which zone you are in from the address bar. Make's API documentation lists zone addresses such as eu1.make.com, eu2.make.com, us1.make.com and us2.make.com. If your dashboard opens on an address starting with eu, your organization lives in a European zone; us means the United States. That page also notes that the zone is tied to the infrastructure region and to your plan, which is why some organizations sit on eu2 or us2 rather than the first zone.

What runs in the zone: your scenarios, their execution logs and the data passing through them, data stores, webhooks and connections. Anything your scenarios send to another app is then handled wherever that app hosts its data, which is a separate question.

How to choose

For a 10 to 50 person firm, three questions settle it.

1. Where are your clients, and what have you told them? If your engagement letters, privacy notice or client contracts say client data stays in the EU, or if your clients are EU or Swiss firms that will ask, the EU zone is the simpler story. If your clients are mostly in the US or Canada, the US zone is the natural fit.
2. Where are the apps you connect? If your CRM, practice management system and accounting software already host your data in one region, keeping Make in the same region avoids one more transfer to explain. Make also recommends picking the region nearest you for lower latency, but at the volumes a small firm runs, latency is rarely the deciding factor.
3. What does your data protection review require? A US zone is not automatically a problem for a European firm; transfers can be covered by contract terms. But it adds a step to your records and your conversations with clients. Check with your lawyer or compliance lead which position your firm needs to take.

If you serve both sides of the Atlantic, you can run two organizations, one per zone, and keep each client group's scenarios in the matching one. That doubles the subscriptions and the maintenance, so do it only when a real client requirement drives it.

What still leaves the EU zone

Choosing EU is not a guarantee that every request stays in Europe. Make's page on AI providers and data zones states plainly that selecting the EU1 or EU2 zone does not automatically mean every request is processed in the EU. As listed in October 2026:

• Some Make features route to the US regardless of zone, including Maia, Make AI Web Search and the OpenAI models in Make's own AI provider.
• Model choice matters. The same page lists which Claude models are served from EU regions and which are processed elsewhere, so check the table before you pick a model for a scenario that handles client data.
• Your own AI connections follow the provider. If you connect your own OpenAI, Anthropic or Google Gemini account, the request goes to that provider's default endpoint, and Make does not guarantee EU processing.

The same logic applies outside AI. A scenario in the EU zone that copies client records into a US-hosted CRM has still moved that data to the US. The zone governs Make's part of the journey only. Our article on whether it is safe to put client data through Zapier covers the wider questions to ask any automation platform, and they apply equally to Make.

Can you move an organization to another zone?

Not in place. Make's organizations page says you cannot change the location of the data center after you create the organization. In a Make Community thread on exactly this question, a community member replied that a region cannot be changed except when upgrading an organization to an Enterprise plan. That is a forum answer, not documentation, so if Enterprise is on the table, confirm it with Make's sales team.

For everyone else, the route is a new organization. The same help page says any user can create an organization, even while belonging to another one, and the region is chosen in the creation dialog.

How to migrate scenarios to a new zone

Treat it as a small project, not an afternoon of copying.

1. Take an inventory first

List every active scenario, the connections each one uses, every webhook and the form or app that posts to it, and any data stores. Note which scenarios are business critical (intake, billing, reminders) and which can wait. This is also the moment to switch off scenarios nobody uses rather than migrating them.

2. Move the scenarios as blueprints

Make's blueprints help page describes exporting a scenario as a JSON file and importing it into a new scenario. A blueprint carries the modules, their settings and the mapped values. It does not carry your logins: the page says users still need to create connections for their accounts after importing. Each blueprint must be under 2 MB.

3. Recreate connections, webhooks and stored data

• Connections: authorize each app again in the new organization, ideally with a firm-owned account rather than one person's login. Our article on what happens to automations when an employee leaves explains why that matters.
• Webhooks: new webhooks in the new organization have new addresses. Every website form, app or service that posts to the old address must be updated, or it will keep sending data to the old zone.
• Data stores: plan how to copy their contents across, and check that nothing in the old organization still writes to them.
• Firewalls and allowlists: if any of your systems only accept traffic from known addresses, Make's page on allowing connections from Make IP addresses lists different addresses per zone, so update the allowlist.

4. Cut over in order

Run the new scenarios in parallel with test data, then switch each source (form, webhook, trigger) to the new organization one process at a time. Turn off the old scenario as soon as its replacement is live, so the same client record is not processed twice. Our guide to syncing data between apps without duplicates covers the safeguards that make a cutover like this safe.

5. Close the old organization deliberately

Once every scenario has run cleanly in the new zone for a full cycle (a month end, a billing run), export anything you need for your records, then remove the old organization and its subscription. Check your own record retention rules with your compliance lead before you delete execution history.

How Flow Mesh helps

Every engagement starts with a first call, then a stack audit scoped in writing before it starts. It gives a verdict on every tool, including where your automation platform runs and what it sends where, and a written scope for any migration worth doing. Builds are quoted in writing after the audit and carried out inside your own accounts.

Key takeaways

• A Make organization's zone is fixed when it is created; Make says the data center location cannot be changed afterward.
• Choose the zone that matches what you have told clients about where their data is handled, then check with your compliance lead.
• The EU zone does not keep everything in Europe: some AI features and your own AI provider connections may process data in the US.
• Moving zones means a new organization: export blueprints, then recreate connections, webhooks, data stores and allowlists.
• Cut over one process at a time and switch off each old scenario as soon as its replacement is live.