Comparison of single instance, multi-instance, and hybrid SAP cloud deployment strategies with their benefits, driving factors, and enabling platforms.

Insight Arc | SAP, Enterprise Architecture & Supply Chain Strategy

SAP S/4HANA Public Cloud Instance Strategy for Overseas Subsidiaries: How to Design for Joint Ventures, Wholly-Owned Subsidiaries, and ROIC Management

Introduction: The Hidden 10-Year Risk of “Just Add a Company Code”

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.

Scenario Assumptions: Relationship Between Company X, Company A, and Company B

The scenario in this article assumes the following setup.

  • Company X (Japan HQ): A Tier-1 automotive parts supplier that has declared global management accounting, portfolio management, and ROIC-focused management as core management policies.
  • Company A (existing joint venture): A joint venture in which Company X holds more than 51% of the equity. It manufactures two-wheeler parts and has been running on SAP S/4HANA Cloud, public edition for one year.
  • Company B (new 100% subsidiary): A newly established, wholly-owned subsidiary of Company X that will manufacture four-wheeler parts. Its initial-year revenue and production volume will be small, but it is planned to grow to several times the size of Company A within a few years.

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.”

Why Instance Strategy Must Be Decided Before Project Kickoff

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.

Four Perspectives: What Happens When You Put a JV and a 100% Subsidiary on the Same Instance?

1. Management Perspective

Option A: Add Company B to the existing instance of Company A.

  • Because Companies A and B are in the same controlling area, Company X can aggregate group management accounting data in real time.
  • ROIC can be calculated by segment or by operating company without building a separate integration layer.
  • Group reporting configuration is straightforward, which helps reduce initial implementation cost.

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.

  • Physical separation of Company B’s data is guaranteed, so its management information remains fully protected even if Company X’s ownership in Company A falls below 50% in the future.
  • When Company B grows to several times the size of Company A, its expansion will not jeopardize the operational stability of Company A’s system.

2. Business Process Perspective

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.

3. Implementation Perspective

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.

  1. Version misalignment
    Company A is already running on a specific release level, while Company B will be implemented on the current release.
    This requires careful compatibility checks and may even force a prior upgrade of Company A as part of the project, adding scope and cost that are not directly related to Company B.
  2. Permanence of design mistakes
    Because organizational structure entities cannot be deleted, any initial design error will remain for the entire system lifecycle.
    If Company B has its own instance, design mistakes can be corrected without impacting Company A.
  3. Future separation cost
    Once Company B grows to several times the size of Company A, separating it out from the same instance becomes practically impossible.
    In SAP S/4HANA Cloud, public edition, attempting “late separation” is extremely expensive both technically and from a business standpoint.

4. Operations Perspective

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.

Why “Separating Later” Is So Expensive: Migration Reality

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:

  • Redesigning and re-implementing all business configuration for Company B in a fresh instance.
  • Closing and minimizing open items before the migration date and reconciling balances.
  • Re-executing unit, integration, and user acceptance tests for all modules from scratch.
  • Storing historical data separately, for example in SAP Analytics Cloud or another reporting platform.
  • Keeping Company B’s legacy data in Company A’s instance for the legally required retention period and bearing the associated operational cost.

This is not a “slightly more complex data migration,” but in effect a second greenfield implementation project.

Recommended Architecture Principles for Company X

If Company X is serious about ROIC-driven management, portfolio management, and global management accounting, the instance strategy should follow three guiding principles.

Principle 1: Align Instance Boundaries with Governance Structures

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.

Principle 2: Perform Group-Level Integration in an Upper Layer

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.

Principle 3: Design for Future Business Scale and Capital Structure Changes

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.

Checklist for PMs and IT Leaders

Before deciding on the instance strategy, project managers and IT leaders should validate the following points.

  • Is the equity structure of the target entity and its relationship with joint venture partners clearly understood?
  • Do Companies A and B share the same fiscal year and chart of accounts design?
  • Is there a clear 3–5-year business scale forecast for Company B?
  • Has the release alignment between Company A’s current version and the planned version for Company B been confirmed?
  • Has a design for a group-level data integration layer for ROIC calculation (SAP Group Reporting or SAC) been defined?
  • Do the JV contracts for Company A include explicit clauses on access restrictions to Company B’s data?
  • Has a TCO comparison been carried out that includes the potential future cost of later instance separation?

Conclusion: Instance Strategy Is a Management Decision, Not Just an IT Decision

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.

Reference Links

Disclaimer

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.

Back to Top

REI Avatar

Published by

REI
Categories:
Tags: , , , , , ,

Leave a Reply

Discover more from Insight Arc | SAP, Enterprise Architecture & Supply Chain Strategy

Subscribe now to keep reading and get access to the full archive.

Continue reading