Landscape and deployment: editions, systems and the migration approach

#The 60-second version

Every SAP program starts with three decisions that are hard to reverse. They are made with the business, not only by IT.

1. Where the system runs and who runs it. SAP S/4HANA comes as a public cloud service that SAP runs for many customers, as a private cloud system that SAP runs for you alone, or as software you run yourself. The choice decides how much you can change the system and how often it changes under you.
2. How many systems you have, and what each is for. A change is built in one system, tested in a second and used in a third. Some companies run one system for the whole world; others run one per region.
3. How you get there from the old system. You can start fresh, convert the old system, or move selected parts of it. Each path trades speed and risk against how much of the past you keep.

This topic gives a leader the words for those decisions, what each option costs, and the questions that expose a weak plan. Calder Pumpworks, the fictional pump maker this unit follows, is the worked case: its US company CP10 already runs S/4HANA, while its German company CP20 still runs SAP ECC, the previous SAP ERP.

#Why it matters to the business

The three decisions set the program's cost, its risk and what the company can do for years afterwards.

• The edition sets the pace of change. In the public cloud edition, SAP upgrades the system twice a year on its own schedule. That brings new functions without upgrade projects, and it obliges the business to test every half year. A private or on-premise system moves when the customer plans an upgrade, within SAP's maintenance rules.
• The edition sets how far you can bend the system. The public cloud edition allows only extensions built on interfaces SAP has released. Private and on-premise systems also allow older techniques, which help in the short term and make every later upgrade dearer.
• The landscape sets how safely change happens. Without a separate test system, a mistaken setting reaches the people taking orders. With too many systems, every change waits for a queue of imports and tests.
• The migration approach sets what you keep. A fresh start lets Calder's German team adopt the US processes but leaves its closed history behind. A conversion keeps everything, including the workarounds.
• The calendar is not optional. SAP's mainstream maintenance for SAP ERP 6.0, the release behind ECC, ends on 31 December 2027 (SAP Support Portal). For Calder, which is planning in October 2026, that is 14 months away.

A concrete case: Calder's US and German companies trade impellers every month. Because they sit in two different systems, each sale needs a purchase order, a sales order and messages between them, and month-end matching finds differences every time (Intercompany and multi-company scenarios). Whether Augsburg joins Rockford's system, or gets a system of its own, decides whether that work ever goes away.

#How SAP does it

As of October 2026, SAP offers S/4HANA in three ways. The names have changed often, so check them in your contract.

• SAP S/4HANA Cloud Public Edition. Software as a service: SAP runs one code line for all customers and upgrades it twice a year, in February and August (SAP Learning). Extensions must use released interfaces only (SAP Learning). SAP's GROW with SAP subscription bundle includes it, listed under the SAP Cloud ERP heading (SAP Support Portal).
• SAP S/4HANA Cloud Private Edition. A system dedicated to one customer, run by SAP. It is sold through RISE with SAP, which SAP's training describes as a cloud subscription offering; for the private cloud, infrastructure and technical software maintenance can be outsourced under one contract (SAP Learning). Newer SAP Learning material also uses the name SAP Cloud ERP Private for the private cloud offering (SAP Learning).
• SAP S/4HANA on-premise. The customer, or a hosting partner it hires, runs the system. The current release is SAP S/4HANA 2025, first documented in October 2025 (SAP Help Portal).

For customers still on ECC, SAP offers optional extended maintenance from 2028 to the end of 2030 (SAP Support Portal). For its largest and most complex ECC customers, it has announced a paid SAP ERP, private edition, transition option for use from 2031 (SAP News). SAP's update of 13 October 2026 says these subscriptions may run until 31 December 2035, with further prerequisites (SAP News).

#A decision guide for executives

Then pick the migration approach:

SAP's training reports that across about 10,000 projects over three years, about half were new implementations, 48% were conversions and 2% were selective data transitions (SAP Learning).

Calder's case. CP10 runs S/4HANA Cloud Private Edition (in the course story). For CP20, Calder has four options: add the German company to the US system as a new implementation of its company code; convert the ECC system into a second S/4HANA system; move CP20's data selectively into the US system; or give Augsburg a new public cloud system. The deep layer scores them; the recommendation is the first, because one system removes the intercompany messaging and lets both companies share one controlling area.

#Questions to ask

1. Which of our processes really differ from the standard, and what do those differences earn us?
2. If we choose the public cloud edition, who tests each half-yearly upgrade, and how long does it take?
3. Under RISE with SAP, which tasks does SAP run and which stay with us? Ask for the responsibilities document.
4. How many systems and clients does the plan include, and what is each one for?
5. Where can someone change production directly, and who can approve it?
6. Which migration approach is proposed, and what happens to closed history in each one?
7. Does the plan finish before ECC mainstream maintenance ends on 31 December 2027, and what does it cost if it slips?
8. If the old system is converted, how much custom code comes along, and who reviews it?

