What breaks when SAP data is not classified before migration to S/4HANA?

Why This Matters for Security Teams

Migration teams often assume the technical lift to S/4HANA is the main risk, when the real failure starts earlier: data that has not been classified cannot be scoped, retained, archived, or validated with confidence. That creates a chain reaction across cutover planning, testing, performance, and compliance. NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that data handling and retention decisions must be deliberate, not implied by the migration schedule.

For SAP environments, this is not abstract. Unclassified records can include operational data, historical data, regulated data, and obsolete records that should not all be treated the same way. When those categories are blended, teams migrate too much, test the wrong datasets, and miss legal hold or retention obligations. NHIMG has documented how poor credential and identity governance creates similar hidden exposure patterns in enterprise systems, including the Ultimate Guide to NHIs and the SAP Breach.

In practice, many security teams discover classification gaps only after the migration plan has already turned into a data cleanup exercise rather than through intentional scope design.

How It Works in Practice

Before migration, classification gives each SAP data domain a purpose: keep, transform, archive, or retire. That matters because S/4HANA projects are not only about moving tables. They are about deciding which business objects, transactional histories, master records, and attachments still justify operational residence. Without classification, migration factories tend to default to bulk movement, which inflates project scope and increases the chance of carrying forward stale or sensitive data.

A practical classification workflow usually starts with inventory, then applies business and compliance tags, and finally maps each class to an action. Current guidance suggests aligning that work with data owners, not only infrastructure owners, because business context determines whether a record is active, reportable, or disposable. The NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because retention, access, and protection requirements should be tied to the data lifecycle.

• Classify by business function first, then by sensitivity and retention class.
• Separate operational tables from historical archives before estimating migration volume.
• Validate legal hold, tax, HR, and regional retention obligations before transport.
• Use classification to decide whether a dataset is migrated, transformed, archived, or deleted.
• Test cutover scenarios with representative data classes, not a generic full copy.

For SAP-specific risk patterns, NHIMG’s SAP SQL Anywhere Monitor Hardcoded Credentials analysis shows how hidden assumptions inside SAP-adjacent systems create exposure when asset and data ownership are unclear. These controls tend to break down when legacy ECC landscapes contain years of duplicated objects, inconsistent custom tables, and weak ownership mapping because classification cannot be trusted at scale.

Common Variations and Edge Cases

Tighter classification often increases upfront governance effort, requiring organisations to balance migration speed against cleanup accuracy. That tradeoff is real, especially when business units want quick cutover and IT wants minimal disruption. Best practice is evolving, but there is no universal standard for classification depth across every SAP program.

Some environments can use coarse classification for low-risk datasets, while regulated industries usually need much finer granularity. Archived finance data, HR records, customer master data, and custom development tables may each need different treatment. If the business lacks reliable owners for older records, teams may need a temporary classification model based on system of record, age, and regulatory sensitivity, then refine it after the first wave.

Another edge case is selective data transition. In those projects, classification becomes even more important because the migration is intentionally partial. A poor taxonomy can cause teams to exclude critical reference data or retain obsolete history that slows performance and complicates audits. NHIMG’s SAP Breach material is a reminder that SAP risk often emerges where hidden assumptions about ownership, scope, and access were never documented. When classification is skipped, the result is usually not just a messier migration, but a weaker post-go-live control model.

Related resources from NHI Mgmt Group

• What breaks when migration planning does not account for data mapping and access controls in SAP transformation projects?
• What breaks when cloud migration starts before data discovery?
• What breaks when child accounts are populated manually instead of using controlled vault migration processes?
• What breaks when coding agents cannot inspect real traces before changing prompts or evaluators?