Shell conversion in RISE with SAP: Keep the benefits of Brownfield without carrying everything forward
Brownfield feels like the safest path to SAP S/4HANA. But what happens when everything moves forward, including what no longer adds value?
Share
Key takeaways
- Brownfield is fast and low-risk, which is why many teams choose it
- But it moves everything into the new system, including what no longer adds value
- That increases complexity without improving how the system works
- Shell conversion in RISE with SAP keeps the same low-risk approach
Why Brownfield is often the first choice for the RISE with SAP journey
If you are planning a move to SAP S/4HANA, the Brownfield approach often feels like the most straightforward option. You take your existing system and move it into the new environment as a “lift-and-shift,” without changing how your business runs.
Keeping processes, structures, and ways of working intact while transitioning to SAP S/4HANA is precisely what many teams are looking for.
This approach is often associated with:
- Faster implementation compared to redesign approaches
- Lower immediate project risk
- Minimal disruption to your operations
- Limited need for change management across your teams
That is why Brownfield is often seen as the default SAP S/4HANA migration approach. It allows your business to keep running while the system changes in the background.
At this stage, the priority is clear. You want to move to SAP S/4HANA safely, without introducing unnecessary complexity into the project itself.
What happens when everything moves forward in a Brownfield migration?
A Brownfield migration moves your system as it is. That includes more than just what your teams use today. Over time, most SAP systems accumulate elements that are no longer relevant. Processes evolve. Structures change. Some parts of the system are simply no longer needed. When everything is carried into SAP S/4HANA, that history moves with it.
This typically means:
- Legacy processes remain in place, even if they are no longer efficient
- Older design decisions continue to shape how your system works
- Unused or redundant elements are still part of the system
- The overall complexity stays the same, just in a new environment
None of this creates immediate disruption. Your system behaves as expected after the go-live.
But the impact becomes visible later.
Your new SAP S/4HANA environment reflects the same structures and limitations you had before. Opportunities to simplify are harder to realize once everything is already in place. In that sense, the migration was successful. But the system itself has not moved forward in the same way your business has.
The moment most teams start questioning their SAP migration approach
Brownfield conversion earns its place. The migration path is well-defined, the system continuity is preserved, and the business keeps running. For teams prioritizing speed and stability, that predictability has real value. But as the scope becomes clearer, the trade-off starts to show. More data means more to validate. More processes mean more to test. What looked simple at the start begins to expand in effort.
At the same time, teams often discover that parts of the system are no longer actively used. Some custom code supports processes that have changed. Some structures remain in place simply because they were never removed. It’s at this point where teams like yours start taking a closer look.
If the goal is to move to SAP S/4HANA without disruption, carrying everything forward makes sense. But if the goal also includes reducing complexity, the approach starts to feel less aligned. That creates a simple but important question:
Do you need to move everything, or just what your business actually uses?
Shell conversion: The more deliberate SAP S/4HANA conversion strategy
Shell conversion follows the same objective as a Brownfield SAP S/4HANA migration. You move to the new system in a controlled way, without disrupting your business or redesigning everything from scratch.
In a standard Brownfield conversion, the existing system is technically converted to SAP S/4HANA in place. The system’s configuration, custom developments, and business data remain part of the converted environment by default.
Shell conversion introduces an additional separation step before the productive system is established. First, a structural copy of the existing SAP ERP system is created – the shell. This environment contains the organizational structures, configuration, and repository objects required for the system to run, but it does not initially include the full set of historical business data.
Business data, custom code, and other system elements are then evaluated and selectively transferred into the new S/4HANA system based on defined criteria. This allows teams to bring forward the structures and data that still support current operations while leaving behind elements that are no longer required.
That means:
- Your business continues to operate without interruption
- Your teams work within familiar structures
- Your migration stays predictable in terms of scope and timeline
At the same time, your new SAP S/4HANA system starts in a cleaner state. Shell conversion does not turn the project into a redesign. It keeps the stability of a Brownfield approach while introducing a more deliberate way to shape what your future system looks like.
Brownfield vs. shell conversion: Key differences
| Brownfield | Brownfield with shell conversion | |
| System scope | Full system is converted in place | System structures are replicated; only selected data and elements are transferred |
| Data footprint | All historical and current business data moves to the new system | Data can be filtered so only relevant historical and active data is migrated |
| Custom code and configuration | Existing developments and configuration remain by default | Unused or obsolete elements can be excluded |
| Testing and validation effort | Larger system footprint increases the testing scope | Reduced scope lowers the validation and testing effort |
| Resulting system state | System reflects historical structures and design decisions | System starts with a more streamlined baseline |
When you move only what supports your business today, your SAP S/4HANA environment starts from a more focused baseline. Your teams are not working around structures that no longer apply.
None of this requires a full redesign. It comes from making a few deliberate decisions during the migration itself, as shown in projects like BSW Timber’s S/4HANA transformation.
Your selective SAP S/4HANA migration checklist: Questions to decide what moves forward
You don’t need to rethink your entire system to take a more selective approach. It often starts with a few practical questions.
☐ Which parts of your system are still actively used by your business today?
☐ Which processes reflect how your teams actually work today?
☐ Which processes exist mainly for historical reasons?
☐ Which data needs to remain operational after the go-live?
☐ Which records are only required for reporting or compliance?
☐ Where does unnecessary complexity come from in your current system?
☐ What would your SAP S/4HANA landscape look like if you only moved what adds value?
Once you start working through these questions, the next step becomes clearer. You define what needs to move, what should remain accessible, and what no longer has to be part of your system.
A broader comparison of Greenfield, Brownfield, and Bluefield approaches can help you put these decisions into context.
Stability should not mean standing still
A Brownfield SAP S/4HANA migration gives you stability. That is why many teams choose it. But stability alone does not change how your system supports your business. If everything moves forward as it is, your new environment reflects the same structures, constraints, and complexity you had before.
Shell conversion keeps that stability. Your business continues to run. Your migration stays controlled and predictable while giving you a clear decision point. You decide what supports your operations today and what does not need to be part of your future system.
If you are planning your RISE with SAP journey, three practical next steps can help you move forward:
- Review which processes and data your teams actively use today
- Identify where unnecessary system complexity is coming from
- Define what needs to move into SAP S/4HANA and what can remain outside the operational system
You still move to SAP S/4HANA with confidence. But you also ensure that your system moves forward with your business.
If you are currently working through these decisions, you can get in touch with our team to explore how a more selective approach fits your RISE with SAP initiative.