#Common misconceptions

• "Public cloud means we can't extend anything." It allows extensions, but only on interfaces SAP has released, and many of them are built on SAP's Business Technology Platform.
• "Private cloud is the same as running it ourselves in someone else's data center." Under RISE with SAP, SAP runs the technical operations and the technical upgrades. Running SAP on a hyperscaler under your own licenses is a different arrangement with different responsibilities.
• "A system conversion is a technical upgrade." It changes data models and processes, so business testing and training are still large.
• "A new implementation means losing our data." Master data and open items are migrated. Closed history stays readable in the old system or an archive, or is moved selectively.
• "More systems make the landscape safer." Each extra system adds imports, tests and drift. Three well-kept systems usually beat five neglected ones.
• "The 2027 date means ECC stops working." Systems keep running; what ends is mainstream maintenance. Extended maintenance and the transition option cost more and buy time, not progress.

#Key terms

All course terms, A to Z, in the glossary

• Deployment option: where the system runs and who operates it: public cloud, private cloud or on-premise.
• RISE with SAP: SAP's subscription offering for the private cloud edition, bundling software, infrastructure and technical operations.
• Landscape: the set of systems behind one ERP, such as development, quality and production.
• Client: a self-contained unit inside one SAP system with its own business data and settings, identified by three digits.
• Transport: a recorded package of changes moved from one system to the next.
• New implementation, system conversion, selective data transition: the three ways to reach S/4HANA from an older ERP.
• Mainstream maintenance: the standard support period SAP includes in maintenance fees, with fixes and legal changes.

#Check yourself

#Mental model

Think of an SAP program as three layers of decisions, each one constraining the next:

1. The deployment option is the lease. It says who owns the building (SAP or you), who maintains it, and what renovations the lease allows. Public cloud is a serviced apartment: SAP repaints twice a year and you may only hang pictures on the hooks provided. Private cloud is a house SAP maintains for you, with more freedom inside. On-premise is a house you own and maintain.
2. The landscape is the floor plan. Development, quality and production are rooms with one-way doors between them. A change is made in the first room, inspected in the second and used in the third. Clients are the furniture arrangements inside each room.
3. The migration approach is the move. You can build a new house and carry only what you need (new implementation), renovate the old one in place (system conversion), or carry a chosen set of rooms into a new house (selective data transition).

If you know which lease, which floor plan and which move, you can predict most of what a program will cost, what it can customize and where it will break.

#How it works

#The three deployment options

As of October 2026, from SAP's own training and support pages:

Two notes on that table. First, the extensibility row comes from SAP's clean core training, which states that Public Edition permits no modifications of SAP objects, while private edition and on-premise also support classic extensibility where ABAP Cloud can't be used (SAP Learning). Second, the transition row: SAP's training on conversion and selective data transition names private edition and on-premise as targets (SAP Learning), while data reaches Public Edition through the SAP S/4HANA migration cockpit, including a direct transfer from an ECC system for a limited set of objects (SAP Learning). Plan a move to Public Edition as a new implementation.

#What "clean core" means for each option

SAP rates extensions by clean core level, from A to D (SAP Learning):

An extension is rated by the lowest level it uses. Level A matches how Public Edition works, so it is the only level open there. In private edition and on-premise, levels B to D are technically possible, and SAP's training says this level approach replaces the older three-tier extensibility model, which is now sunset (SAP Learning). The practical rule: every level-C or level-D extension is a cost you pay again at each upgrade. ABAP Cloud and side-by-side extensions are covered in ABAP Cloud and RAP for AI and CAP and side-by-side extensions.

#Maintenance dates that set the calendar

Check exact dates for your releases in SAP's Product Availability Matrix; the support portal points there.

#System landscape: three systems and one-way doors

In private edition and on-premise, the classic landscape is three systems: development (DEV), quality assurance (QAS) and production (PRD). The Transport Management System (TMS) moves changes between them. SAP's training sets out the rules (SAP Learning):

• A change is recorded in a transport request in development, exported to a shared transport directory, imported into quality for testing, then imported into production. Exports and imports copy, so the change ends up in all three systems.
• Transports along a route go in one direction only.
• All systems managed together form a transport domain. One system, the domain controller, holds the TMS configuration for the rest.
• A consolidation route (development to quality) carries a named transport layer; a delivery route (quality to production) is import-only.

flowchart LR
  SB[Sandbox<br/>experiments] -.-x|never exported| DEV
  DEV[Development<br/>client 100 customizing<br/>client 300 unit test] -->|consolidation route| QAS[Quality<br/>integration and<br/>acceptance tests]
  QAS -->|delivery route| PRD[Production<br/>no direct changes]

