A few weeks remained before go-live in an SAP project. The project plan was progressing, user tests were being completed, and integrations were being activated one by one. On paper, everything appeared to be under control.
However, as more users joined the testing process, the system began to behave differently. Some reports took longer to load, batch processes exceeded their expected runtimes, and performance fluctuated during periods of heavy integration traffic.
The infrastructure was not underpowered. At least, that was how it appeared when looking only at server capacity.
The real issue was that capacity had not been evaluated alongside the realities of the project. User numbers had been considered, but concurrent usage, seasonal transaction peaks, integration loads, and data growth had not been brought together within the same scenario.
This is not an isolated example. It reflects a pattern that recurs across projects of different sizes: in S/4HANA Greenfield projects, infrastructure is often built with sufficient capacity, but it is not always designed around the right workload.
The Greenfield approach gives organizations an opportunity to redesign both their processes and technical architecture. Yet a genuine fresh start is not achieved simply by leaving legacy processes behind. It also requires designing the underlying platform around future business needs.
So, do infrastructure decisions—which are often less visible than process design, data migration, and the go-live schedule—receive the level of attention they deserve in S/4HANA Greenfield projects?
Infrastructure planning is not necessarily neglected in such projects. However, it is often treated as a technical workstream to be resolved within the IT team and is not connected early enough with workloads, integrations, growth expectations, and business continuity objectives. Yet infrastructure decisions directly affect system performance, scalability, resilience, and the long-term operating model.
This article does not cover every aspect of an S/4HANA Greenfield transformation. Instead, it focuses on how the infrastructure should be planned, sized, validated, and monitored after go-live to support a successful and sustainable transformation.
The Fundamental Difference Between Greenfield and Brownfield Approaches
Two primary approaches stand out in S/4HANA transformations: Greenfield and Brownfield.
In a Greenfield approach, processes, the system landscape, and the technical architecture are redesigned. The organization aims not merely to move its existing SAP system, but to establish a simpler, more standardized, and future-ready environment.
In a Brownfield approach, the existing SAP system, processes, and data are largely retained and converted to S/4HANA. This approach may be suitable for organizations that are satisfied with their current operating model, want to limit operational change, or prefer to manage the transformation in a more controlled manner.
| Greenfield may be more suitable when | Brownfield may be more suitable when |
|---|---|
| Existing processes have become overly complex | Existing processes are working effectively |
| Legacy custom developments need to be reduced | Existing investments need to be preserved |
| Business processes will be redesigned | The scope of change needs to remain limited |
| A new architecture is being established | The organization prefers to build on the current environment |
Both approaches have their own advantages and risks. This article focuses on why infrastructure in Greenfield projects—where an entirely new environment can be created—should not be treated as merely another technical work package.
The core value of the Greenfield approach lies in the opportunity to redesign the future operating model rather than carrying the technical and process burden of the legacy system into the new environment. Greenfield is therefore not simply about implementing a new S/4HANA system. It is about creating a simpler, more scalable, and more sustainable structure across processes, integrations, application architecture, and infrastructure.
Why Should Infrastructure Be Planned from the Start of a Greenfield Project?
When a new system is introduced as part of a Greenfield transformation, processes, user roles, integrations, and data structures are reconsidered. Even so, infrastructure decisions are sometimes handled separately from the other project workstreams.
The simplicity targeted at the application level should also be reflected in the infrastructure and operating model. While the Clean Core approach aims to reduce unnecessary custom developments and legacy technical debt, the platform supporting the new system should also be designed to remain manageable, observable, and adaptable to changing requirements. Otherwise, the simplification achieved at the application layer may fail to deliver the expected value because of an overly complex infrastructure and operating model.
While business teams design processes, technical teams typically work on server and capacity planning. If these two workstreams are not aligned early enough, the infrastructure may be shaped by assumptions rather than real usage scenarios.
As go-live approaches, this can lead to risks such as:
- Performance fluctuations under heavy usage
- Unexpected capacity investments
- Longer backup and recovery times
- New bottlenecks as integrations increase
- Last-minute changes to the project schedule
- The need for additional infrastructure investment within the first few years
The critical point is this:Infrastructure planning is not merely a capacity exercise performed by technical teams. It is the process of translating business workloads into technical architecture.
The First Step Toward the Right Infrastructure: Sizing
Sizing is the process of estimating the capacity an S/4HANA system will require. Processing power, memory, storage, and other system resources are planned based on inputs such as user numbers, data volume, transaction intensity, and growth expectations.
In Greenfield projects, SAP Quick Sizer helps translate business data—such as user numbers and transaction volumes—into memory, processing power, storage, and I/O requirements. CPU demand can also be evaluated using SAPS, the standardized performance unit used in SAP environments. However, a Quick Sizer result should not be treated as a direct hardware purchasing list. It is an initial input that supports the broader infrastructure design.
This is because sizing is not simply about answering the question, “How many users will there be?” Two organizations with the same number of users may have entirely different infrastructure requirements. In one organization, most users may primarily view reports, while in another, order processing, production, invoicing, planning, and integration workloads may run concurrently throughout the day.
Not every workload can be explained by user numbers alone. In scenarios such as mass billing, period-end processing, planning runs, or integration flows, what matters is often not how many users initiate the process, but how many business objects must be processed within a specific time window. User-based sizing and transaction-volume-based sizing should therefore be evaluated together.
Daily transaction volume is also not sufficient on its own. The same number of transactions creates a different capacity requirement when spread across an entire day than when it must be completed within a critical two-hour window. Sizing should therefore consider not only average workload, but also peak periods and the timeframes within which business processes must be completed.
In Greenfield projects, the target system does not yet have its own real usage history. However, this does not mean that sizing must rely entirely on assumptions. A realistic workload profile can be created by combining existing operational data, historical transaction volumes, business-unit expectations, and future growth forecasts.
A sound sizing exercise should answer the following questions collectively:
- How many people will use the system in total?
- How many users will be active concurrently?
- Which transactions will users perform, and how frequently?
- How many documents or business objects will be processed within specific time windows?
- How will daily and seasonal transaction intensity change?
- How will data volume grow over the next three to five years?
- How much load will integrations, reporting, and analytics place on the system?
- Are new companies, plants, or locations expected to be added?
Accurate sizing is the starting point of sound infrastructure design. However, the result must be interpreted alongside real usage scenarios, business continuity objectives, the chosen infrastructure model, and growth plans. In other words, sizing is not the final architecture decision itself, but one of its most important inputs.
Performance Is More Than Hardware Capacity
Performance in an S/4HANA environment does not come from the high capacity of a single component. Processing power, memory, storage, network, operating system, and application layers must work together in a balanced manner.
Workload also extends beyond traditional user transactions. Fiori applications, OData services, system-to-system integrations, reporting activities, and background jobs all create different types of load on the infrastructure. These workloads may appear limited individually, but when they run within the same time window, they can generate a significant peak load.
A common misconception in the field is that a powerful server automatically guarantees high performance. In reality, even a fast processor may fail to deliver the expected result if storage or network bottlenecks exist elsewhere in the architecture.
Another important consideration is how accurately the test environment represents the production environment.
If the test environment contains less data, fewer concurrent users, and lower integration traffic than production, successful test results may be misleading. This is particularly relevant in Greenfield projects, where test data and transaction volumes may not adequately reflect future production conditions. As a result, performance bottlenecks may only become visible after the system goes live.
For this reason, it is not enough to confirm that the system starts successfully and transactions can be completed. Load testing shows how the system behaves under expected normal and peak usage, while stress testing reveals capacity limits and the point at which potential bottlenecks begin to emerge.
Before go-live, the following scenarios should also be assessed:
- Concurrent user load
- Batch processing
- Heavy reporting activity
- Integration traffic
- Period-end operations
- System load during backup operations
These tests should be performed not only to measure performance, but also to identify architectural weaknesses before go-live.
Further Reading
You can also check out our guide titled [ SAP Post-Implementation Handover Guide: Invisible Risks & Proven Solutions ] to maintain system performance after go-live and prevent potential operational disruptions.
Business Continuity Is Not an Add-On
For many organizations, S/4HANA sits at the center of finance, manufacturing, sales, procurement, and logistics operations. If the system becomes unavailable, the impact is not limited to a technical incident—it can bring business operations to a halt.
For this reason, the following questions should be answered at the earliest stages of a Greenfield project:
- How much downtime can the business tolerate?
- How quickly must the system be restored after a failure?
- What is the acceptable level of data loss?
- Will backup and recovery scenarios be tested?
- Is redundancy required for critical components?
- Can the system continue operating from another location in the event of a disaster?
The objective is not to implement the most comprehensive or expensive solution. It is to align infrastructure investment with the organization’s actual risk profile.
Business continuity requirements vary from one organization to another. However, the fact that these requirements have not been defined does not mean they are low.
Infrastructure That Supports Growth, Not Just Today’s Needs
A common mistake in Greenfield projects is to plan the infrastructure solely around the initial go-live scope.
Capacity that appears sufficient in the first year may quickly approach its limits as new companies are added, the number of integrations increases, data volumes grow, or analytics adoption expands.
Planning for data growth is not simply a matter of estimating the future size of the database. How long data will remain active, which data will be archived, how much space backups will require, and whether backup windows will fit within operational constraints all have a direct impact on infrastructure requirements. Sizing and data lifecycle management should therefore be considered together.
At the same time, building an oversized system to accommodate every possible future scenario is not a sound investment approach either.
The right objective should be:
Build an architecture that meets current needs, makes growth measurable, and can be expanded in a controlled manner as demand increases.
Whether the system is deployed on-premises, in a private cloud, or through a managed cloud model also affects how capacity can be increased, where responsibilities sit, and how business continuity should be designed.
In short, Greenfield infrastructure design should address not only how much capacity is required, but also how that capacity will be monitored and when it should be expanded.
Infrastructure Design Does Not End with Implementation
A well-designed infrastructure does not automatically remain well operated over the long term.
The following questions should also have clear answers after go-live:
- Who will monitor system performance?
- Which indicators will trigger capacity expansion?
- How will critical alerts be managed?
- How will backup recoverability be verified?
- Who will be responsible for updates and maintenance?
- Which teams will work together when a performance issue arises?
Infrastructure design and the operating model should therefore not be treated as separate topics. If the system implemented during the project is not measured and continuously improved after go-live, even a sound initial investment can gradually lose its value.
How Can Greenfield Infrastructure Be Planned More Effectively?
Infrastructure decisions in Greenfield projects should not be based solely on technical assumptions. Business units, application consultants, integration teams, and SAP Basis specialists should work from the same usage scenarios.
Do not limit business volume to user numbers. In a Quick Sizer exercise, total user count should be considered alongside concurrent users, hourly document volumes, batch processes, background jobs, and seasonal peaks.
Evaluate all workloads within the same picture. Fiori applications, OData services, integrations, reporting activities, and batch jobs may appear limited when considered separately. However, when they run within the same time window, they can create a significant peak load.
Create the integration map early. Knowing how many systems will be integrated is not enough. It is also necessary to determine which systems will exchange data, how frequently they will communicate, when transaction volumes will peak, how failed transactions will be reprocessed, and which connections will be activated simultaneously during go-live. This map improves the accuracy of sizing assumptions and enables more realistic load and end-to-end test scenarios.
Test with production-like scenarios. Confirming that functions work correctly in the test environment is not sufficient. Load and stress tests performed with production-like data volumes make both expected usage conditions and system capacity limits visible before go-live.
Do not treat sizing as a one-time exercise. Sizing assumptions should be reviewed whenever the project scope, user numbers, integrations, or data expectations change. After go-live, initial estimates should be validated by monitoring actual usage values.
Where Does SAP Basis Expertise Add Value to the Project?
SAP Basis expertise extends beyond system installation and technical administration.
An experienced SAP Basis team:
- Translates business requirements into technical capacity needs
- Evaluates sizing results against real usage scenarios
- Verifies compatibility across infrastructure components
- Makes risks between test and production environments visible
- Challenges performance and continuity scenarios before the project goes live
- Contributes to establishing the post-go-live monitoring and operating model
The real value lies in identifying where problems may arise during the project design phase, rather than intervening only after they occur. In other words, SAP Basis expertise enables a proactive approach.
How Should Tools Be Positioned in Infrastructure Planning?
Infrastructure planning in S/4HANA Greenfield projects is not completed through a single sizing exercise. Initial assumptions should be supported by appropriate tools, the planned infrastructure should be validated through testing, and actual usage should be monitored after go-live. This approach can be summarized in three stages: predict, validate, and monitor.
Tools such as SAP Quick Sizer help estimate expected resource requirements, while SAP HANA Hardware and Cloud Measurement Tools can be used to assess whether the planned server, storage, and network architecture meets SAP HANA requirements.
After go-live, the capacity plan should not remain a static document. Monitoring solutions such as SAP Cloud ALM can track system health, resource utilization, integrations, and performance trends, helping teams determine how closely the original assumptions match actual usage.
None of these tools can guarantee the right infrastructure decision on its own. Their real value emerges when the results are interpreted together with actual workloads, growth expectations, integrations, business continuity objectives, and the operating model.
A sound approach is to predict infrastructure needs, validate the planned environment, and monitor it throughout live operation.
Table 1. Recommended Tools for S/4HANA Greenfield Infrastructure Planning
| Stage and purpose | Recommended tool |
|---|---|
| Predict: Estimate expected capacity requirements | SAP Quick Sizer |
| Validate: Test whether the planned infrastructure meets SAP HANA requirements | SAP HANA Hardware and Cloud Measurement Tools |
| Monitor: Track performance, capacity, and system health in the production environment | SAP Cloud ALM |
Conclusion: A Strong Start, a Sustainable System
S/4HANA Greenfield projects give organizations an opportunity to redesign both their business processes and technology infrastructure. However, for this opportunity to deliver real value, infrastructure should not be viewed merely as a technical implementation task.
Sizing is an important starting point. Yet it is not sufficient on its own unless performance, business continuity, integrations, data growth, testing strategy, and the operating model are considered together.
A solid infrastructure is not necessarily the system with the highest capacity. It is one that accurately understands the workload, identifies risks in advance, and adapts to changing requirements in a controlled manner.
A strong start in an S/4HANA Greenfield project depends not only on implementing a new system, but also on comprehensively planning the conditions under which that system will operate before the project begins.
Frequently Asked Questions (FAQs)
Greenfield is an S/4HANA transformation approach in which business processes, the system landscape, and the technical architecture are redesigned from the ground up with future requirements in mind, rather than directly carrying over the existing system and its technical debt.
Sizing is the process of determining the infrastructure capacity required to support expected data volumes, transaction loads, integrations, and growth. It helps organizations select the right hardware or cloud resources, avoid unused capacity, and reduce the risk of performance bottlenecks after go-live.
Incorrect sizing can lead to system slowdowns and performance issues after go-live. It can also result in over-provisioning, where more infrastructure is purchased than the business actually needs, creating unnecessary costs. Accurate sizing supports reliable system operation from day one while helping the organization use its infrastructure budget more efficiently.
No. The total number of licensed or registered users can be misleading when considered on its own. Concurrent usage, background jobs, integration traffic, transaction intensity, and seasonal peak loads must also be included in the sizing exercise.
A test environment with significantly lower capacity or only limited synthetic data may fail to reveal bottlenecks that emerge under real workloads. For meaningful load and stress testing, the test architecture, data volume, integrations, and usage scenarios should represent production conditions as closely as practical.
No. Cloud environments, including Cloud ERP and RISE with SAP models, can make it easier to scale resources up or out. However, they do not compensate for poorly designed memory, storage I/O, network, or application-layer architecture.
Incorrect planning can still lead to service disruption, performance problems, and unexpected cloud cost overruns. Cloud flexibility supports sound infrastructure planning; it does not replace it.
The SAP Basis team helps build the project’s technical foundation. Its responsibilities may include infrastructure and architecture design, sizing validation, system installation, integration readiness, security, load testing, cutover planning, go-live support, and post-go-live operations.