SAP ECC-to-S/4HANA Parallel Landscape Licensing: How to Avoid Paying for Both Systems During Migration

What Is a Parallel Landscape?

A parallel landscape is the practice of running two SAP environments simultaneously during a system migration—typically SAP ECC (the legacy system) and SAP S/4HANA (the target system) running side-by-side. This is not optional. It is the industry standard approach to de-risking major ERP transitions.

Why is this necessary? Because SAP migrations are not simple data transfers. They involve complex business process redesign, extensive data validation, user training in a new system, and comprehensive testing across all critical workflows. The parallel landscape provides a safety net: your ECC system remains in production while S/4HANA is validated in a production-equivalent environment.

A typical parallel landscape includes:

• Development environments on both systems for configuration and customization testing
• Quality assurance systems for regression testing, data validation, and process verification
• Pre-production or staging systems that mirror production exactly for final cutover rehearsal
• Production systems running in parallel for the duration of the migration

The duration of a parallel landscape varies based on complexity, scope, and organizational readiness. Most enterprises operate parallel landscapes for 12 to 36 months—sometimes longer in highly complex environments. The longer your parallel period, the higher your licensing exposure.

SAP's Default Position: Pay for Both

Here is the core problem: SAP's licensing model does not automatically account for transitional states. Under SAP's standard terms, every system that is production-equivalent—regardless of whether it is truly needed for business operations—must be fully licensed. If you are running ECC in production and S/4HANA in a production-equivalent configuration during migration, SAP's position is simple: you owe licensing fees for both systems.

This means:

• Named users must be licensed on both systems if they access both during the migration period. That person with a Named User licence in ECC now requires another Named User licence in S/4HANA—even though they are using the same licence in practical terms.
• Processor licensing is measured on both systems. If you have USMM (Utilization Sizing Management Measurement) engagement or have deployed SAP on multiple processor cores, SAP will count usage on both systems separately. Your licensing bill scales accordingly.
• Indirect access rules apply to both systems. If an external party or system accesses your ECC data during the parallel period, and then also accesses S/4HANA, you may owe indirect access licensing on both systems.
• Annual support costs double. Not only do you pay licensing for both systems, but you also pay annual support for both. This often exceeds the licence cost itself over a 24-month period.

SAP's sales team will position this as "normal" and "expected." It is not. Industry surveys show that enterprises without negotiated parallel landscape relief often pay between 1.5x and 2x their annual ECC licensing cost during the migration period—covering costs for the legacy system plus the new system running simultaneously.

We have seen back-licence claims from SAP exceeding $5 million for parallel landscape configurations that were not addressed in the original contract.

The Parallel Landscape Agreement (PLA) Explained

A Parallel Landscape Agreement (PLA) is a contractual carve-out that allows you to operate two systems simultaneously without triggering double licensing costs. It is not an automatic entitlement—it must be negotiated and documented in your SAP contract before migration begins.

Here is what a PLA does:

• Limits the scope of systems covered. A PLA defines which systems are included (e.g., production ECC and production S/4HANA), and specifies that development and QA systems are excluded or handled separately.
• Sets a time window for dual operation. The PLA specifies a defined period—typically 12, 18, or 24 months—during which both systems can run without additional licensing fees.
• Clarifies user licensing rules. A well-negotiated PLA will specify that a Named User licensed in ECC does not require a second Named User licence in S/4HANA during the parallel period, or that the organization pays a fixed fee rather than incremental licensing.
• Addresses measurement during parallel operation. The PLA clarifies that USMM measurements, processor licensing, or indirect access licensing will be calculated based on the higher of the two systems, not the sum.
• Provides extension options. Most PLAs include the ability to extend the parallel period by an additional 3–6 months at a pre-negotiated cost or at no additional charge, provided reasonable progress toward cutover is being made.

SAP does offer PLAs. The problem is that they are only offered to customers who explicitly ask for them. They do not appear in SAP's standard order forms, and they will not be proactively offered during contract negotiation. This is deliberate.

Negotiating Your PLA: Terms That Matter

A Parallel Landscape Agreement is only as strong as its language. Generic PLAs are common—and often leave critical gaps. Here are the terms that matter most when negotiating your PLA.

1. Start Early—Before You Sign the S/4HANA Contract

This cannot be overstated. PLAs must be negotiated as part of your initial S/4HANA software order, not as an afterthought or amendment later. Once you have signed an S/4HANA order without PLA language, you have surrendered your negotiating leverage. SAP will not voluntarily offer retroactive relief.

2. Define System Scope Precisely

Your PLA must specify exactly which systems are covered. Too many PLAs use vague language like "production-equivalent systems." This creates ambiguity. SAP's definition of "production-equivalent" often includes systems that enterprises consider QA or pre-production. Be specific:

• Which production system(s) are covered? (List by SID or technical identifier)
• Are QA systems covered separately, or at reduced licensing rates?
• What about pre-production or staging systems used for cutover rehearsal?
• If you have multiple instances of S/4HANA (e.g., pilot + main), are both covered under the PLA?