Clients divide each system. Cross-client data, such as all repository objects (programs, tables, CDS views) and some configuration, affects the whole system; client-specific data, such as business data, user master records and most configuration, affects one client. SAP's training names typical client roles: a customizing client in development, a quality test client, a production client, and a standalone sandbox from which transports should not be allowed. Its example adds a unit-test client in development and a pre-production system for volume and performance tests, and it states that every critical client should sit in its own system (SAP Learning).

In Public Edition, the shape is similar but SAP-managed (SAP Learning):

• A starter system, preconfigured with SAP Best Practices and sample data, for fit-to-standard workshops; it can be decommissioned later.
• A three-system landscape (since release 2208): a development system with a development tenant (ABAP on released objects) and a customizing tenant (configuration and key-user extensions), a test system and a production system. SAP Central Business Configuration connects only to the development system; configuration is read-only downstream, except for "current settings" kept in production.
• A two-system landscape (quality and production) is still described; SAP's page says its "Manage Your Solution" configuration option is available only for existing installations.

The difference that matters: in Public Edition, SAP upgrades every system on a schedule, so the test system is also where the business regression-tests each release.

#One instance or several

A global single instance puts every company code in one production system. A regional design runs one system per region or business. The trade-off:

At Calder, the intercompany topic showed what two instances cost: price, currency, terms and partner have to agree in two systems, and goods in transit are invisible to Rockford. Calder's size, two plants and two companies, makes one instance the natural target. A group with thirty countries and different time zones might weigh it differently.

#The three migration approaches, mechanically

New implementation. A new S/4HANA system is installed and configured. Master data and open items are loaded; closed transactions are not (SAP Learning). The main tool is the SAP S/4HANA migration cockpit, which loads data from SAP and non-SAP sources and is included in the S/4HANA license (SAP Help Portal). For Calder, a variant applies: CP20 would be a new company code rolled into an existing S/4HANA system, so the configuration is extended, not built from zero.

System conversion. The ECC system itself becomes an S/4HANA system, keeping data, configuration and custom code. The steps, from SAP's training (SAP Learning and SAP Learning):

1. Analyze. SAP Readiness Check reports affected add-ons and business functions, relevant simplification items, custom code, data volume, sizing and suggested SAP Fiori apps. Simplification item checks test which items apply and whether data is consistent enough to convert. Maintenance Planner calculates the path.
2. Prepare. Clean up custom code and reduce data volume. The system must be on Unicode, and dual-stack systems must be split first. A single-step conversion is supported from SAP ERP 6.0 enhancement packages 0 to 8, within service-pack limits SAP lists in a note (SAP Help Portal).
3. Convert. The Software Update Manager (SUM) migrates the database to SAP HANA where needed, updates the software and converts the data to the new data model. Its Database Migration Option (DMO) does these in one step and leaves the source database unchanged as a fallback.
4. Adjust. Configure mandatory simplification items, adapt custom code, test.

The sandbox conversion runs first and is repeated until clean; development, quality and production follow. The master data topic already noted that business partner conversion of customers and suppliers must be prepared before a conversion.

Selective data transition. Chosen parts of the old system are moved: repository objects, configuration, master data, and transaction data such as open items plus a time slice of closed items, for example two years. SAP's training names two approaches (SAP Learning):

• Shell conversion: copy the production system without business data, convert the empty shell, then load the selected data. Best when most processes are reused.
• Mix and match: install a new system, then bring selected configuration and code across. Best when most of the solution is redesigned.

The tooling is SAP Landscape Transformation, whose use cases include consolidating systems and moving business units. SAP advises engaging SAP's own services or specialized partners (SAP Help Portal), and its training warns that partner tools are not SAP-certified and that issues from non-SAP tools fall outside SAP Support (SAP Learning). SAP's own SAP Business Transformation Center offers a lean selective data transition to on-premise or private edition targets, with the target built by shell conversion; mix and match is not supported there (SAP Learning).

#Calder's four options for CP20

None of these is free of trade-offs. Option A depends on Augsburg accepting Rockford's processes. Option B keeps everything, including the integration cost. Option C is the most specialist work. Option D gives Augsburg standard processes, but leaves Calder with two systems and two upgrade rhythms. The walkthrough below scores them; the architecture view records the decision.

#Build it yourself

Before you start: finish Set up your computer for this course and Set up for Unit 1B. This walkthrough uses the Calder sample pack from the Unit 1B setup.

You will write one script that does three jobs a solution architect does on paper. It draws Calder's landscape as a diagram, from the company codes in the sample pack. It checks a log of transport requests against the one-way route development, quality, production, and flags the four mistakes that cause most production incidents. And it scores the four options for CP20 against weighted criteria, then compares each option's duration with the end of ECC mainstream maintenance.

