SAP Security Hardening: The 10 Most Important Measures for 2026
Practical guide: 10 concrete measures to protect your SAP systems against current threats.
Read more →
The decision for S/4HANA has been made. Now the real work begins – and most problems don’t arise during the migration but because critical questions weren’t clarified beforehand. This checklist is aimed at Basis teams and technical project managers who want to properly prepare an S/4HANA migration.
Before you plan anything: do you have a current, complete documentation of your system landscape? This sounds obvious but rarely is. Record all systems (production, QA, dev, sandbox), their versions, database types, OS versions and dependencies. Interfaces, RFC connections, ALE scenarios – everything must be on the table.
SAP’s Readiness Check is your first port of call. It shows you simplification items, custom code adjustment needs, Fiori app recommendations and business function dependencies. Run it early – not once the project is already underway.
The Custom Code Migration Worklist Tool (ABAP Test Cockpit) shows you which custom code needs to be adapted. Experience shows: in typical ECC systems, 15–30% of custom code is affected. Sort by criticality: what is actively used? What can be deleted?
HANA has different sizing requirements than any previous SAP database. Use the SAP Quick Sizer and the HANA Sizing Report (transaction /SDF/HDB_SIZING). Note: memory for HANA is not just data volume – indexes, column store and delta merge require additional RAM.
Greenfield, brownfield or selective data transition? The decision has massive implications for effort, timeline and risk. Brownfield (system conversion) retains your history. Greenfield means rebuilding from scratch. Both have their merits – but the choice must be made consciously.
How much data are you migrating? Historical documents, archived data, legacy data? Every GB you don’t migrate saves time and cost. Define clear cutoff dates. Check whether data archiving before the migration makes sense – it reduces downtime considerably.
S/4HANA brings new transactions, new Fiori apps and new authorisation objects. Your existing role concept must be adapted. Plan this in early – not as an afterthought in the go-live week. More on this in our authorisations guide.
Use the migration as an opportunity to set up security properly from the start. SNC, encryption, gateway security, ICF services – everything that was “historically grown” in the old system should be configured according to best practice in the new system. See also: Security Hardening Guide.
Technical tests (performance, integration, regression) and functional tests (end-to-end scenarios) must be planned. Define test cases early. Automate where possible. Plan at least two complete test rounds.
The cutover plan is your script for go-live weekend. It must be precise to the minute: who does what when? What are the checkpoints? What are the abort criteria? Test the cutover at least once completely – as a dress rehearsal.
What happens if go-live fails? A documented, tested fallback plan is mandatory. Define the point of no return and the criteria that would trigger an abort.
The first 2–4 weeks after go-live are critical. Plan increased staffing, fast escalation paths and daily status meetings. Define KPIs for system stability: response times, error rates, job runtimes.
An S/4HANA migration is not purely a technical project – but without solid technical preparation, it’s guaranteed to fail. These 12 points are no guarantee of success, but they prevent the most common mistakes. If you need support with planning or implementation, talk to us.
Practical guide: 10 concrete measures to protect your SAP systems against current threats.
Read more →A step-by-step approach to bringing order to historically grown authorisations.
Read more →The most important security parameters compared across all three environments.
Read more →We help you with implementation – from analysis to go-live.
Get in touch