3. Negotiate Duration with Built-In Extension Rights

Most SAP migrations take longer than originally planned. We recommend negotiating for a minimum of 24 months of parallel landscape coverage, with an option to extend by an additional 6–12 months without triggering additional licensing. The extension clause should not require SAP's approval—it should be automatic if reasonable cutover progress is being made.

4. Clarify User Licensing Rules

The most common gotcha in PLAs is how named users are counted during the parallel period. Your PLA must address this explicitly. Three approaches are common:

• Single licence model: A named user licensed in ECC does not require a second licence in S/4HANA during the parallel period. This is the fairest approach and what you should push for.
• Reduced-cost concurrent access: Users can access both systems, but pay a reduced licensing fee (e.g., 25% of the normal S/4HANA licence cost) rather than the full incremental cost.
• Fixed bridge fee: The organization pays a fixed amount (e.g., 10–15% of the S/4HANA licence cost) for concurrent access to both systems during the parallel period, regardless of actual user migration.

Push hard for the single-licence model. This is defensible and protects you from mid-migration surprises as your user base shifts from ECC to S/4HANA.

5. Address USMM and Processor Licensing

If you are subject to USMM measurement or have negotiated processor-based licensing, your PLA must specify how these are calculated during parallel operation. The agreement should state that measurements will count the higher of the two systems, not the sum. For example, if your ECC system measures 300 users and your S/4HANA system measures 250 users during the parallel period, your licensing obligation should be based on 300, not 550.

6. Indirect Access Carve-Out

If third parties or external systems access your ECC data during migration (e.g., via API calls to external systems, EDI feeds, or vendor portals), you may face indirect access licensing obligations on both systems. Your PLA should explicitly state that indirect access triggered during the parallel period will be measured once across both systems, not separately on each.

Common Mistakes Enterprises Make

We have reviewed hundreds of SAP contracts covering S/4HANA migrations. The same mistakes appear repeatedly. Avoid these traps:

Mistake #1: Assuming the S/4HANA Contract Automatically Covers Transitional ECC Use

It does not. The S/4HANA contract covers S/4HANA. ECC licensing remains separate and typically requires its own maintenance agreement. If the PLA is not explicitly documented in the S/4HANA order, you do not have one.

Mistake #2: Not Defining "Production Equivalent" Carefully

SAP auditors have a much more expansive definition of "production equivalent" than most enterprises do. What you call a "QA system used for testing" may be classified by SAP as a "production-equivalent system" subject to full licensing. Build explicit system definitions into your PLA.

Mistake #3: Underestimating Migration Duration

SAP migrations routinely run 18–36 months from kickoff to full cutover. If your PLA only covers 12 months, you will face licensing gaps. Build in buffer time and ensure extension rights are automatic, not discretionary.

Mistake #4: Not Getting PLA Terms in the Order Form

Verbal commitments from SAP account teams are worthless. Once new SAP leadership takes over your account, verbal promises evaporate. PLA terms must be in the Order Form, Schedule A, or explicitly referenced terms and conditions. If it is not in writing, it does not exist.

Mistake #5: Failing to Address Support and Infrastructure Costs

Many PLAs focus on licensing but ignore annual support fees, which can be just as expensive. Your PLA should also address whether you pay support for ECC during the parallel period or whether that obligation is suspended. Similarly, if you are migrating to RISE with SAP (cloud-based), clarify whether you pay dual infrastructure costs or whether RISE support includes bridging costs for parallel ECC operation.

How Long Should a Parallel Landscape Last?

The duration of your parallel landscape depends on your migration approach, not on SAP's timeline.

Brownfield Migrations (Converting Existing ECC to S/4HANA)

Brownfield migrations—where you convert your existing ECC installation to S/4HANA—typically run 18–24 months in parallel. These migrations are generally lower-risk because you are not redesigning your entire ERP system; you are modernizing the technical foundation. However, the parallel period can be lengthy because business process changes are often substantial.

Greenfield Implementations (Building New S/4HANA Alongside ECC)

Greenfield migrations—where you build an entirely new S/4HANA system independently of your ECC system—can sometimes be shorter: 12–18 months. However, greenfield projects often run longer in practice because the scope is broader. New processes must be built, validated, and adopted by a user base accustomed to ECC. Cutover complexity is high.

Selective Data Migration and Hybrid Approaches

The most complex scenarios involve selective migration of specific modules or business units while others remain on ECC. These hybrid approaches often require the longest parallel landscapes—24–36 months or longer—because data synchronization across both systems is complex and ongoing.

RISE with SAP Migrations