flowchart LR
  P[calder_pack/<br/>org_units.json] --> S[landscape.py]
  S --> D[calder_landscape.md<br/>diagram]
  S --> T[Transport check<br/>OK / FINDING / OPEN]
  S --> M[Option scores<br/>and timeline]

#What you need

• The course folder orchestrate-course with its .venv, and the Unit 1B sample pack.
• No account, no key and no network. The script uses only Python's built-in modules, so requirements.txt doesn't change.
• Cost: free. Time: about 30 minutes.

#Step 1: Open your course folder and turn on the virtual environment

1. Open VS Code, then File > Open Folder and choose orchestrate-course.
2. Open a terminal with Terminal > New Terminal.
3. Turn on the virtual environment:

   • Windows (PowerShell):

     Copy

     .venv\Scripts\Activate.ps1

   • macOS / Linux:

     Copy

     source .venv/bin/activate

You should see (.venv) at the start of the prompt.

#Step 2: Make sure the sample pack is current

1. Rewrite the pack, so you start from the same data as this topic:

   • Windows (PowerShell):

     Copy

     python unit1b\make_calder_pack.py

   • macOS / Linux:

     Copy

     python unit1b/make_calder_pack.py

2. The last lines should read:

Calder sample pack 1.0: order 1000001, net 29,100.00 USD, cost 19,600.00 USD.
All data is fictional. Next: python check_unit1b.py

The script only needs org_units.json from the pack, which says which company code runs on which system: CP10 on S/4HANA, CP20 on ECC.

#Step 3: Create the script

1. In VS Code, create a new file, paste the script below, and save it as landscape.py inside the unit1b folder.

"""Draw Calder Pumpworks' system landscape, check its transport log and
compare the migration approaches for CP20.

Calder Pumpworks is a fictional company. System IDs, clients, transport
numbers, scores and durations below are course labels and workshop inputs,
not SAP standard values or real project figures. The script reads the Calder
sample pack (unit1b/calder_pack/) and needs no account, no key and no network.

Run it from your course folder:
  python unit1b/landscape.py                          summary and diagram
  python unit1b/landscape.py --transports             check the transport log
  python unit1b/landscape.py --decide                 score the four approaches for CP20
  python unit1b/landscape.py --decide --weight history=5
                                                      the same, with one weight changed
It writes unit1b/calder_landscape.md and changes nothing else.
"""
import argparse
import json
import sys
from datetime import date
from pathlib import Path

PACK = Path("unit1b") / "calder_pack"
DIAGRAM = Path("unit1b") / "calder_landscape.md"
RUN_DATE = date(2026, 10, 28)              # fixed so every reader gets the same output
ECC_MAINSTREAM_END = date(2027, 12, 31)    # SAP ERP 6.0 mainstream maintenance (support.sap.com)
DRIFT_DAYS = 30                            # course rule: in quality longer than this = drift

# ------------------------------------------------------------ the landscape
# One track per ERP. Each track lists its systems in transport order.
LANDSCAPE = {
    "S/4HANA": {
        "deployment": "SAP S/4HANA Cloud Private Edition, release 2023",
        "systems": [
            {"sid": "S4S", "role": "sandbox", "clients": {"100": "SAND"}},
            {"sid": "S4D", "role": "development", "clients": {"100": "CUST", "300": "unit test"}},
            {"sid": "S4Q", "role": "quality", "clients": {"100": "QTST"}},
            {"sid": "S4P", "role": "production", "clients": {"100": "PROD"}},
        ],
        "route": ["S4D", "S4Q", "S4P"],
    },
    "ECC": {
        "deployment": "SAP ECC 6.0, enhancement package 8, on-premise",
        "systems": [
            {"sid": "ECD", "role": "development", "clients": {"100": "CUST"}},
            {"sid": "ECQ", "role": "quality", "clients": {"100": "QTST"}},
            {"sid": "ECP", "role": "production", "clients": {"100": "PROD"}},
        ],
        "route": ["ECD", "ECQ", "ECP"],
    },
}

# --------------------------------------------------- the S/4HANA transport log
# Each request lists the systems it was imported into, with the date.
TRANSPORTS = [
    {"id": "S4DK900401", "text": "Credit check: new risk class", "imports": {"S4Q": "2026-09-08", "S4P": "2026-09-15"}},
    {"id": "S4DK900412", "text": "Hotfix: billing block AC text", "imports": {"S4P": "2026-10-02"}},
    {"id": "S4DK900414", "text": "Seal kit price condition", "imports": {"S4Q": "2026-10-06", "S4P": "2026-10-14"}},
    {"id": "S4DK900415", "text": "Seal kit price report (needs 900414)", "needs": "S4DK900414",
     "imports": {"S4Q": "2026-10-07", "S4P": "2026-10-09"}},
    {"id": "S4DK900418", "text": "Output form for delivery note", "imports": {"S4Q": "2026-09-02"}},
    {"id": "S4SK900007", "text": "Experiment: new MRP area", "imports": {"S4Q": "2026-10-20"}},
    {"id": "S4DK900420", "text": "Tolerance group for CP10", "imports": {"S4Q": "2026-10-26"}},
]

