Overview of SAP cloud instance strategies for global subsidiaries highlighting key features and drivers.
A new overseas entity is being established, and an SAP S/4HANA Cloud, public edition instance is already up and running.
On the project side, a common conclusion is: “To save cost and effort, let’s just add the new company code into the existing instance.”
At first glance, this looks like a rational first-year decision, but it hides structural risks that will surface in a few years from three perspectives: management, business operations, and systems.
This article uses a Japanese automotive parts manufacturer rolling out SAP S/4HANA Cloud, public edition to its overseas locations as a scenario.
It compares “adding a new company to an existing instance” versus “building a new, independent instance” across four viewpoints.
On that basis, it then discusses which option is strategically sound for a parent company that emphasizes global management accounting, ROIC-driven management, and portfolio management.
The scenario in this article assumes the following setup.
The SAP implementation scope for Company B is FI (Financial Accounting), CO (Controlling), SD (Sales), MM (Materials Management & Inventory), and PP (Production Planning).
At the project initiation phase, the key decision is whether to “add Company B’s company code into Company A’s instance” or to “build a dedicated new instance for Company B.”
SAP S/4HANA Cloud, public edition has several important technical constraints that differ from other SAP products.
One of the most critical constraints is the controlling area design:
“In SAP S/4HANA Cloud Public Edition there is only one controlling area (A000). This configuration cannot be changed under any circumstances.”
This means an instance can have only one controlling area.
All company codes in the same instance must therefore share the same chart of accounts and the same fiscal year variant at the controlling-area level.
A second constraint is equally significant:
“It is not possible to delete confirmed organizational units.”
Once an organizational structure entity (such as company code, plant, or sales organization) is confirmed, it cannot be deleted in a live SAP S/4HANA Cloud, public edition system.
In practice, this means that even if you later decide “we should have put this company on a separate instance,” there is no way to roll back the change within the same tenant.
These constraints elevate instance strategy from a technical configuration choice to an irreversible management decision that must be made before the project formally starts.
Option A: Add Company B to the existing instance of Company A.
However, the hidden risk is often underestimated.
Company A is a joint venture in which Company X holds more than 51% and has a partner, Company Y.
Stakeholders from Company Y are also users of Company A’s system.
Even with strict role-based access control, having Company B’s cost structure, ramp-up plans, and profitability data in the same physical instance does not constitute true information isolation.
From a global perspective, a joint venture partner can easily become a future competitor.
Allowing the JV partner to infer Company B’s ROIC potential indirectly from the shared instance represents a serious management risk.
Option B: Build a dedicated, independent instance for Company B.
If Companies A and B share the same instance, intercompany transactions (internal transfers of parts, intra-group procurement, etc.) can be processed in real time.
Master data such as business partners and materials can also be shared between the two companies, which is a clear advantage of a single-instance design.
However, there are several concerns.
Company A deals with two-wheeler components, while Company B deals with four-wheeler components.
If the overlap in material master structures, cost center hierarchies, and supplier portfolios is low, the real benefit of sharing master data is limited.
In contrast, the risk that configuration changes for Company B cause regression issues in Company A’s already live processes becomes a more serious issue.
As one expert comment notes:
“Regression testing efforts are significantly larger in a single instance deployment.”
Company A has already been live for a year.
Every time Company B introduces new functionality or configuration in FI, CO, MM, or PP, full regression testing would be required in Company A’s environment.
Both the cost and the risk of downtime weigh heavily on the stable operation of Company A, where the joint venture partner is deeply involved.
If you look only at first-year implementation cost, adding Company B to the existing instance appears cheaper.
However, three structural cost factors must not be overlooked.
From an operations-cost viewpoint, a single instance undeniably has lower license and infrastructure cost.
However, several operational risks need close attention.
In SAP S/4HANA Cloud, public edition, upgrades are automatically applied by SAP.
If Companies A and B share the same instance, a single upgrade will affect both entities simultaneously.
Company B, being a 100% subsidiary of Company X, can proceed with testing and acceptance based on the parent company’s schedule, but Company A must always coordinate with its joint venture partner.
This asymmetry in decision-making speed significantly amplifies operational complexity.
Furthermore, if Company X’s ownership in Company A drops below 50% in the future, Company B’s data will have to be separated from Company A’s instance.
Such a migration would require effort and cost equivalent to a new greenfield implementation project.
This point is so critical that it deserves separate discussion.
SAP S/4HANA Cloud, public edition imposes fundamental constraints on data migration between instances.
According to SAP’s own documentation:
“You can use the SAP S/4HANA migration cockpit to migrate the initial set of data that is required to start business operations. This data includes master data, open transactional data, and balances.”
The migration cockpit is designed for initial loads only and does not support full historical data migration.
In other words, you can migrate master data, open items, and balances, but closed historical transactions (posting history, production confirmations, detailed cost analysis) cannot be brought into the new instance.
In addition, mapping and configuration performed in one tenant cannot simply be transported to another.
All configuration for Company B would have to be redesigned and rebuilt manually in the new instance.
Therefore, “migrating to an independent instance later” effectively means:
This is not a “slightly more complex data migration,” but in effect a second greenfield implementation project.
If Company X is serious about ROIC-driven management, portfolio management, and global management accounting, the instance strategy should follow three guiding principles.
Placing joint ventures and wholly-owned subsidiaries in the same instance leaves fundamental governance and information security risks unresolved.
As a rule of thumb, entities with different ownership structures should be managed on separate instances.
Instead of forcing all entities into a single instance, Company X should use SAP Group Reporting and/or SAP Analytics Cloud as the integration layer at HQ level.
This “visibility layer above the instances” enables scalable and secure global ROIC calculation and portfolio management without sacrificing data isolation at the instance level.
Company B is planned to grow to several times the size of Company A, and Company X’s stake in Company A may fall below 50% in some scenarios.
The design must recognize that today’s cost-minimizing decision could lead to multiplied costs and opportunity loss several years later.
Before deciding on the instance strategy, project managers and IT leaders should validate the following points.
The instance strategy for SAP S/4HANA Cloud, public edition is not a decision that project managers or IT architects should make in isolation.
It is a management decision that integrates capital structure, governance, information security, business growth scenarios, and the overall direction of group-level management.
While adding Company B into Company A’s instance might look reasonable as a first-year cost optimization measure, it becomes clear—once you understand the constraints around non-deletable organizational entities and the practical impossibility of moving full data between instances—that this path carries significant long-term risk.
For Company X to realize ROIC-driven management on a global scale, instance strategy decisions for each site must be made not as isolated “points,” but as part of a coherent architectural “line and surface” that covers the entire group.
The first step is to hold an “Instance Strategy Steering Meeting” at the management level before project kickoff and to ensure that IT-related decisions are never made solely within the IT domain.
Parts of this article were developed with reference to generative AI suggestions and were reviewed, refined, and supplemented based on the author’s professional expertise and judgment.
This article explains why product costing is complex for automotive Tier 1 suppliers and how…
A practical guide to SAP S/4HANA implementation in automotive Tier 1 suppliers, focusing on real-world…
This article explains how Tier 1 automotive suppliers can leverage Enterprise Architecture to connect IT…
A practical guide to SAP Signavio covering process mining, business transformation, S/4HANA alignment, and project…
A practical guide to SAP MDG implementation for successful master data management in enterprise integration…
This article explains how Enterprise Architects can use TOGAF Preliminary Phase and Phase A to…