When growth means regionalization
A European manufacturer has been operating in China for years. What started as a sales market has gradually grown into a strategic business unit, with its own local customers, suppliers, and partners. To strengthen its position, the company decides to give its China business more autonomy: its own sales structure, its own decision-making authority, closer ties to local partners and suppliers.
At first, this looks like a purely business decision. Systems and data are barely part of the discussion. The focus remains on expanding the business. Six months later, the first uncomfortable question lands on someone’s desk. A new local partner needs access to systems the global IT architecture was never built to share. Then compliance asks a harder one: whether any of the data now flowing to that partner was ever supposed to leave the country. What started as a business decision has quietly become an IT challenge, and possibly a legal one.
This is where most companies get the sequence wrong.
A pattern, not a coincidence
That partner request turns out to be only the first of several. The regional service team asks for faster response times than the global system supports. Compliance starts asking where customer records are actually stored. Each request gets resolved on its own, none of it part of the original plan, none assigned to a specific department. Seen together, though, these are not unrelated cases. It reflects the same underlying pattern: the business has changed, while the logic behind the company’s IT decisions has not. This is where many companies make their first strategic mistake.
Why data residency must come first in IT localization
The mistake usually starts with a familiar question: Which applications do we actually need, and which existing systems can support the business as it becomes more regionalized? It feels like the natural next step, a concrete decision the IT team can act on, and once it is answered, momentum builds around implementing it.
What often gets asked too late is where different categories of data are actually allowed to reside. In our experience, that question tends to get treated as an afterthought, something compliance can sort out later, rather than a factor that should shape how those applications are designed, connected, and localized.
The consequences of that ordering show up late. A system gets selected and rolled out, and only afterward does someone notice that certain data was never allowed to leave the country to begin with, forcing a costly rebuild or a workaround nobody wanted. What looked like a straightforward application choice turns into a regulatory compliance problem, and fixing it costs far more than getting the sequence right from the start would have.
Not all data is subject to the same rules. Understanding that difference is where the next decision begins. Systems follow data, not the other way around, and regionalization is fundamentally a business decision that creates IT consequences, consequences that should be designed from data residency outward.
Cross-border IT compliance: a landscape that doesn’t sit still
This is not a hypothetical risk. Companies operating between Europe and China must comply with two regulatory environments that are evolving independently, and what is allowed in one jurisdiction may be restricted in the other. AI applications make this harder still, since they typically draw on more data, from more sources, than the systems they replace.
Here is our approach: identify where data needs to reside, then build the application landscape and infrastructure around that answer. Together, these decisions form what we call the IT architecture target picture.
Navigating the three localization models
In the following we focuse on the first two of these steps. The third, the target operating model and security, is a conversation of its own.
Most companies would call the first step data localization. At Detecon, we use a broader term for it, because the question is not just where data is stored, but where data and business capabilities need to reside, and how that decision shapes everything built on top of it.
Where does data actually belong?
At Detecon, this classification step is what we call Geopatriation.
Geopatriation goes beyond the narrower definition sometimes used in the industry, where the term mainly describes moving workloads away from global cloud providers to either local data centers or local private clouds. Here, it means something broader: establishing where data and business capabilities need to reside, whether a company is migrating an existing system or building one from scratch.
It is the foundation of what we think of as enterprise architecture for IT localization: not a single infrastructure choice, but a sequence of decisions that starts with data.
Instead of starting with infrastructure, companies first need to understand what their data actually requires because that answer is what later shapes the application landscape and, eventually, where each system runs. Every system raises the same four questions, and how it answers them determines where it lands on all three of those decisions. We call them CRED:
Connectivity – does the system need constant, low-latency access, and what happens to it if that connection is cut?
Regulatory risk – is the data legally sensitive today and how likely is that going to change?
Ecosystem integration – how fast does its local environment change now and in the future?
Data Protection – how much intellectual property does a breach expose, and how would that exposure evolve?
Run through these four questions, a system usually lands in one of three places: fully local, connected but local, or staying global, as the examples below show and that placement is what drives the application landscape and deployment decisions that follow.
Four questions, one decision
These four criteria do not just apply to individual systems. They apply across the whole value chain, and different functions tend to lean on different ones.
What drives localization?
The manufacturer’s CRM system is a good place to see this up close.
Customer records fall under a layered framework of Chinese law, including the Personal Information Protection Law, the Cybersecurity Law, and the Data Security Law. Depending on how sensitive or extensive the data is, it may also be classified as “important data,” a category that can trigger stricter requirements even for information that isn’t personal. In practice, this means the largest or most sensitive datasets typically require a formal government review before they can leave the country, while smaller or lower-risk transfers have lighter compliance paths available.
Storing Chinese customer data outside China is rarely a simple yes-or-no question, it depends on exactly what the data is and how much of it there is. The integration environment reinforces the same conclusion from another angle: Chinese customers largely operate through platforms like WeChat and Alipay, and these interfaces change fast, often faster than a system built for another market can keep up with.
That pace is part of what makes local ecosystem integration in China so demanding for a system built elsewhere. In practice, that combination tends to push the CRM toward a fully independent setup in China: not just a local copy of the global system, but its own instance with its own local operations.
The MES, the manufacturing execution system that runs the factory floor, raises a separate concern, and two criteria at once. It handles process parameters and configurations that competitors would pay to see, sensitive enough that China’s Data Security Law treats certain categories of it as requiring stricter local handling.
Once this data lives in a database shared across multiple systems and teams, protection depends on who has access to what, and role-based permissions are not a guarantee on their own. They are difficult to keep consistent across borders, and a breach of that kind of shared database can expose far more sensitive information than a system designed for a single purpose.
Connectivity adds a second layer, and it is where many companies first run into China’s data connectivity issues in practice. Systems like this depend on constant, low-latency access, and data that has to cross the Great Firewall to reach a server outside China introduces exactly the kind of delay real-time production monitoring cannot absorb.
That connection is also not guaranteed to stay open. A single undersea cable, damaged by a ship’s anchor or a natural disaster, can cut the physical link between two continents for days while repairs are arranged. A system that depends entirely on cross-border access to China carries that risk by design.
Unlike the CRM, though, this system does not need to stand entirely on its own. A local instance, feeding the global ERP only with data that does not depend on real-time exchange, is usually enough.
Financial consolidation data tends to sit at the other end of this spectrum. Aggregated figures rarely trigger the same regulatory or IP concerns as customer or production data, and the integration environment around them barely changes. In most cases, that keeps finance largely part of the global system. But the answer isn’t universal, and companies often underestimate how many regulators can have a say in the same figures. Tax-related data crossing the border, for instance, must satisfy the Data Security Law and the Cybersecurity Law as well as tax-specific reporting requirements, and different industries can bring additional regulators into the picture. It is worth confirming case by case rather than assuming a blanket answer applies.
This classification provides a horizon of roughly five years to plan against, not a fixed answer that expires on schedule. It stays valid for as long as the underlying picture holds, and is revisited only when something genuinely changes it: a new law, a cut connection, a shift in the business itself.
Systems follow data, not the other way around
For the CRM, the answer is already set by the classification. Because parts of that customer data, depending on how they are used, are required to stay in China and the system needs to work inside another digital ecosystem, a shared global instance was never really an option.
For a large enterprise, that typically means running a separate, largely self-contained CRM for its China business, operated by the regional organization, with only limited exchange back to Europe. Smaller companies often cannot justify that level of duplication, and instead rely on a local partner or a lighter, China-specific tool that covers the essentials without the full operational overhead of a second system.
The MES tells a different story. Its data also needs to stay local, but the system does not need to be reinvented from scratch. A local instance, deployed in China, is connected to the global ERP through a small, well-defined set of interfaces, just enough to feed relevant figures back into group reporting without exposing the underlying production detail.
Finance itself needs no fully independent local instance. In most cases, it continues to run largely as it always has, with the China business reporting into it, though smaller local add-ons, for tax or statutory reporting requirements, for example, are common even here.
The CRM and the MES may both require a footprint in China, but they do not require the same architecture, and that gap is not accidental. It reflects a principle we apply across information system decisions more broadly: build independently where speed and local adaptability matter most, stay close to the standard where integration, and often cost, favor consistency over independence.
The CRM leans toward the first. What matters most is how quickly it can adapt to a fast-changing local market, and a specialized local system tends to do that better than a global suite built for many markets at once. The MES leans toward the second. What matters there is that production data flows reliably into the group’s existing reporting and planning processes, which favors staying close to the standard rather than building something entirely separate.
None of this was obvious from the classification alone. It only became clear once the company asked, system by system, what kind of independence each one actually needed, and what kind of connection each one could not do without. The result is an architecture shaped by business and data requirements, not by infrastructure preferences.
Only now: where it runs
With the application landscape defined, deployment follows, together with the question of who operates each system day to day.
The CRM, running as its own instance and built for speed and local integration, fits naturally on a Chinese public cloud platform. It provides the flexibility and local ecosystem integration the system depends on, without adding infrastructure the company would otherwise have to manage on its own. Responsibility for operating it may also shift to the regional organization, rather than remaining entirely with central IT.
The MES sits in a different category. Because it carries sensitive production data and depends on constant, low-latency access, it runs on-premises or in a private cloud environment close to the factory floor, prioritizing control and reliability over the flexibility a public cloud would offer.
Finance needs no separate local system. It can continue to use the company’s existing global systems.
Each deployment choice here follows directly from decisions made in the two steps before it. When infrastructure is the last consideration instead of the first, it becomes the logical consequence of earlier decisions rather than a debate in its own right.
Taken together, these three decisions complete the IT architecture target picture this article set out to build.
Beyond infrastructure
The architecture is now defined, but the work does not end there.Security policies that once applied to a single, unified system now need to remain consistent across separate environments. Cost allocation and ownership also become important once responsibilities are shared between a regional business unit and a central IT function that previously owned everything.
These questions go beyond the architecture itself. They open the next conversation, the one about how the company runs what it has built.
Where to start
Most companies that get this wrong do not fail because they chose the wrong cloud provider. They fail because they asked the infrastructure question before understanding what the business needed locally, where the supporting data belonged, and which systems had to follow.
Getting that sequence right does not require a perfect plan on day one. It requires asking the right questions in the right order and revisiting the decisions when the business or regulatory environment changes, not simply because time has passed.
This is the sequence Detecon works through with clients regionalizing between Europe and China: from the business decision that starts it all, through data residency and application landscape, to deployment. Because successful regionalization is not about choosing the right cloud. It is about asking the right questions first.