# ------------------------------------------- the four approaches for CP20
# Scores from Calder's (fictional) workshop: 1 = poor, 5 = good for Calder.
CRITERIA = {
    "one_instance": ("Puts CP10 and CP20 in one system", 4),
    "redesign": ("Lets Augsburg adopt CP10's processes", 3),
    "history": ("Keeps Augsburg's closed history in the new system", 2),
    "risk": ("Low cutover risk and downtime", 4),
    "cost": ("Low project cost", 3),
}
APPROACHES = [
    {"key": "A", "name": "Company code rollout into CP10's S/4HANA (new implementation)", "months": 11,
     "scores": {"one_instance": 5, "redesign": 5, "history": 2, "risk": 4, "cost": 4}},
    {"key": "B", "name": "System conversion of the ECC system to its own S/4HANA", "months": 12,
     "scores": {"one_instance": 1, "redesign": 2, "history": 5, "risk": 3, "cost": 3}},
    {"key": "C", "name": "Selective data transition into CP10's S/4HANA", "months": 14,
     "scores": {"one_instance": 5, "redesign": 4, "history": 4, "risk": 2, "cost": 2}},
    {"key": "D", "name": "New SAP S/4HANA Cloud Public Edition system for CP20", "months": 9,
     "scores": {"one_instance": 1, "redesign": 3, "history": 2, "risk": 4, "cost": 4}},
]


def load_company_codes() -> list:
    """Read the company codes and the system each runs on from the pack."""
    path = PACK / "org_units.json"
    try:
        org = json.loads(path.read_text(encoding="utf-8"))
    except FileNotFoundError:
        sys.exit(f"Can't find {path}. Run: python unit1b/make_calder_pack.py")
    except json.JSONDecodeError as err:
        sys.exit(f"{path} is not valid JSON (line {err.lineno}). Run make_calder_pack.py again.")
    return org["CompanyCodes"]


def summary(codes: list) -> None:
    """Print each ERP track with its company codes, systems and clients."""
    for track, info in LANDSCAPE.items():
        ccs = [c["CompanyCode"] for c in codes if c["System"] == track]
        print(f"{track} ({info['deployment']}): company codes {', '.join(ccs) or 'none'}")
        for s in info["systems"]:
            clients = ", ".join(f"{k} {v}" for k, v in s["clients"].items())
            print(f"  {s['sid']}  {s['role']:<12} clients: {clients}")
        print(f"  transport route: {' -> '.join(info['route'])}")
    missing = [c["CompanyCode"] for c in codes if c["System"] not in LANDSCAPE]
    if missing:
        print(f"WARNING company codes on a system not in LANDSCAPE: {', '.join(missing)}")


def check_transports(track: str = "S/4HANA") -> int:
    """Check each request against the route. Returns the number of findings."""
    route = LANDSCAPE[track]["route"]
    dev, qa, prod = route[0], route[1], route[-1]
    by_id = {t["id"]: t for t in TRANSPORTS}
    findings = 0
    for t in TRANSPORTS:
        imp = {sid: date.fromisoformat(d) for sid, d in t["imports"].items()}
        problems = []
        source = t["id"][:3]
        if source != dev:
            problems.append(f"comes from {source}, not from {dev}; only {dev} may export")
        if prod in imp and qa not in imp:
            problems.append(f"reached {prod} without passing {qa}")
        if prod in imp and qa in imp and imp[prod] < imp[qa]:
            problems.append(f"reached {prod} before {qa}")
        need = t.get("needs")
        if need and prod in imp:
            before = by_id.get(need, {}).get("imports", {}).get(prod)
            if before is None or date.fromisoformat(before) > imp[prod]:
                problems.append(f"reached {prod} before {need}, which it needs")
        if qa in imp and prod not in imp and not problems:
            days = (RUN_DATE - imp[qa]).days
            if days > DRIFT_DAYS:
                problems.append(f"in {qa} for {days} days but not in {prod}: {qa} and {prod} have drifted")
            else:
                print(f"OPEN     {t['id']}  {t['text']}: in {qa} for {days} days, waiting for test sign-off")
                continue
        if problems:
            findings += 1
            print(f"FINDING  {t['id']}  {t['text']}: " + "; ".join(problems))
        else:
            print(f"OK       {t['id']}  {t['text']}")
    print(f"\n{findings} finding(s) in {len(TRANSPORTS)} requests on route {' -> '.join(route)}.")
    return findings


