Lesson 2 of 5
Shell conversion
10 min
A shell conversion starts from the system you already have. You make a copy of production that contains the ABAP repository and the configuration, but no master data and no transaction data. That empty "shell" is converted to SAP S/4HANA with the normal system-conversion tooling. Business data is then moved into it selectively. SAP Learning positions shell conversion as the better option when most of the original processes are being reused.
- Copy production as a shellRepository and customizing only; no master or transaction data
- Clean up the shellRemove obsolete custom code and configuration you do not want to carry
- Convert the shellRun the system conversion (Software Update Manager), handle simplification items, adapt custom code
- Build on the converted shellNew S/4HANA design work, fixes and retrofitted production changes
- Transfer data selectivelyMaster data, open items and any time slice, in repeated test cycles
- CutoverFinal selective transfer into production
Why an empty shell helps
Converting a system without its business data is faster and simpler than a full conversion: there is no data to convert during the technical run, so the conversion itself is quick to repeat, and data-related conversion problems are pushed into the selective transfer where they can be filtered. You still get the main benefit of a conversion: your proven configuration and custom code come across, adapted to SAP S/4HANA, without being rebuilt.
What you do not get is a clean slate. Whatever configuration and custom code the shell carried comes along unless you remove it. A shell conversion is a good moment to retire unused custom objects and obsolete configuration, but it does not do that by itself.
The work a conversion always brings
Because the shell goes through a real system conversion, every conversion task applies: checking the simplification items that affect your scope, adapting custom code to the SAP S/4HANA data model, converting customers and suppliers to business partners, and adapting finance to the universal journal. These are not optional extras; they are the reason the shell is not "free".
| Conversion task | What it means for the shell | Contoso example |
|---|---|---|
| Simplification items | Functions changed or removed in SAP S/4HANA must be checked against the shell's configuration | Old credit management settings need the new credit management design |
| Custom code adaptation | Custom programs reading old tables must be adapted | A custom fleet rebate report that reads old sales tables |
| Business partner | Customer and supplier configuration must be mapped to business partner settings | Number ranges and groupings for Great Lakes Fleet Services and Lakeside Components |
| Finance | Ledgers, accounts and asset accounting settings adapted to the universal journal | Leading ledger 0L and non-leading ledger 2L set up for US GAAP and IFRS |
Typical conversion work on a shell. Your own list comes from SAP Readiness Check and the simplification item check.
The double maintenance problem
The shell is a snapshot of production on the day it was copied. Production keeps changing after that: support fixes, small enhancements, new pricing. Every one of those changes must also be applied to the new landscape, or it will be lost at go-live. This is called retrofit or double maintenance, and it lasts from the shell copy until cutover. The longer the project, the bigger the retrofit list.
- Month 0Shell copiedProduction configuration and code frozen into the shell
- Months 1–3Shell convertedConversion run and adaptation; production keeps changing
- Months 3–10Build and retrofitEach production change is logged and rebuilt in the new development system
- Months 6–11Data transfer cyclesSelective transfers tested; retrofitted changes included in regression
- Month 12CutoverRetrofit list must be empty, or each open item accepted as a known gap
What would you do?
Imagine Contoso had chosen a shell conversion. Four months after the shell copy, finance changed the tax determination in ECC production to handle a new state rule. What should happen?
- Will most of today's processes and configuration be reused?Yes → shell conversion is a candidate · No → look at mix and match or a new implementation
- Is the existing configuration clean enough to carry forward?Yes → proceed · No → plan cleanup of the shell first, or prefer mix and match
- Can the program absorb months of double maintenance?Yes → set up retrofit governance · No → shorten the timeline or reconsider the path
- A shell is a copy of production with repository and configuration but no master or transaction data.
- The shell is converted with normal system-conversion tooling, so simplification items and custom code adaptation still apply.
- Business data is moved in afterwards, selectively and in repeated cycles.
- Production changes after the shell copy must be retrofitted and retested until cutover.
Check your understanding · not graded
Lesson check
1. What does a shell copy contain?
2. When is shell conversion the better fit, according to SAP Learning?
3. Why does a shell conversion create double maintenance?
4. Which task still applies to a shell even though it has no business data?