This guide is about making the decision. If you already know which region you want and need the mechanics — the exact options, what the setting does and does not change, and what moving involves — the companion guide covers that ground.
Where is our data is really three questions
When somebody asks where your live chat data lives, they are usually asking three different things at once, and the answers are not the same. The first is physical: which data center holds the conversation records. The second is legal: whose jurisdiction those records sit in, and what that means for transfers. The third is practical: who can reach the data, from where, and with what logging.
Only the first of those is a setting. The other two are answered by your contract, your retention policy and your own access controls, and no dropdown will answer them for you. Teams that treat region selection as the whole privacy story end up with a confident answer to a question nobody asked and a gap where the real one was. Separate the three before you start, because the work each one needs is different.
Latency and jurisdiction usually point the same way
The happy part of this decision is that the two main drivers rarely conflict. Chat is a chatty protocol in the literal sense: a conversation is many small round trips, not one large transfer, so round-trip time is felt more sharply than raw bandwidth. Every message an agent sends and every keystroke indicator travels the distance between your visitor and the server twice. Put the server near the people using it and the widget simply feels quicker.
Jurisdiction usually agrees, because most businesses have visitors concentrated where they operate, and the region nearest most of your traffic is also the one your customers expect their data to sit in. A UK retailer serving UK shoppers gets lower latency and an easier conversation with a privacy-conscious buyer from the same choice.
Where they do conflict, jurisdiction usually wins, because latency is a matter of degree and jurisdiction is a matter of kind. A visitor tolerates an extra eighty milliseconds without noticing. A procurement reviewer does not tolerate the wrong answer about where personal data rests. Choose for the constraint that has a threshold, not the one that has a gradient.
The regions you can actually choose
MyLiveChat runs in four managed regions, selected from Server Region in your dashboard. New sites default to Dallas, Texas in the United States. The alternatives are Beauharnois in Quebec, Canada; London in the United Kingdom; and Sydney, Australia.
That list is worth reading literally rather than aspirationally. If your requirement is that data must rest inside the European Union specifically, note that London is in the United Kingdom, which since Brexit is a separate jurisdiction from the EU with its own adequacy arrangements. That distinction matters to some buyers and not at all to others, but it is the kind of detail that is much cheaper to notice now than during a security review. The trust page carries the current commitments and the document request paths in one place.
If none of the four fits a hard requirement, the managed service is not your answer and you should skip ahead to the self-hosting section rather than trying to make a region choice carry weight it cannot bear.
Switching regions is a migration, not a toggle
This is the part teams get wrong, because it looks like a dropdown and behaves like a move. When you save a new region, the workspace migrates and future chat routing is refreshed. That is real work happening behind a simple control, and it has preconditions.
All agents must be signed out and all active chats closed before the change. This is not bureaucratic caution; a conversation in flight has state on the server you are moving away from. After you save, the workspace needs a few minutes to finish syncing before you reopen the console and test. Reopening immediately and concluding that chat is broken is the most common self-inflicted wound here.
So treat it as a scheduled change rather than an idle afternoon click:
- Pick a genuinely quiet window. Your own hourly volume chart tells you when that is. Do not guess, and do not assume it is the same day of the week as last month.
- Tell the team beforehand. Agents who know the console will be unavailable for a few minutes do not file a bug report about it.
- Set your widget to a truthful offline state for the window, so visitors get an honest message rather than a chat that never connects.
- Close active chats deliberately rather than waiting for them to age out, and confirm every agent is signed out rather than merely idle.
- Wait, then test a real conversation end to end before declaring it done. Send a message from a visitor session and answer it from the console.
Because it is disruptive by nature, do it once, deliberately, rather than experimenting. Decide the region on evidence about your traffic and your obligations, then move once and leave it alone.
What choosing a region does not buy you
A region is a location, not a compliance posture, and the gap between those two is where overconfident answers live. Selecting London does not by itself make you GDPR compliant, because compliance is mostly about what you collect, why, how long you keep it, who can see it and how you handle requests. All of that is unchanged by geography.
Specifically, a region choice does not decide your retention window, does not restrict which of your own agents can read transcripts, does not sign a data processing agreement, and does not change what your widget collects from visitors in the first place. Those are separate decisions that you still own, and they are the ones a serious reviewer will ask about second, immediately after the easy geography question.
Encryption is likewise orthogonal. Conversations are protected in transit and at rest regardless of which region you pick, so encryption is not a reason to prefer one over another.
When self-hosting is the honest answer
Some requirements cannot be met by any managed region, and it is better to recognise that early than to negotiate against a constraint that will not move. If your obligation is that data must never leave hardware you control, or must rest in a country not on the list, or must sit inside a specific network boundary, then the managed service is the wrong shape of product for you and the self-hosted option is the real answer.
Self-hosting moves the whole question onto your infrastructure: the data lives wherever you put it, which is exactly the point, and the operational burden of patching, backups, availability and access control moves to you along with it. That is a genuine trade, not a free upgrade, and the teams who are happiest with it are the ones who chose it because of a specific written requirement rather than a general unease.
Write the answer down before procurement asks
The security questionnaire will come, usually at the least convenient moment in a deal, and the answer to the storage question should be a paragraph you already have rather than a research project. Write it once and keep it where the person who gets asked can find it.
A good version of that paragraph names the region in plain words, states who at your company can read conversation data and how that access is controlled, gives your retention window and what happens at the end of it, and links to the vendor documents rather than paraphrasing them from memory. Paraphrasing a security commitment is how an accurate document becomes an inaccurate answer.
Keep it truthful about limits, too. If you are on a managed region, say so rather than implying dedicated infrastructure. A reviewer who catches one overstatement re-reads everything else with suspicion, and you will have spent far more time recovering from that than the honest sentence would have cost.
What to measure
- Where your visitors actually are, by share of conversations rather than by impression. The region decision should follow this number, and it is worth re-checking yearly as markets shift.
- Perceived responsiveness after a region change, from the agent side as well as the visitor side. Agents feel console latency all day and will tell you quickly.
- Time to answer the storage question when it arrives. If it takes more than a few minutes, the written answer is missing or hard to find.
- Whether your retention window is actually enforced, not merely documented. This is the follow-up question after geography, and the one more teams fail.
- Any drift between what your public pages claim and what your settings say. Both change over time; only one of them tends to get reviewed.