def decide(weights: dict) -> None:
    """Score each approach for CP20 and compare its duration with ECC mainstream maintenance."""
    months_left = (ECC_MAINSTREAM_END.year - RUN_DATE.year) * 12 + ECC_MAINSTREAM_END.month - RUN_DATE.month
    best = sum(5 * w for w in weights.values())
    rows = []
    for a in APPROACHES:
        score = sum(a["scores"][k] * w for k, w in weights.items())
        rows.append((score, a))
    rows.sort(key=lambda r: (-r[0], r[1]["key"]))
    print("Weights: " + ", ".join(f"{k}={w}" for k, w in weights.items()))
    print(f"Months from {RUN_DATE} to the end of ECC mainstream maintenance ({ECC_MAINSTREAM_END}): {months_left}\n")
    for score, a in rows:
        fit = "fits" if a["months"] <= months_left else "LATE"
        print(f"{a['key']}  {score:>3}/{best}  {a['months']:>2} months ({fit})  {a['name']}")
    print("\nScores and durations are workshop inputs for a fictional company, not SAP figures.")


def diagram(codes: list) -> str:
    """Return the landscape as a Mermaid flowchart."""
    lines = ["flowchart LR"]
    for n, (track, info) in enumerate(LANDSCAPE.items()):
        ccs = "/".join(c["CompanyCode"] for c in codes if c["System"] == track)
        lines.append(f"  subgraph T{n}[{track}: {ccs}]")
        for s in info["systems"]:
            lines.append(f"    {s['sid']}[{s['sid']}<br/>{s['role']}]")
        lines.append("  end")
        route = info["route"]
        for a, b in zip(route, route[1:]):
            lines.append(f"  {a} -->|transport| {b}")
        sandbox = [s["sid"] for s in info["systems"] if s["role"] == "sandbox"]
        for sid in sandbox:
            lines.append(f"  {sid} -.-x|no transports out| {route[0]}")
    lines.append("  S4P <-->|EDI orders, invoices| ECP")
    return "\n".join(lines)


def parse_weights(items: list) -> dict:
    """Start from the default weights and apply name=value changes."""
    weights = {k: w for k, (_, w) in CRITERIA.items()}
    for item in items:
        name, _, value = item.partition("=")
        if name not in weights or not value.isdigit():
            sys.exit(f"Bad --weight {item!r}. Use one of {', '.join(weights)} with a whole number, e.g. history=5")
        weights[name] = int(value)
    return weights


def main() -> None:
    parser = argparse.ArgumentParser(description="Calder landscape, transports and migration options.")
    parser.add_argument("--transports", action="store_true", help="check the S/4HANA transport log")
    parser.add_argument("--decide", action="store_true", help="score the approaches for CP20")
    parser.add_argument("--weight", action="append", default=[], metavar="NAME=N", help="change one weight")
    args = parser.parse_args()

    codes = load_company_codes()
    if args.transports:
        sys.exit(1 if check_transports() else 0)
    if args.decide:
        decide(parse_weights(args.weight))
        return
    summary(codes)
    DIAGRAM.write_text("# Calder landscape (fictional)\n\n```mermaid\n" + diagram(codes) + "\n```\n", encoding="utf-8")
    print(f"\nWrote {DIAGRAM}. Open it in VS Code and press Ctrl+Shift+V (Cmd+Shift+V on a Mac) to preview.")


if __name__ == "__main__":
    main()

Everything Calder-specific sits in four blocks at the top: LANDSCAPE, TRANSPORTS, CRITERIA and APPROACHES. They are course labels and workshop inputs for a fictional company. The system IDs (S4D, ECP and so on) and the transport numbers follow the usual pattern of a three-character system ID, but their values are made up. The only outside fact in the script is the end of ECC mainstream maintenance, 31 December 2027, from SAP's release strategy page. The run date is fixed at 28 October 2026 so your output matches this page.

#Step 4: Draw the landscape

1. Run the script with no options:

   • Windows (PowerShell):

     Copy

     python unit1b\landscape.py

   • macOS / Linux:

     Copy

     python unit1b/landscape.py

2. You should see:

S/4HANA (SAP S/4HANA Cloud Private Edition, release 2023): company codes CP10
  S4S  sandbox      clients: 100 SAND
  S4D  development  clients: 100 CUST, 300 unit test
  S4Q  quality      clients: 100 QTST
  S4P  production   clients: 100 PROD
  transport route: S4D -> S4Q -> S4P
ECC (SAP ECC 6.0, enhancement package 8, on-premise): company codes CP20
  ECD  development  clients: 100 CUST
  ECQ  quality      clients: 100 QTST
  ECP  production   clients: 100 PROD
  transport route: ECD -> ECQ -> ECP