If you are migrating to RISE with SAP (SAP's cloud offering), you are managing two migrations simultaneously: infrastructure migration to the cloud plus the ECC-to-S/4HANA conversion. This complexity typically adds 6–12 months to the parallel period compared to on-premise migrations.

Industry Benchmark

Our experience across 40+ enterprise migrations shows the median parallel landscape duration is 22 months. We recommend budgeting for 24 months minimum with a 6-month extension option. This avoids the compressed timeline scenarios where rushed cutover decisions increase project risk.

Brownfield vs Greenfield: Different Licensing Risks

The migration approach you choose dramatically affects your parallel landscape licensing exposure. These approaches have different risk profiles.

Brownfield: Converting Existing ECC to S/4HANA

In brownfield migrations, you take your existing ECC system and convert it to S/4HANA using SAP's conversion tools. The business processes remain largely intact, as do your data structures and configurations.

Licensing advantage: Your user base, processor count, and indirect access requirements remain relatively stable. If you had 500 named users in ECC and 500 in S/4HANA post-cutover, your licensing obligation during the parallel period is straightforward—you manage a parallel landscape with similar licensing footprints.

Licensing risk: The parallel period can be lengthy (18–24 months or more) because business process validation is extensive. You are testing not just the new system, but also verifying that ECC-to-S/4HANA conversion has not broken existing workflows.

Greenfield: Building New S/4HANA Independently

In greenfield migrations, you build an entirely new S/4HANA system from scratch with redesigned business processes, new data structures, and often a simplified configuration.

Licensing advantage: Greenfield migrations often have shorter parallel periods (12–18 months) because you are not constrained by legacy ECC configurations. Once S/4HANA is built and validated, cutover can occur faster.

Licensing risk: Greenfield projects often involve selective data migration—moving data from ECC to S/4HANA in phases. During this hybrid period, you may need to maintain both systems with different user bases, different processor requirements, and complex indirect access rules. This complexity can actually lengthen the parallel period despite the simpler system design.

Selective or Hybrid Approaches

The highest-risk scenario is selective migration where some business units remain on ECC while others migrate to S/4HANA. These "hub-and-spoke" or "dual-system" models often require the longest parallel landscapes (24–36 months or more) because data synchronization is ongoing and complex.

What to Demand in Writing

A Parallel Landscape Agreement is only as strong as its language. Here is the specific contract language you should demand in your SAP Order Form or Terms and Conditions Schedule:

Core PLA Language

Must include: A clear definition of the parallel landscape period (start and end dates), the systems covered, and explicit statement that both systems can operate without triggering additional licensing fees during this period. Example language:

• "During the Parallel Landscape Period of [DATE] to [DATE], Customer may operate SAP ECC system [SID: XXXX] and SAP S/4HANA system [SID: YYYY] simultaneously without incurring additional licence fees or Named User licence requirements beyond those established for the primary production system."

User Licensing Scope

Must include: Clear rules for how Named Users and concurrent users are licensed during the parallel period. Push for single-licence language or fixed-fee concurrent access. Avoid vague language like "users may access both systems."

• "Named Users licensed for SAP ECC do not require separate Named User licences for SAP S/4HANA during the Parallel Landscape Period. Upon cutover, Customer shall consolidate user bases on S/4HANA, and ECC user licences shall be suspended at the end of the parallel period."

System Scope Definition

Must include: Explicit list of systems covered by the PLA (by SID), and clarification about development, QA, and pre-production systems. Be specific about what is and is not covered.

• "The Parallel Landscape Agreement covers production systems only: SAP ECC [SID] and SAP S/4HANA [SID]. Non-production systems (development, QA, pre-production) are licensed separately under standard SAP licensing terms."

Measurement and USMM Rules

Must include: Language that specifies measurement is calculated on the higher of the two systems during the parallel period, not the sum.

• "During the Parallel Landscape Period, all sizing and USMM measurements shall be calculated based on the maximum monthly measurement across both systems, not the combined measurement. Named User counts shall be based on the larger user population (ECC or S/4HANA), not the sum of both."

Extension Rights

Must include: Automatic extension options without requiring SAP approval. Build in at least one 6-month extension with no additional licensing fees.

• "The Parallel Landscape Period may be extended by mutual written agreement for periods of up to 6 months at no additional licence cost, provided Customer is making reasonable progress toward S/4HANA cutover. Customer shall provide notice of extension intent no later than 60 days prior to the scheduled end of the Parallel Landscape Period."

Indirect Access Carve-Out

Must include: Explicit language that indirect access is not duplicated across both systems during the parallel period.

• "Indirect Access licensing obligations incurred during the Parallel Landscape Period shall be calculated once across both systems combined, not separately for each system."

Support and Maintenance Clarification

Must include: Clear statement about whether you pay support for both systems or if support obligations are modified during the parallel period.

• "Annual Software Support and Maintenance fees for SAP ECC are suspended during the Parallel Landscape Period and resume only if the customer maintains ECC in production beyond the defined parallel landscape end date."

Termination and Post-Cutover Rules

Must include: Clear language about what happens at the end of the parallel period. When is ECC licensing obligation terminated? What happens if you miss the cutover date?

• "Upon cutover to S/4HANA at the end of the Parallel Landscape Period, all SAP ECC licences and support obligations shall terminate immediately. If cutover is delayed beyond the parallel landscape end date, Standard SAP licensing terms shall apply to ECC, and customer shall be responsible for additional licensing fees."