System landscape optimization is the disciplined reshaping of applications, data and integrations to support a target business and technology operating model. It can include consolidation, carve-out, migration, harmonization and retirement. SAP data archiving may be an important lever, but it is not a synonym for the whole transformation.

The initials “SLO” are used inconsistently in the market. They may refer broadly to system landscape optimization, to consulting practices or to particular service histories. Treating the acronym as one universally defined SAP product creates unnecessary ambiguity. The useful question is not “Are we doing SLO?” but “What landscape outcome are we pursuing, which data must move or remain accessible, and how will we prove the result?”

Start with the target landscape, not a tool

A landscape program should begin with a factual current-state map and a clear target state. The map includes productive and non-productive systems, clients, company codes, organizational structures, interfaces, batch flows, identity dependencies, reporting platforms, archives, document repositories and systems of record. It also identifies business owners, technical owners, contractual limits and regulatory obligations.

The target may be a consolidated SAP environment, a separated business for a divestiture, a move to SAP S/4HANA, or the shutdown of redundant applications. SAP’s Data Management and Landscape Transformation material describes consolidation and harmonization as transferring essential business objects while preserving integrity and continuity. That is wider than moving tables: business meaning and process continuity have to survive.

Common transformation paths

  • Consolidation: combine systems or clients into a smaller target estate, often with harmonized master data, organizational structures and process rules.
  • Carve-out: separate the agreed data and operations for a company, business unit or function into a new environment. SAP’s own carve-out documentation highlights release, add-on, support-package and table-scope prerequisites; deletion from the source can be a separate activity.
  • Migration: transfer data and processes to a target platform. For an SAP S/4HANA transformation, the chosen transition approach determines how much history, configuration and process redesign travel together.
  • Retirement: preserve approved historical information and access, close dependencies and shut down the source. See the application-retirement framework.
  • M&A restructuring: combine consolidation and separation under contractual deadlines, transitional-service agreements and strict data-access boundaries. The M&A data-transition overview covers this business context.

These paths often coexist. A program may carve out one company, migrate active operations to SAP S/4HANA, archive closed transactions and retire two legacy systems. Each stream needs its own scope and acceptance criteria, coordinated through one dependency plan.

Choose the data scope deliberately

“Move all the data” is rarely a complete requirement. Scope should distinguish active transactions, open items, historical transactions, master data, configuration, custom tables, attachments, print lists, change history, workflow evidence and analytics. It should also define the organizational and temporal selection rules: for example, company codes, plants, personnel areas, fiscal periods and status conditions.

Data dependencies are decisive. An invoice may depend on a customer, sales order, delivery, pricing conditions, accounting documents and attachments. A selection that looks valid table by table can become unusable when those relationships are broken. Teams therefore need object-level dependency analysis, referential checks and explicit treatment of shared master data.

Archiving can reduce the live database footprint by moving completed business data that must remain available. SAP explains that its data-archiving concept is based primarily on archiving objects, while SAP Information Lifecycle Management adds rule-based storage, retention, blocking and destruction capabilities. The SAP data archiving guide explains these mechanisms and their boundaries.

Sequence decisions before execution

The order of operations changes risk, downtime and rework. Decide early whether archiving happens before or after migration; whether a carve-out target is created before harmonization; when interfaces switch; when source posting stops; and when historical reporting becomes authoritative. There is no universal sequence, but every sequence should account for reconciliation points and a controlled fallback.

  1. Define the business outcome. Agree the future operating model, users, reporting needs, service levels and decision owners.
  2. Baseline the estate. Measure systems, volumes, growth, data ages, custom objects, interfaces and operational costs.
  3. Classify data. Decide what migrates, remains temporarily, is archived, is preserved for retirement, or is eligible for defensible disposal.
  4. Design dependencies and waves. Group tightly coupled processes and systems, then define cutover and rollback boundaries.
  5. Rehearse and reconcile. Run representative conversions or extracts, measure exceptions and test the business use cases.
  6. Authorize transition. Move only when technical, business, security and records-management gates are satisfied.

Validation must prove more than record counts

Technical validation should compare agreed record populations, control totals, balances, date ranges, documents, relationships and rejected records between source and target. It also needs to cover custom developments, interfaces, authorizations, scheduled jobs and performance. The exact controls vary: financial data may require ledger and document reconciliation, while an HCM carve-out may require continuity checks for payroll-relevant histories and organizational assignments.

Business validation is a separate gate. Named users should execute representative end-to-end activities in the target state: process an open item, research a historical order, answer an audit request or retrieve a retained attachment. Exceptions, workarounds and accepted limitations belong in the evidence pack. A technically successful transfer does not by itself establish operational readiness.

Governance across the landscape

A cross-functional design authority should own scope and sequence decisions. Business process owners define continuity; data owners approve meaning and quality; architecture controls the target landscape; security and privacy teams govern access; records and legal specialists approve retention requirements; and operations accepts the support model. A steering group should resolve trade-offs that cross systems rather than allowing each workstream to optimize locally.

Useful governance artefacts include a system and interface inventory, data disposition matrix, dependency map, transformation rules, reconciliation catalogue, cutover plan, decision log, exception register, retention approvals and shutdown certificate. Start with an application and data assessment when these facts are incomplete.

What a good operating state looks like

Optimization is complete only when the new landscape operates predictably. The desired outcomes are fewer redundant systems and interfaces; controlled database growth; clear system-of-record ownership; fit-for-purpose historical access; enforceable retention and destruction rules; monitored jobs and integrations; and support teams that understand the new boundaries.

For systems that can be retired, SAP ILM supports decommissioning scenarios in which retained data remains available after the original system is shut down. SAP describes a retention warehouse approach for bringing data from SAP and third-party legacy systems into a central environment with reporting and policy controls. Whether that pattern fits depends on source technology, licensing, retention requirements and the required user experience.

Measure outcomes after cutover: systems actually switched off, infrastructure and licences removed, interface count, database growth, incident levels, reporting availability, reconciliation exceptions and operating cost. Benefits should be demonstrated rather than inferred from a completed migration.

System landscape optimization is therefore a portfolio and operating-model discipline. Archiving can make a migration smaller, control growth or preserve information for shutdown, but value comes from coordinating data scope, dependencies, transformation sequencing, validation and governance around an explicit target state.

Official SAP references