| Owner | |
| Stakeholders |
Issue
A key decision must be made on how to deploy the SAP Global Trade Services (GTS) environment. SAP GTS c an be deployed in two main ways:
- Option A: SAP GTS Co-Deployed within S/4HANA – This approach integrates SAP GTS directly within the S/4HANA system, operating in a dedicated client. It eliminates the need for a separate GTS instance, streamlining system management.
- Option B: Deploying SAP Global Trade Services (GTS) as a standalone system while integrating it with SAP S/4HANA – SAP GTS runs as an independent instance while integrating with SAP S/4HANA, rather than being co-deployed within it.
This document analyses the benefits, limitations, and feasibility of each option to identify the best fit for the project’s objectives and long-term strategy.
Recommendation
It is recommended to adopt the Co-Deployed approach within S/4HANA ( Option A ) in a dedicated client . This deployment retains the full functionality of SAP Global Trade Services (GTS), just as in a Stand-alone setup, while offering additional benefits.
Key advantages of the Co-Deployment approach include:
- Simplified IT landscape – Reduces system complexity and integration efforts.
- Lower infrastructure costs – Eliminates the need for a separate GTS instance.
- Optimized operations & maintenance – Unified management within S/4HANA.
- Enhanced compatibility – Seamless integration with core SAP processes.
- Future Scalability: If functional or technical requirements change, SAP GTS can be transitioned from a co-deployment to a standalone deployment in the future.
Given these benefits, the Co-Deployed approach within S/4HANA (Option A) is the recommended deployment option to maximize efficiency and minimize operational overhead.
Background & Context
As part of the SyWay Project, the implementation of SAP Global Trade Services (GTS) is required, along with its integration into the SAP S/4HANA system. There are two SAP GTS deployment approaches available for the project, each with distinct infrastructure and operational requirements.
This document evaluates these options and recommends the most suitable approach based on the project's specific requirements, complexity, and business objectives. The evaluation considers factors such as system compatibility, ease of implementation, costs, and system landscape requirements.
A decision on the deployment approach must be made at this stage, as the SAP GTS Co-Deployed approach within S/4HANA presents an opportunity to optimize landscape costs. The available deployment options are:
Option A: SAP GTS Co-Deployed within S/4HANA
With S/4HANA 2023, SAP GTS can now run in a separate client of a S/4HANA Instance without compromising the functional scope—an improvement over previous S/4HANA versions. Key characteristics of this deployment include:
- SAP GTS and SAP S/4HANA share the same database and application server, meaning they also share system resources.
- GTS runs on a separate client in the S/4HANA platform. This is required because as indicated in the SAP documentation “You must install SAP Global Trade Services, edition for SAP HANA 2023 in a separate client from SAP S/4HANA 2022/2023 or master data distribution from S/4 to GTS will not work”.
- Unified Maintenance: Updates and patches are managed together with SAP S/4HANA, creating a technical dependency between both solutions.
- IT Operations and administrative tasks are shared by both solutions.
Option B: Deploying SAP Global Trade Services (GTS) as a standalone system while integrating it with SAP S/4HANA
This has been the traditional approach for SAP GTS implementations. Until S/4HANA 2023, this was the only deployment option that ensured full functional scope availability.
Key characteristics of this deployment include:
Independent System: SAP GTS operates on dedicated application and database servers, separate from S/4HANA.
Integration Interfaces Required: Data exchange with S/4HANA relies on RFC, IDocs, APIs, or other integration methods.
Separate Administration & Maintenance: System operations, updates, and administration must be managed independently.
Higher Infrastructure Costs: Requires additional servers, resources, and licenses, increasing total cost of ownership (TCO).
While this deployment offers full functional scope as for option A, it also results in higher complexity and costs due to separate system management and integration requirements.
More details are available here:
- Blog SAP GTS Deployment
- System Landscape for SAP Global Trade Services, edition for SAP HANA | SAP Help Portal
- SAP Global Trade Services, edition for SAP HANA | SAP Help Portal
Assumptions
- No Functional Restrictions: Both deployment options provide the same functional capabilities.
Future Flexibility: A co-deployed SAP GTS system can be separated into a standalone deployment if needed.
Software Component Alignment: S/4HANA and SAP GTS must remain synchronized in terms of software components, creating a technical dependency in both scenarios.
System Time Zone: All SAP applications, including SAP GTS, will operate on UTC time, following SAP’s recommended best practice. There are no specific time zone requirements for SAP GTS.
No Workbench Object Conflicts: SAP GTS uses its own workbench objects, ensuring no impact when running in a co-deployed mode.
Project Implementation Unaffected: Both options fully support all required activities for a SAP GTS Greenfield implementation, including:
Interface configuration
Data loading
Testing
Customizing
Development
No Historical Data Migration: Existing historical data from the current SAP GTS system (SID WGP) will not be migrated. Only open items could be required.
Constraints
- Choosing RISE for a standalone SAP GTS system will require a long-term financial commitment, as the system cost will apply for the entire contract duration (7 years). Therefore, a final decision must be made at this stage.
- Integration constraints between S/4HANA and GTS
Impacts
- No Functional Impact: Both the co-deployed and standalone deployment options provide the same SAP GTS functionality.
- Number of systems: Considering that there will be multiple S/4HANA instances in the landscape (e.g. China, USA, Rest of the World), there will necessarily be multiple GTS systems and therefore some degree of dual maintenance of certain master data or the creation of additional interfaces to distribute master data from the primary system in the EU to the other systems.
Technical Dependencies: SAP S/4HANA and SAP GTS versions must remain aligned from a software component perspective. As SAP GTS evolves, new functionalities may require patches or upgrades. To mitigate potential impacts, the following actions are recommended:
Patch & Upgrade Strategy: Establish a proactive approach to keep systems updated based on technological advancements and business requirements.
Regression Testing Strategy: Implement a structured regression testing process, leveraging automated testing tools to minimize effort and ensure system stability. This should be analyzed as part of the Testing Strategy.
S/4HANA Resource Requirements: Running SAP GTS within S/4HANA will increase slightly resource demands as per analysis performed.
The assumption based in current EWA analyzed is that GTS requirements would be similar to a system Size catalogued as "Small" with 2/4 CPUs, 16/32GB RAM ,<500GB disk size and 60 users.
The necessary adjustments to S/4HANA sizing must be analyzed to accommodate these additional workloads. However, this analysis is beyond the scope of this document.
Business Rules
None
Options considered
Option A: SAP GTS Co-Deployed within S/4HANA system
The co-deployed option refers to deploying SAP GTS within the same SAP S/4HANA system rather than operating it as a standalone instance. In this approach, SAP GTS runs on the S/4HANA platform as a separate client.
- Shared Infrastructure: SAP GTS and SAP S/4HANA share the same database and application server . Therefore, additional system resource requirements must be analyzed to ensure optimal performance.
- Resource Analysis based on the Early Watch Alert (EWA) from 17 March 2025 for the current SAP GTS production environment (SID WGP):
- WGP runs on a shared AWS r6i.2xlarge server with following attributes: 8 CPUs, 64GB RAM, 1.1TB DB disk.
SAP GTS specific tables occupy approximately 346GB.
- Other technical tables (logs, change documents...) occupy approximately 219GB
- DB Disk Average monthly growth is 7GB approximately
Current DB disk use is high (950 GB) , but as per the data strategy, historical data migration is not required, only open items will be migrated, significantly reducing disk space requirements.
- 61 active users.
Based on above data we can conclude that estimated additional infrastructure needs on S/4HANA for SAP GTS system are equivalent to a "Small" size system (e.g., 2/4 CPUs, 16/32GB RAM, <500 gb disk, 60 users).
Separate Client: GTS operates in a dedicated S/4HANA client, ensuring functional separation. That also mean that the workbench objects are shared between all the SAP S/4HANA system clients. This will not have any impact since SAP GTS Standard objects use its own Namespace (/SAPSLL/) and packages (/SAPSLL/*). Custom objects (if required) for GTS should be created in the a dedicated namespace to avoid conflicts with other potential developments.
Simplified Maintenance: Updates, patches, and operations are managed together with SAP S/4HANA, reducing administrative effort.
Real-Time Access: Direct access to S/4HANA data improves efficiency.
Cost Efficiency: Eliminates the need for an external SAP GTS system, leading to lower infrastructure and operational costs.
System Resources Considerations: Since SAP GTS and S/4HANA share infrastructure resources, proper sizing adjustments must be factored in during implementation.
- The co-deployed client applies to every S/4HANA instance to be created in Syensqo landscape, that means:
- a co-deployed GTS client in the S/4HANA ROW instance
- a co-deployed GTS client in the S/4HANA China instance
- a co-deployed GTS client in the S/4HANA North America instance (if confirmed)
Option B: Deploying SAP Global Trade Services (GTS) as a standalone system while integrating it with SAP S/4HANA
This option involves running SAP GTS as a standalone instance, separate from SAP S/4HANA.
Key Points:
Independent Operation: SAP GTS runs independently from SAP S/4HANA on a dedicated application server and database.
Integration Requirement: Integration interfaces are needed to enable data exchange between SAP GTS and S/4HANA.
Maintenance: Requires separate operational management, with updates and patches handled independently for SAP GTS.
Resource Efficiency: By processing system activities separately, this option reduces slightly the sizing requirements for SAP S/4HANA.
- Landscape Requirements: With this approach would be required a SAP GTS System for every project environment, meaning: Development, Integration Test, User Acceptance Test, PreProduction, Production.
Increased Costs: This approach incurs higher costs due to the need for additional infrastructure and system resources.
Version Alignment: System components, such as SAP GTS and SAP S/4HANA, must be kept aligned in terms of versions to ensure smooth integration.
Evaluation
Based on the following matrix Option A have been chosen :
Option A | Option B | |
|---|---|---|
| Landscape Cost |
|
|
| Landscape Complexity |
|
|
| Maintenance Complexity |
|
|
| Functional Scope |  Full Scope | Full Scope |
| S/4HANA Resources Requirements |  Small Additional system requirements on S/4HANA(2/4 CPU,16/32GB RAM) since GTS process will run on the same instance | System resources Full dedicated to GTS processes |
See also
Blog SAP GTS Deployment
System Landscape for SAP Global Trade Services, edition for SAP HANA | SAP Help Portal
SAP Global Trade Services, edition for SAP HANA | SAP Help Portal
2447201 - KBA: Where to find GTS Documentation - SAP for Me
SAP Note 3016042 - Sizing for SAP Global Trade Services, edition for SAP HANA 2020