Wrote unit1b/calder_landscape.md. Open it in VS Code and press Ctrl+Shift+V (Cmd+Shift+V on a Mac) to preview.

3. Open unit1b/calder_landscape.md and preview it. You should see two boxes, one per ERP, with transport arrows inside each, a dotted line with a cross from the sandbox, and the EDI link between the two production systems.

The company codes come from the pack, not from the script. If you change CP20's "System" to "S/4HANA" in org_units.json, the next run lists both company codes under S/4HANA. That is option A in one line. Run Step 2 again to put the file back.

#Step 5: Check the transport log

1. Run the transport check:

   • Windows (PowerShell):

     Copy

     python unit1b\landscape.py --transports

   • macOS / Linux:

     Copy

     python unit1b/landscape.py --transports

2. You should see:

OK       S4DK900401  Credit check: new risk class
FINDING  S4DK900412  Hotfix: billing block AC text: reached S4P without passing S4Q
OK       S4DK900414  Seal kit price condition
FINDING  S4DK900415  Seal kit price report (needs 900414): reached S4P before S4DK900414, which it needs
FINDING  S4DK900418  Output form for delivery note: in S4Q for 56 days but not in S4P: S4Q and S4P have drifted
FINDING  S4SK900007  Experiment: new MRP area: comes from S4S, not from S4D; only S4D may export
OPEN     S4DK900420  Tolerance group for CP10: in S4Q for 2 days, waiting for test sign-off

4 finding(s) in 7 requests on route S4D -> S4Q -> S4P.

The four findings are the classic ones:

OPEN is not a finding: a request that has been in quality for two days is waiting for its test, which is normal. The script ends with exit code 1 when there are findings, so a scheduled job could alert on it.

#Step 6: Score the options for CP20

1. Run the decision with the default weights:

   • Windows (PowerShell):

     Copy

     python unit1b\landscape.py --decide

   • macOS / Linux:

     Copy

     python unit1b/landscape.py --decide

2. You should see:

Weights: one_instance=4, redesign=3, history=2, risk=4, cost=3
Months from 2026-10-28 to the end of ECC mainstream maintenance (2027-12-31): 14

A   67/80  11 months (fits)  Company code rollout into CP10's S/4HANA (new implementation)
C   54/80  14 months (fits)  Selective data transition into CP10's S/4HANA
D   45/80   9 months (fits)  New SAP S/4HANA Cloud Public Edition system for CP20
B   41/80  12 months (fits)  System conversion of the ECC system to its own S/4HANA

Scores and durations are workshop inputs for a fictional company, not SAP figures.

3. Now test how sensitive the result is. Suppose Augsburg's finance team insists on keeping closed history in the new system. Raise that weight:

   • Windows (PowerShell):

     Copy

     python unit1b\landscape.py --decide --weight history=5

   • macOS / Linux:

     Copy

     python unit1b/landscape.py --decide --weight history=5

4. You should see A still first (73/95), with C close behind (66/95) and B overtaking D.

The value of the exercise is not the winning number. It is that the weights are written down, so a steering committee argues about "how much does history matter to us?" rather than about the conclusion.

#Step 7: Save your work in Git

git add unit1b/landscape.py unit1b/calder_landscape.md
git commit -m "Add Calder landscape, transport check and migration options"

#What each part of the code does

#If something goes wrong

This script needs no key and no network, so key or proxy problems don't apply here.

#The SAP way

On a real program, each part of this topic has an SAP tool or service. As of October 2026:

Licensing notes. RISE with SAP is a cloud subscription offering; for the private cloud, SAP's training says infrastructure and technical software maintenance can be outsourced under one contract (SAP Learning). GROW with SAP bundles Public Edition with selected SAP BTP services and other cloud products, per entitlement (SAP Support Portal). SAP describes the SAP ERP, private edition, transition option as priced at an uplift over SAP ERP, private edition pricing, with exceptions for customers who committed early, and the max success plan charged on top (SAP News, updated 13 October 2026). Contract details vary; read your own.

#Build vs. SAP

#Architecture view

Where it sits. Calder today, with the course's system IDs:

flowchart LR
  subgraph PCE[S/4HANA private edition, RISE]
    S4D[S4D dev] --> S4Q[S4Q quality] --> S4P[S4P production<br/>CP10]
  end
  subgraph ONP[ECC on-premise]
    ECD[ECD dev] --> ECQ[ECQ quality] --> ECP[ECP production<br/>CP20]
  end
  S4P <-->|EDI| ECP
  S4P --> EWM[Decentralized EWM<br/>Rockford DC]
  S4P --> BTP[SAP BTP apps<br/>and agents]
  ECP --> DW[Data warehouse]
  S4P --> DW

After option A, the ECC track disappears: CP20 becomes a company code in S4P, the EDI link becomes an integrated intercompany flow, and ECC stays only as a read-only source of closed history until it is archived.

Non-functional requirements that decide the design

Integration and identity. Today, orders and invoices travel as EDI messages between S4P and ECP, posted by technical users in each system. After option A, they become documents inside one system, and the messages are retired. Users authenticate through the company's identity provider; once CP20 is in S4P, its users need roles restricted to company code CP20 and plant CP21, so access separation moves from "separate system" to "separate org values" (How an SAP enterprise is wired). BTP apps and agents keep reading through released APIs, now for both company codes.

The decision to record (in the ADR form from Writing a solution design doc):

• Context: CP10 runs S/4HANA private edition; CP20 runs ECC 6.0, whose mainstream maintenance ends on 31 December 2027, 14 months from now. Intercompany between them needs messages and monthly matching. Earlier decisions wait for CP20's move: one controlling area CP00, integrated intercompany flows, and central master data governance.
• Options: (A) roll CP20 into CP10's system as a new company code; (B) convert the ECC system into a second S/4HANA system; (C) selective data transition of CP20 into CP10's system; (D) a new Public Edition system for CP20.
• Decision: (A). Load master data and open items with the migration cockpit; keep ECC read-only for closed history, then archive it. Revisit (C) only if finance proves a legal or business need for closed history online.
• Consequences: Augsburg adopts Rockford's processes, so fit-to-standard workshops and training are on the critical path. Roles must separate the two company codes inside one system. The EDI link and the pre-close check service from the intercompany topic are retired at cutover. If the plan slips past 2027, ECC needs extended maintenance, which costs extra.

What a design review will ask

1. Why one instance for both companies, and what happens to Augsburg if the shared system is down?
2. Which closed history must stay online, for how long, and where will it be read from?
3. How do roles keep the two companies' data apart once they share a system?
4. Which ECC custom programs does Augsburg still need, and are they rebuilt at clean core level A?
5. What is the cutover plan for open items at month end, and what is the fallback?

#Production concerns

• Security and authorizations. Restrict production change to the transport route: no direct changes in production clients, and emergency changes still pass through quality. Sandbox systems with copies of production data need the same data protection as production. For agents, keep separate technical identities per system and per landscape tier (Agent permissions and SAP authorizations).
• Evaluation. Every half-yearly Public Edition release, or every private edition upgrade, needs a regression test set. AI features built on SAP APIs belong in it too: rerun their evaluation sets in the test system before production is upgraded.
• Cost. Count systems, not licenses: every landscape tier is operated, patched, refreshed and tested. Two ERP landscapes mean two upgrade programs.
• Operations. Refresh quality from production on a schedule so tests prove something, and track requests that linger in quality. Agree with SAP, under RISE, who runs which task.
• Clean core. Choose level A for new extensions in every edition. It keeps a later move to Public Edition possible and makes each upgrade cheaper.

#Pitfalls

• Choosing the edition before the processes. The fit-to-standard result should drive the edition, not a price list.
• Treating conversion as a technical project. It changes data models and processes; budget for business testing and training.
• Counting only go-live. Public Edition's half-yearly tests and private edition's upgrade obligation are running costs.
• Hotfixes straight to production. They are the main source of drift between quality and production.
• Migrating every year of history. Each extra year adds data volume, reconciliation and downtime; ask what the business actually reads.
• Planning to the last month. A plan that ends exactly at 31 December 2027 has no slack for a failed cutover rehearsal.

#Exercise

Write Calder's landscape and migration decision record, the page a steering committee signs.

1. Run python unit1b/landscape.py and python unit1b/landscape.py --transports, and confirm you see 4 findings.
2. Create unit1b/calder_landscape_decision.md in VS Code.
3. Under a heading Landscape today, copy the Mermaid block from unit1b/calder_landscape.md.
4. Under Transport findings, write one line per finding with the fix: what the team does differently so it doesn't happen again.
5. Run python unit1b/landscape.py --decide, then twice more with one changed weight each time (for example --weight risk=5, --weight cost=5). Under Option scores, paste the three results and label them as synthetic.
6. Under Decision, write the ADR from the Architecture view in your own words: context, options, decision, consequences. If your weights changed the winner, say why you would still choose it, or not.
7. Under Landscape after, draw a Mermaid diagram of the landscape after your chosen option.
8. Add one line on the ECC difference: which ECC habit (for example, configuring in Customizing) changes after the move.
9. Preview the file to check both diagrams render, then commit it with Git.

Done when: unit1b/calder_landscape_decision.md shows two rendered diagrams, four transport fixes, three labeled synthetic score runs, an ADR with all four parts and an ECC line, and fits on two printed pages. Keep it: Data migration and Fit-to-standard and extension choices start from this decision.

#Check yourself