SAP Transportation Management (SAP TM) is SAP’s system for running freight, the planning, the execution, the settlement, and the monitoring of goods moving by road, rail, sea, or air. It’s the default TMS in SAP S/4HANA, and it runs one of two ways: embedded inside the same system, or standalone alongside it. Shippers, carriers, freight forwarders, and 3PLs use it to pull freight cost down, see every shipment end to end, and take the manual work out of the trip from order to settlement.

Freight has a way of growing on the P&L without anyone signing off on it. A carrier rate nudges up. An empty mile here, a wrong invoice paid there. Nothing you can point at as one clean line item, which is exactly why it’s so hard to control. SAP Transportation Management pulls all of it into one place, so goods get planned, moved, and paid for on purpose instead of by habit.

Below, we get into what SAP TM actually is, how it works from one end of a shipment to the other, the embedded-or-standalone call that snags most implementations, and where the whole thing sits in a 2026 S/4HANA landscape. Whether you’re evaluating it or just trying to get the module straight in your head, this is the place to start.

What is SAP Transportation Management (SAP TM)?

So what is SAP Transportation Management, really? It’s the software that runs your freight, plainly put. SAP TM takes a shipment through its whole life: planning it, picking and booking the carrier, moving and tracking it, then settling what the freight cost. Road, rail, ocean, air, all of it. It sits in the SAP Digital Supply Chain line, and in any current setup it lives inside the SAP S/4HANA enterprise system.

And it isn’t built for just one kind of company. Shippers use it to move their own goods. For carriers and freight forwarders, transportation is the business, so TM is the business. 3PLs run freight on behalf of their clients. The thread tying them together is complexity: lots of carriers, several modes, rates that won’t sit still, and customers who want to know where their order is right now. That’s the mess SAP TM was made for.

The old approach in SAP was LE-TRA, the bare-bones transportation bit tucked inside SAP ERP. SAP TM took its place with something far deeper and purpose-built, and it’s the transportation solution SAP actually puts its development money behind now.

How Does SAP TM Work?

It’s easier to picture SAP TM as a single flow than as a pile of features. Every shipment runs through the same stages, and the module has a hand in each.

• Order and requirement. Something needs to move. That requirement lands in TM from a sales or purchase order in S/4HANA, from a delivery, or as a forwarding order a customer sends you. It tells TM what’s shipping, and by when.
• Planning and optimization. Now TM builds the plan. You can do it by hand, on a map, or let it run automatically. The optimizer trades cost against service level, bundles loads together, and can even lay out vehicle space in 3D so you’re not shipping air.
• Carrier selection and tendering. TM picks the carrier against whatever rules you set, least cost, service level, allocations, then hands the freight over, either straight to the carrier or through a tender where they bid for it.
• Execution and monitoring. Freight’s moving. TM watches it, logs the events, and throws up an alert when something slips, so your team can fix it before the customer ever spots the problem.
• Freight settlement. Finally, TM works out the charges from your carrier agreements, checks the invoices against what actually shipped, and kicks off settlement. This last step is where a surprising amount of overpayment gets caught before it goes out the door.

Run that loop a few thousand times a month, with clean data shared across the business the whole way, and you’ve got the gap between a transportation team that firefights and one that’s genuinely in control.

Embedded TM vs. Standalone TM in S/4HANA

Here’s the call that shapes the entire implementation, and the one most overview breeze right past. Ever since S/4HANA released 1709, TM has run two ways. Choosing wrong and untangling it later gets expensive.

For a new deployment on a single S/4HANA system, embedded TM is usually the pick. It shares the same tables and master data, so there’s nothing to replicate, no CIF interface to babysit, a lighter database footprint, and a lower total cost of ownership. One caveat worth knowing: embedded TM comes with Basic Shipping, and the Professional Shipping features sit behind an extra license.

Standalone, or side-by-side, TM earns its keep when the landscape’s messier. Think a dedicated TMS feeding several ERP instances, some maybe still on ECC, or a business that wants transportation running before it migrates the rest of its ERP. One date to keep on the radar, though: SAP has put end to mainstream maintenance for standalone TM 9.6 on NetWeaver and SCM on 31 December 2027, the very same cliff as ECC. If that older standalone TM is in your landscape, the move to S/4HANA TM is a project that needs a date against it, not a someday.

Core Components of SAP TM

Under the hood, the SAP TM module is a set of components that hand off to each other along the flow above:

• Order and forwarding management. Where transportation demand comes in, and where LSPs raise forwarding orders and quotations for their customers.
• Freight order management. Builds and edits the freight orders and bookings that planning then works from.
• Transportation planning and optimization. The engine room. It turns raw demand into an efficient plan that respects your constraints and your costs.
• Carrier selection and tendering. Chooses the carrier and subcontracts the freight, straight up or by tender.
• Charge management and settlement. Works out charges from your agreements, then drives both freight and forward
• Strategic freight management. The longer game: freight procurement and contract negotiation with your carriers.

Track and trace. Keeps eyes on shipments and reports events in real time across the network.

Key Features and Capabilities of SAP TM

Those components reach users as a set of capabilities worth knowing:

• Flexible planning. By hand, on a map, or fully automated, with 3D load optimization squeezing the most out of every vehicle.
• Multimodal support. One system for road, rail, ocean, and air, complex multi-leg routes included.
• Real-time visibility. Track-and-trace plus event-based alerts, so a delay gets flagged instead of discovered.
• Accurate freight costing. Rate engines and agreement-based charge calculation feed clean settlement and cut the billing disputes.
• Embedded analytics. Fiori apps and Core Data Services reporting on cost, carrier performance, on-time delivery.
• Sustainability planning. TM can pull greenhouse gas emissions into the plan, so carbon sits alongside cost and service in the decision.
• Dangerous goods and compliance. Safe, compliant movement of hazardous materials, in line with the regulations that govern them.

SAP TM and AI in S/4HANA (2026)

The 2026 chapter is worth a mention, partly because it’s where SAP TM is going and partly because it’s where most guides quietly stop. SAP S/4HANA 2025 FPS01, out in March 2026, started pulling Joule, SAP’s generative AI copilot, straight into TM freight document processing. On the ground that looks like AI reading and checking freight documents for you, exceptions clearing faster, and a lot less manual keying in the settlement flow.

It’s early days, and no point pretending otherwise: this is AI lending a hand to a human-run process, not standing in for your planners. But the trajectory’s clear, and it sits on the same governed foundation as the rest of AI-driven SAP Business. If your transportation team is buried in freight paperwork, this is the corner of the roadmap worth keeping an eye on.

Benefits of SAP TM

• Lower freight cost. Sharper planning, consolidated loads, and accurate settlement trim the spend and catch the overpayments.
• End-to-end visibility. One view of every shipment, every mode, so trouble shows up early rather than on the customer’s doorstep.
• Less manual grind. Automated planning, carrier selection, and settlement hand the repetitive work back to the machine.
• Better carrier collaboration. Tendering and collaboration tools keep the conversation and the rates in one place.
• Healthier cash flow. Cost it right, settle it clean, and you pay what you owe. Nothing more.
• Agility when things break. Real-time data and dynamic replanning let you bend with disruption instead of snapping under it.

Common Challenges in Transportation Management, and How SAP TM Helps

The very reasons companies go looking for a TMS line up almost one-to-one with what SAP TM tackles.

• Cost control. Freight spend drifts up across carriers and surcharges when nobody’s watching. TM’s optimization and settlement pin it back down.
• Fragmented data. Transport data scattered across systems hides the problems. Embedded TM keeps it in one place with the rest of S/4HANA.
• Rising customer expectations. People want accurate ETAs and a heads-up when things change. Track-and-trace and event alerts give them that.
• Demand and capacity swings. Volumes and rates that lurch around make planning hard. Automated, rules-based planning flexes with them.

Best Practices for SAP TM Implementation

A TM project is usually won or lost well before go-live. The habits that move the needle, pulled from real rollouts and expanded on in these S/4HANA TM features:

• Scope it against your processes. Map your real transportation flows first, then configure them, not to some generic template.
• Pick the deployment on purpose. Settle embedded versus standalone early, off your ERP landscape and roadmap. It’s a costly thing to change later.
• Get master data right. Locations, business partners, products, rates. That’s the foundation, so clean it before you build.
• Plan the integrations up front. TM rarely stands alone. Map its links to EWM, SD, MM, Finance, and Global Trade Services before you start.
• Roll out in phases. One lane or one business unit, proven, then widen it. Big-bang TM go-lives carry risks you don’t need to take.
• Onboard carriers, train users. The whole thing lives or dies on carriers and planners actually using it. Give both real time in the plan.

How Accely Helps With SAP TM

Most of what decides how a TM project lands is settled before anyone opens configuration. The deployment model. The master data. The integration map. A first phase that proves value quickly. Nail those and the rest tends to follow.

That’s where we come in. As an SAP Gold Partner with 23 years of SAP delivery and logistics rollouts behind us, Accely runs the deployment assessment, makes the embedded-or-standalone call with you, handles the SAP data migration off older TM or ECC, and wires TM cleanly into EWM, Finance, and whatever else is in your landscape. What you’re left with is a transportation function that keeps freight cost down and stays visible, not a project that stalls at the halfway mark. All of it rests on the architecture of SAP S/4HANA underneath.

SAP HANA memory management is how the database claims memory from the operating system, shares it across its own components, then gives it back once it’s free. HANA runs in memory, not off disk, so memory is what keeps it quick or brings it down. The number that counts is used memory, the amount HANA genuinely needs at any given moment. Stay on top of that and performance holds. Lose track of it and slowdowns come first, out-of-memory failures soon after.

Most database problems build slowly. You see them coming. HANA memory problems have a habit of arriving overnight, a system that ran clean yesterday paging, stalling, or dropping out-of-memory dumps by morning. Why does it hit that hard? Because the data sits in RAM. The second demand outruns what the host can hand over, there’s no slow disk underneath to limp along on. The thing just stops.

So no, knowing how HANA handles memory isn’t admin trivia you get to skip. It’s the line between spotting a problem on a dashboard and writing the incident report after the fact. The rest of this covers the memory model, the way allocation actually works, what to keep an eye on, and what to do when consumption starts creeping up.

What is Memory Management in SAP HANA?

At its core, memory management in SAP HANA is the database handling its own housekeeping. It pulls memory from the operating system as it needs it, and gives back what it’s finished with. The catch isn’t the idea. It’s the scale and the speed HANA does this at, and the fact that all of it happens in RAM.

And that’s the part that changes how you think about everything else. HANA is an in-memory database. Your tables, indexes, query results, caches, they all live in RAM while the system runs. Disk only comes into it for persistence and recovery, never for everyday reads. In an older database, memory is one knob among a dozen you might tune. In HANA it’s the single constraint sitting over all the rest. It’s also why the platform under AI-powered SAP S/4HANA needs its memory planned with real care to stay steady once the load comes on.

One indicator sits at the center of all of this. Used memory. Get comfortable with that one and most of HANA memory management falls into place.

How SAP HANA Uses Memory

Picture it as layers. At the top is the physical RAM on the host, the hard ceiling. HANA reserves a chunk of that as a pool and works inside it, growing the pool as tables expand or queries need scratch space, and releasing memory lazily when pressure drops.

What it doesn’t do is grab all the RAM and sit on it. HANA allocates on demand and frees in the background, so the amount it has reserved and the amount it’s genuinely using at any second are two different numbers. Confusing those two is where most memory misreads start. For the wider context of how this fits the platform, the SAP S/4HANA architecture breakdown is a good companion read.

So before the troubleshooting makes sense, you need the vocabulary. Here are the memory types.

Key Memory Types in SAP HANA

SAP documents HANA memory as a set of areas, each measured at a different level. Here’s the whole set in one place.

Code and stack also exist as areas, but they’re tiny and rarely worth a second look.

SAP HANA Used Memory

Worth its own note, because it’s the number you’ll come back to constantly. SAP HANA used memory is the sum of shared memory and the heap memory currently in use. It tells you what the database genuinely requires right now, stripped of the slack that allocated memory carries. When someone asks “how much memory does HANA actually need,” used memory is the honest answer.

Used Memory vs. Virtual Memory vs. Resident Memory

These three get mixed up constantly, usually because someone reads resident or virtual off an OS tool and panics. The relationships sort it out.

In a healthy HANA host with no paging, where HANA is the only serious memory consumer, the numbers line up like this:

• Physical memory is greater than virtual memory.
• Virtual memory equals resident memory, and both are greater than or equal to allocated memory.
• Allocated memory equals shared memory plus allocated heap memory.
• Used memory equals shared memory plus the heap memory in use.

Read that and one thing stands out. A query running will move used memory, but it doesn’t necessarily move the process’s virtual or resident size. So if you’re watching the OS instead of HANA’s own indicators, you’ll misread what’s happening.

One more indicator to know. Peak used memory is the highest used memory has reached since the last restart. It’s how you catch a spike that’s already passed, the load test at 2am you’d otherwise never see in a live reading.

Memory Allocation in SAP HANA

The Memory Pool and Lazy Allocation

HANA doesn’t ask the OS for memory transaction by transaction. That would be slow. Instead it reserves a pool up front and serves its own needs from it. When the pool can’t cover a request, the memory manager goes back to the OS for more, up to the limit.

The lazy part matters. HANA holds onto allocated memory rather than returning it the instant a query finishes, on the assumption it’ll need it again shortly. So allocated memory can drift up toward the ceiling while used memory sits well below it. That’s normal. It’s not a leak.

Initial vs Dynamic Allocation

At startup, HANA loads the row store and a baseline set of structures, your initial footprint. From there it’s dynamic. Column tables load as they’re touched, temporary results consume heap during queries, and the pool grows to match. Demand drives the number, not a fixed reservation.

The Global Allocation Limit

This is the cap on how much memory HANA will allocate, and it’s a query worth knowing on its own. By default the global allocation limit is set to 90% of the first 64 GB of physical memory, plus 97% of every GB above that. You can change it through the global_allocation_limit parameter in global.ini, set in MB.

Hit that limit and the memory manager can’t allocate more for anything, internal operations included. Which is the doorway to out-of-memory territory, so it’s worth getting the sizing right early. Memory planning during a move is exactly the kind of thing covered under AI-assisted SAP migration, where readiness assessment flags undersized hosts before go-live rather than after.

Column Store vs. Row Store Memory

The two table stores in HANA use memory differently, and that difference drives a lot of consumption.

Column Store

The column store holds most of your data and is built for reads. It splits into two parts. Main storage is heavily compressed and read-optimized. Delta storage takes the writes with lighter compression, and a delta merge periodically folds those writes back into main.

Two behaviors save memory here. Columns load lazily, on first access, so columns nobody queries never take up space. And under memory pressure, HANA unloads columns it hasn’t touched recently to free room, reloading them when they’re next needed. That unloading is automatic, though you can influence it with unload priorities.

Row Store

The row store is write-optimized and loads fully into memory at startup. It doesn’t unload the way the column store does, and it lives in shared memory. Keep it lean. A bloated row store is memory you pay for at every restart, whether anyone queries it or not.

Monitoring SAP HANA Memory

You can’t manage what you’re not watching, and the old habit of reading memory off the OS will mislead you. Use HANA’s own tools.

SAP HANA Cockpit

Cockpit is the current admin tool for this. It surfaces used memory, peak used memory, the allocation limit, and per-service breakdowns without you writing a line of SQL. If your team is still living in HANA Studio for monitoring, that’s the dated path now. The cockpit is where this lives.

System Views and SQL

When you want detail, the monitoring views give it. A few worth knowing:

• M_HOST_RESOURCE_UTILIZATION for host-level physical and used memory.
• M_SERVICE_MEMORY for per-service used, allocated, and peak figures.
• M_HEAP_MEMORY to see which allocators are eating the heap.
• M_CS_TABLES for the largest column tables in memory.

SAP also ships a set of memory mini-checks through its SQL statement collection (SAP Note 1969700) that surface the common problems fast.

Tracking Used Memory and Peak Over Time

A single reading tells you almost nothing. Used memory swings with load all day. What you want is the trend, and the peak across a window that includes your heaviest jobs. Continuous tracking is where AI-assisted SAP managed services earns its place, watching memory trends and firing alerts before a slow climb turns into a failed allocation, instead of someone noticing after the fact.

Troubleshooting High Memory Consumption

This is the section you’ll come back to when something’s wrong.

Finding What is Consuming Memory

Start with the heap. M_HEAP_MEMORY shows the top allocators, which usually points straight at the cause, whether that’s a large intermediate result, a runaway statement, or a cache. Then check M_CS_TABLES for oversized column tables. Compare used memory against the allocation limit to see how much headroom is actually left.

Out-of-Memory (OOM) Situations and Dumps

When HANA can’t allocate, either because it hit the allocation limit or the host ran out of physical RAM, it raises a composite out-of-memory error and writes an OOM dump to the trace directory. That dump is not noise. It lists the top memory consumers at the moment of failure, which is often the fastest route to the culprit. SAP Note 1999997 is the standard memory FAQ, and 1900257 covers reading OOM dumps.

Adjusting Memory Parameters

A few levers, used carefully. global_allocation_limit caps total allocation. statement_memory_limit stops a single runaway query from taking the whole system down with it, which is one of the more useful guardrails you can set. Unload priorities tell HANA which column tables to drop first under pressure.

Reducing Memory Consumption

Parameters treat symptoms. To cut the underlying load, the real moves are data aging and archiving to get cold data out of memory, partitioning very large tables, dropping unused indexes and objects, and keeping delta merges healthy so the delta store doesn’t swell. Less data in memory is the only fix that lasts.

Memory Management in Multitenant Database Containers (MDC)

In a multitenant setup, one system database and several tenant databases share the same host RAM. Left uncapped, a single hungry tenant can starve the others. So you set a global_allocation_limit per tenant, in that tenant’s own configuration, to box in how much each one can take. The system database coordinates, but the discipline is the per-tenant cap. On shared infrastructure, getting these limits right is part of a stable AI-enabled SAP Private Cloud foundation, where one tenant’s spike shouldn’t become everyone’s outage.

How Accely Helps You Manage SAP HANA Memory

Most HANA memory trouble isn’t a mystery once you’re in it. The harder part is not being in it. That means sizing the host correctly before migration, setting allocation limits and statement guardrails that fit your actual workload, and watching the trend so a slow climb gets caught while it’s still a chart and not an incident.

That’s the work Accely does with HANA teams. As an SAP Gold Partner with 23 years in SAP delivery, we pair AI-assisted monitoring and proactive alerting with hands-on tuning, from migration sizing through day-two operations. The aim is straightforward. A HANA landscape that stays inside its memory budget, so your team spends its time on the business and not on OOM dumps at midnight.

An extension ledger in SAP S/4HANA sits on top of a standard ledger and records only delta postings, meaning the specific adjustments you need for one reporting view. It doesn’t copy the base ledger’s data. When you run a report, SAP reads both ledgers together. So you get a way to handle tax adjustments, management entries, and predictive accounting without building a second full ledger to do it.

Ask a finance team how many versions of their numbers they keep, and the honest answer is always more than one. There’s the statutory view. The group view. A tax view. Then whatever shape management wants this quarter. Same underlying figures, reshaped four different ways.

Standing up a full ledger for each of those is slow, and it bloats your data. The extension ledger is SAP’s answer to that problem. It lets you record adjustments on top of a ledger you already have, without copying anything or going near your core books.

Below: what it is, how it differs from a non-leading ledger, how it actually works, where predictive accounting comes in, what it can’t do, and how to configure one.

What is an Extension Ledger in SAP S/4HANA?

An extension ledger pulls its data from an underlying standard ledger and stores only the extra postings you make against it. Those extras have a name in SAP. Delta postings.

The base figures are inherited, not copied. So the extension ledger only ever holds the difference, nothing else.

All of it lives inside the Universal Journal, the single ACDOCA table that carries finance line items in AI-enabled SAP S/4HANA. One table for every posting. That’s the thing that lets you report on the standard ledger by itself, the extension ledger by itself, or the two read together, without stitching data from different places. For the wider map of where finance sits in the suite, the overview to SAP S/4HANA modules is a decent starting point.

A standard ledger is your book of record. An extension ledger is a see-through layer on top of it, holding entries you want in a specific report but nowhere near your core books.

SAP S/4HANA Finance and the General Ledger

In SAP, the general ledger is where financial accounting lives. Every business transaction lands on a G/L account, and from there the ledger gives you the full financial position, broken out by company code, segment, profit center, whatever dimension you report on.

S/4HANA changed how this works under the hood. The old setup kept separate tables for the G/L, controlling, asset accounting, the material ledger. S/4HANA folded all of that into one line-item table, ACDOCA, shared across every module. And that shared table is the whole reason extension ledgers can exist. The data already sits in one place, so SAP can layer a ledger over it and read both at runtime.

If you want a closer look at the finance side, the S/4HANA finance module breakdown goes deeper. From here on, we stay on the extension ledger.

Types of Ledgers in SAP S/4HANA

Two ledger families matter before the extension ledger makes sense. Standard ledgers, and the extension ledger itself.

Standard Ledger

A standard ledger carries the full record of your financial transactions. S/4HANA gives you two kinds of it.

The leading ledger (0L) is the primary one. It usually runs your group accounting principle, often IFRS. Every company code reports to it, and postings cascade down from there.

A non-leading ledger runs in parallel for a different principle, normally local GAAP or tax. The key point: it stores a complete set of values on its own. That’s what makes it fit for statutory reporting in a given country.

Extension Ledger

The extension ledger isn’t a standalone book. It points at a base ledger and records only delta entries against it. If the base ledger already shows a number, the extension ledger inherits it and posts your adjustment on top. Which is exactly why it carries a sliver of the data a full ledger does.

Most teams use it as a tax or management overlay. Legal numbers stay in the base ledger. The adjustments only one audience cares about go in the extension ledger.

Extension Ledger vs Non-Leading Ledger

This is the comparison people get stuck on, because both touch parallel reporting. What separates them is what they store, and what you’d reach for them to do.

A quick way to decide. Does the view need to stand on its own as a legal book? Non-leading ledger. Is it just an adjustment layer on figures that already exist? Extension ledger.

Key Features of the Extension Ledger in SAP S/4HANA

Worth being precise here, because people blur the two constantly. These are extension ledger features, not general ledger features.

Derivation from the Standard Ledger

Every extension ledger ties to an underlying ledger, usually 0L, and reads its data automatically. You never key the base figures again.

Delta Posting

You post the difference, and only the difference. A tax adjustment, a management accrual, a reclassification, all of it goes into the extension ledger and stops there. The base ledger doesn’t move.

Storage Efficiency

Nothing gets duplicated, so the data footprint stays small. SAP merges the base values with the delta entries on the fly when you run a report. On a system pushing serious transaction volume, that saved space adds up fast.

Parallel and Scenario Reporting

You can run parallel accounting and what-if scenarios without standing up a stack of full ledgers. Each extension ledger is its own view, layered on the same actuals. Handy when consolidation and adjustment cycles start piling on top of each other, and it works well alongside AI-powered SAP Group Reporting for catching anomalies during consolidation.

Integration with the Universal Journal

Base postings and delta postings all sit in ACDOCA. Same table, same reporting tools, and the numbers reconcile whether you’re looking at the standard ledger, the extension ledger, or both at once.

How Does the Extension Ledger in SAP S/4HANA Work?

Three moving parts, really. How the data flows, how postings get tagged, and how a report stitches it all back together.

Data Flow

Run a report and SAP grabs the base figures from the standard ledger, then drops the extension ledger’s delta entries on top. Nothing’s calculated ahead of time or held in two places. The merge happens live, at the moment you run it.

Posting Mechanism

Anything posted to an extension ledger gets tagged to its ledger group, so it only ever touches that ledger. The base ledger never sees it. That isolation is the entire point. You record an adjustment, it shows up in one report, and your legal books don’t budge.

Reporting

You pick the lens. Standard ledger for the legal numbers. Extension ledger to see the adjustments on their own. Both, for the adjusted picture. One data source, three ways to read it.

Extension Ledger and Predictive Accounting in SAP S/4HANA

Here’s where the extension ledger earns its keep, and it’s the part most overviews skip past.

How Predictive Accounting Uses the Extension Ledger

Predictive accounting shows you the financial impact of something that hasn’t been posted yet. Create a sales order and there’s no actual revenue, so the standard ledger records nothing. Predictive accounting instead writes a statistical entry into an extension ledger. Your actuals stay clean. The forecast sits right next to them, separate.

Worked Example: Forecasting from a Sales Order

Say a manufacturer takes a sales order worth 50,000 USD. Nothing’s shipped, so the leading ledger 0L stays empty on this one for now.

Predictive accounting posts to the extension ledger, call it N1:

• Predicted accounts receivable: 50,000 USD
• Predicted revenue: 50,000 USD

Then the goods go out, the invoice posts, real revenue hits 0L, and that predictive entry in N1 drops away. A report reading 0L plus N1 shows you booked revenue and the pipeline you expect to land, in one view. Committed and expected, side by side, neither one polluting the other.

Real-Time Forecasting and AI-Enabled Planning

Once those predictive entries are flowing, they turn into a feed for forward-looking analysis. That data carries cleanly into AI-enabled predictive forecasting, where models read committed actuals and predicted pipeline together and flag variances earlier than any manual review would. The extension ledger keeps prediction and actual apart at the source. That separation is what makes the downstream analysis worth trusting.

Benefits of the Extension Ledger in SAP S/4HANA

Faster Setup With No Data Migration

Configuration, not a data project. There’s no migration to run. Configure it, and it reads existing data straight away, with historical figures coming through the base ledger.

Lower Data Footprint

Delta-only storage means you add a reporting layer without paying the storage cost of a full parallel ledger. On high-volume systems, that gap is real money.

Reuse of Existing Reports

Standard ledger reports just work with extension ledgers. Analytical apps and old-school SAP GUI reports both read the combined view, so you’re not rebuilding a reporting stack from scratch.

Flexible Parallel and Management Reporting

Carve out a separate view for management, tax, or a what-if scenario, and the legal books stay untouched. Every view is its own overlay.

Reduced Risk to Core Ledgers

Adjustments are boxed into the extension ledger, so the odds of a management or tax entry quietly distorting your statutory numbers drop to roughly nil. Your book of record stays exactly that.

Limitations: What the Extension Ledger Cannot Do

It’s an overlay, not a stand-in for a standard ledger. Knowing the edges keeps you from designing yourself into a corner you can’t post your way out of.

• No postings to customer or vendor reconciliation accounts.
• No postings to G/L accounts under open item management.
• No integration with Asset Accounting.
• Limited support for automatic processes like G/L allocations.
• It leans on its base ledger, so it can’t run independent business processes alone.
• It’s built for adjustments, reporting, and predictive entries, not core legal ledger accounting.

If a requirement trips any of those, the answer is a non-leading ledger or a different design, not an extension ledger forced into a job it wasn’t built for.

Use Cases and Scenarios for Extension Ledgers

Local Tax vs IFRS Adjustments

A company reports group results under IFRS in the leading ledger, then needs local tax adjustments, accelerated depreciation, tax-deductible provisions, that sort of thing. Those go into the extension ledger. Both views stay compliant, and nothing’s duplicated to get there.

Management and Topside Adjustments

Management reporting wants regroupings and reclassifications that have no business sitting in the legal books. The extension ledger holds those topside adjustments cleanly, so the management view and the statutory view trace back to the same actuals.

Post-Closing and Period-End Entries

Entries booked after a period closes, or corrections you only want visible in one report, fit the model neatly. The closed standard ledger never gets touched.

Forecasting and Predictive Scenarios

Covered this above, so just to place it: predictive accounting and what-if runs both lean on the extension ledger to keep forward-looking entries away from your actuals.

How to Set Up an Extension Ledger in SAP S/4HANA

Setup happens in configuration (SPRO). Menu wording shifts a little between releases, so check it against your own system. The flow itself holds steady.

Creation Procedure

Head to Financial Accounting, then Financial Accounting Global Settings, then Ledgers, then Ledger, then Define Settings for Ledgers and Currency Types. Create the new ledger, set its type to extension ledger, and point it at the base ledger it should read from, usually 0L.

Company Code Settings

Open company code settings for the new ledger. It inherits the company code assignments from its base ledger, so before you post anything, double-check the company codes you expect are actually there.

Assigning Accounting Principles

Assign an accounting principle. Nine times out of ten it mirrors the reference ledger’s principle, so the overlay reports on the same basis as the book underneath it. Principle assigned, and the ledger’s ready for delta postings.

Implementing Extension Ledgers With Accely

Most extension ledger projects don’t come apart at configuration. They come apart at design. The technical build is a day’s work. Deciding which views belong in an extension ledger, which need a full non-leading ledger, and how predictive accounting should feed your planning, that’s where the real time goes, and where the expensive mistakes hide.

That’s the part Accely works on with finance teams. As an SAP Gold Partner with 26+ years in SAP delivery, our consultants run AI-assisted analysis across your current ledger setup and data quality, then map each reporting requirement to the right ledger design before anyone opens SPRO. Parallel reporting structures, predictive accounting, the move onto SAP financial management for teams modernizing the close. The point is a ledger architecture that reports right the first time, instead of one you spend a quarter unpicking.

Selective data transition (SDT) is a hybrid way of getting to SAP S/4HANA. Rather than converting the whole system, the way brownfield does, or starting from a blank sheet, the way greenfield does, you handpick the data and configuration worth carrying forward and leave everything else behind. It lands squarely between the two extremes, and it’s the route that actually suits the tangled, multi-system landscapes most big SAP shops are living with.

Every road to SAP S/4HANA opens at the same fork. Do you convert what you’ve already got, or tear it down and rebuild? Brownfield or greenfield. Put like that it sounds like a tidy either-or. It almost never is.

Real SAP landscapes aren’t tidy. They’re what’s left after years of growth, a few acquisitions, regional rollouts, and quick fixes nobody ever went back to clean up. Several systems humming along in parallel, master data that argues with itself, custom code that drifted away from the business a long time ago. Point a pure brownfield or a pure greenfield at that and neither one really lands. The gap in the middle is where selective data transition sits, and this guide walks through what it is, when it’s worth it, how it works under the hood, and where it bites if you’re careless.

What is Selective Data Transition for SAP S/4HANA?

Selective data transition is a migration approach that moves only the data you pick from your legacy systems into a new AI-enabled SAP S/4HANA environment. There’s no copying the whole system the way brownfield does, and no walking away to rebuild from nothing the way greenfield does. You decide, on purpose, what crosses over and what stays where it is.

A useful way to picture it is a curated migration. You’re not hauling decades of history forward untouched, and you’re not binning the parts that still do their job. The valuable configuration and custom development from ECC comes across, the data that matters comes across, and the obsolete stuff gets left behind.

The real shift is quieter than the definition lets on. In a normal project the method sets the data scope: brownfield drags everything, greenfield takes next to nothing. SDT turns that on its head. Scope becomes a design decision you make up front, driven by what the business needs rather than by what the technical approach forces on you. That’s why people also call it a data-driven migration, or Bluefield, instead of just a hybrid.

Brownfield vs. Greenfield vs. Selective Data Transition

To place SDT properly, line all three up next to each other. Brownfield and greenfield have been the two standard S/4HANA routes for years now, both well documented, both fully supported by SAP. The cracks only show once you get past the definitions and into a real landscape.

Brownfield, or system conversion, is the lift-and-shift. It converts your existing ECC system to S/4HANA with data and processes mostly untouched. Quick, familiar, and a decent fit when the environment is stable and reasonably clean to begin with. Greenfield is the blank sheet: a fresh S/4HANA build, processes redesigned on SAP best practices, little or no history carried across. A lovely destination, but the price tag and the timeline send plenty of companies running. SDT is the road that runs between them, and it can lean toward either end depending on how much you decide to reuse.

There’s an old industry line that sums up the trade-off well enough. Managers of system conversions think in weeks, managers of selective transitions think in months, and managers of new implementations think in years. SDT buys you the control of a redesign without signing up for the full clock of one.

When to Use Selective Data Transition

SDT isn’t the right call for everyone. Where it genuinely earns its keep is the handful of situations brownfield and greenfield both handle badly:

• Consolidating multiple SAP systems. Several ECC instances have to become one S/4HANA system. SDT merges them and sorts out the overlaps as it goes.
• Carve-outs and divestitures. Cleanly separating a business unit or a chunk of data, without breaking continuity or compliance.
• Mergers and acquisitions. Folding an acquired company’s data into your landscape without adopting all of its mess along with it.
• Trimming the migration scope. You want the modern platform, not thirty years of closed transactions dragging down a brand-new HANA database.
• Cleaning up legacy data. A rare chance to harmonize master data and drop the dead records, rather than carrying them forward as-is.

Phased or wave rollouts. Go live one company code or region at a time, then merge later waves into a system that’s already up and running.

How Selective Data Transition Works

Underneath, every SDT project answers two questions, in this order: how do we build the target system, and which data do we move into it.

Creating the Target System

The target S/4HANA system, the golden shell as it’s sometimes called, gets created in one of a few ways. Shell conversion is the most common: take a 1:1 copy of ECC, strip out the master and transactional data, hold onto the customizing and repository objects, and convert that lightweight shell to S/4HANA. Mix-and-match goes the other way, starting from a fresh S/4HANA install and then selectively importing the configurations and processes worth keeping. And in wave-based rollouts, an S/4HANA system is already live, and SDT just keeps feeding data into it over time.

Selecting and Transferring the Data

This is the heart of the whole thing. Using SAP Landscape Transformation tooling, data is selected and moved at table level, filtered by organizational unit, by key date, or by whatever criteria you set. You pick the ABAP repositories, the master data, the transactional data that comes across, and the obsolete records stay behind. Nailing that scope is exactly where SAP migration assessment earns its money, because the call is a business one first and a technical one second.

Cleansing, Harmonizing, and Reorganizing in Flight

SDT lets you reshape data as it moves, not just copy it across. Rename company codes 1:1, cleanse and drop what’s no longer useful, harmonize master data across systems you’re merging, reorganize organizational units, all in the same step as the migration itself. That’s the flexibility a straight brownfield simply can’t hand you.

Keeping Systems in Sync and Cutting Over

Long migrations hide an awkward problem: the ECC system keeps changing while you’re mid-project. SAP deals with it through a retrofit process, run via Solution Manager or Cloud ALM, that keeps source and target in step. And because SDT works at table level, near-zero-downtime cutover is on the table, which for a business that can’t stomach a long outage is frequently the entire reason to go this way.

Lean SDT and the SAP Business Transformation Center (2026)

One 2026 shift most guides haven’t caught up to yet is worth flagging. SAP now ships Lean SDT as its standard selective-transition scenario, delivered through the SAP Business Transformation Center up in the cloud. It runs on a target shell system, works at table level, and lets you filter by organizational units and time slices, with a good chunk of the legwork automated for you.

The bit worth knowing is the Digital Blueprint, a scoping capability that helps you pin down exactly which data is relevant to your business and your compliance obligations before anything moves. Guided execution walks the project end to end, and SAP-delivered content and checks make the whole thing more repeatable. It’s the same governed-data thinking that runs through the rest of AI-driven SAP Business, pointed at migration scoping.

Accely’s Selective Data Transition Methodology

A selective transition is won on planning, not on tooling. Our delivery runs through the five phases of SAP Activate, and each one has a clear job:

Discover

We look hard at your current landscape, your data quality, and your business goals, and confirm whether SDT is genuinely the right fit or whether brownfield or greenfield would serve you better. There’s no sense selling a selective transition into a problem that doesn’t call for one.

Prepare

Scope and design. We settle what data comes across, how the target system gets built, and what’s cleansed, harmonized, or reorganized on the way in. This is where the data-scope decisions get made, and written down.

Explore

We map the source data and processes to the S/4HANA target in detail, validate the design against real data, and drag the edge cases, custom objects, and interdependencies into the light before they turn into go-live surprises.

Realize

Build and test. The migration gets configured, the selected data is moved into the target, and everything is reconciled and validated back against the source, over and over, until the numbers agree.

Deploy and Run

Cutover, ideally with near-zero downtime, then hypercare and post-go-live support. We stick around through stabilization, because the first few weeks after go-live are when the real issues decide to show up.

Benefits of Selective Data Transition

• Lower risk, less data debt. You bring only what’s needed, so decades of legacy baggage don’t tag along into the new system.
• A leaner, cheaper S/4HANA. Less data in HANA means lower cost and less long-term complexity. Migrating the lot quietly inflates both.
• Quicker than greenfield. You reuse configuration and custom development that already works instead of rebuilding it, and that trims the timeline in a real way.
• Cleaner data at the end. Cleansing and harmonizing happen during the move, so you land on better data than you left with.
• Near-zero downtime. Table-level techniques keep the outage short, which counts for a lot when the business can’t just stop.
• Your call on timing. One big go-live or a phased set of waves, whichever suits, and you can fold harmonization or consolidation into the same move.

What to Watch Out For

SDT hands you control, but only if the design is any good. The failure mode worth naming out loud is data loss, and it pays to be clear about where it actually comes from.

Data loss isn’t a byproduct of going selective. It comes from a migration design that lacks clarity: scope drawn too tight, or drawn without asking the business; compliance-relevant data cut without checking the retention rules; custom objects or non-standard tables quietly missed; validation and reconciliation half-finished. Designed deliberately, a selective migration builds structure. Designed carelessly, gaps open up, and they tend to surface right after go-live, at the worst possible moment.

And a selective scope raises one question straight away: if not all the data moves to S/4HANA, where does the rest go? Leaving ECC running in read-only mode is costly and defeats the purpose. The cleaner answer is a governed, searchable archive that keeps historical and compliance data within reach without bloating the new system. Our guide to SAP data archiving digs into that side properly.

Selective Data Transition in Practice

It scales further than most people expect. There’s one example that gets passed around a lot: 190 company codes and tens of billions of records moved into a new global S/4HANA environment across a single weekend, and manufacturing and distribution never once stopped. Roughly four-fifths of the processes came over with barely a change. The rest, a targeted few, got reworked to pull value out of the new platform straight away.

The point isn’t the size of it, though. It’s the principle underneath. Being selective meant modernization and continuity got to move together, instead of one being traded off against the other. Same logic on a two-system consolidation, or a carve-out. Keep what’s proven, fix what isn’t, walk away from the rest. And if you want the fuller picture of what you’re landing on, the SAP S/4HANA modules overview pairs well with this.

How Accely Helps

How an SDT project ends up is mostly decided before a single table moves anywhere. The approach you pick. The data you scope in. How the target system gets built. A validation plan you can actually trust. Get those four straight and the migration itself tends to fall into line.

That’s the part we spend the most time on. As an SAP Gold Partner with 23 years of SAP delivery behind us, Accely runs the assessment, makes the brownfield-greenfield-selective call with you rather than at you, scopes and runs the transition on Lean SDT and SAP Landscape Transformation tooling, and sets up the governed archive for whatever gets left behind. Single conversion, multi-system consolidation, carve-out, on-premise or an AI-enabled SAP S/4HANA Private Cloud, the aim never really changes: a lean, clean S/4HANA that takes your business forward and leaves the baggage at the door.

Two cloud editions. One decision that shapes your next decade of SAP. Public Cloud runs under GROW with SAP, fast, standardized, SAP manages everything. Private Cloud runs under RISE with SAP, dedicated, flexible, built for complexity. SAP quietly grouped both under “SAP Cloud ERP” in 2025, but the differences between them are anything but cosmetic. This guide cuts through the noise on cost, control, deployment, and which one actually fits your business.

What Is SAP Cloud ERP and How Do Public and Private Editions Fit In?

Most vendor blogs still haven’t picked this up, but in 2025 SAP quietly rebranded its cloud portfolio under one name: SAP Cloud ERP. Both editions now sit under that umbrella. The individual product names still exist, they haven’t gone anywhere, but SAP’s commercial messaging has shifted.

What that tells you is actually useful. SAP isn’t positioning Public and Private as competing products anymore. Same HANA core. Same long-term roadmap. Same innovation pipeline feeding both. The split is in delivery model, in who manages what, and in how much control ends up in your hands rather than SAP’s.

Coming into this decision fresh, or revisiting something you decided a few years back? That context matters. It stops you wasting time debating technology when the real question is about deployment model and operational control. For a practical look at what the Public Cloud path actually involves, SAP S/4HANA Public Cloud implementation covers it in detail.

What Is SAP S/4HANA Public Cloud Edition?

How Does SAP S/4HANA Public Cloud Work?

Shared infrastructure. Your organization sits alongside other SAP customers on the same underlying servers, data and processes stay walled off from each other, but the maintenance, the updates, the infrastructure sizing? None of that is your problem. SAP deals with it.

You subscribe. You configure what your business needs. You go live. That’s genuinely it. No one on your team loses sleep over server capacity or patch schedules. That simplicity is the whole point of the model.

What Is GROW with SAP and How Does It Relate to Public Cloud?

GROW with SAP is the commercial package SAP wraps around Public Cloud. Software, implementation tooling, best-practice content, bundled together to get businesses live in months, not years. When SAP pitches Public Cloud, it sells through GROW.

The name gives you the intent: this is for organizations that are growing and want SAP running fast without a multi-year implementation project eating their budget and headcount.

Who Should Use SAP S/4HANA Public Cloud?

New to SAP. No heavy customizations to bring across. Comfortable going live within six months. Happy to let SAP’s standard best-practice processes shape how the business operates rather than building custom workflows from scratch. Mid-market companies and first-time SAP adopters tend to find Public Cloud a natural landing spot.

What Is SAP S/4HANA Private Cloud Edition?

How Does SAP S/4HANA Private Cloud Work?

Dedicated infrastructure, yours alone. SAP or a hyperscaler hosts it, but nothing gets shared with other customers. Your instance, your environment, your rules.

That’s what unlocks the flexibility. Custom code becomes possible. Proprietary extensions, complex configurations, control over when updates land, none of that works in a shared environment, which is exactly why Private Cloud exists.

What Is RISE with SAP and How Does It Relate to Private Cloud?

Think of RISE as GROW’s counterpart for Private Cloud. Same concept, a commercial package bundling the software with managed infrastructure, SAP Business Network access, and transformation services. One subscription to cover the technical estate.

Where GROW targets speed and simplicity, RISE is built for transformation. Large enterprises migrating from SAP ECC with years of custom development behind them. The managed services layer in RISE is genuinely valuable here, the technical landscape is big enough that running it independently is a significant undertaking.

Who Should Use SAP S/4HANA Private Cloud?

Heavy SAP customizations. Strict data sovereignty requirements. Regulated industries where standard processes won’t cut it. Organizations on SAP ECC that have configurations and custom code their business depends on daily. If that sounds like you, Private Cloud is probably where you end up.

SAP S/4HANA Private Cloud for enterprises covers what that implementation path looks like.

SAP S/4HANA Public Cloud vs Private Cloud: Key Differences

Customization and Flexibility

Public Cloud works within SAP’s standard process templates. Configure, yes. Modify the core code, no. Businesses with processes that fall outside those templates face a real choice: adapt how they work to fit the software, or accept that walls will appear.

Private Cloud has no equivalent constraint. Custom code lives here comfortably. Complex configurations, proprietary extensions, niche integrations, the dedicated environment handles all of it. That’s the main reason large enterprises end up here regardless of the cost differential.

Deployment Approach: Greenfield vs Brownfield

Public Cloud means starting fresh. No legacy code comes across, no old configurations survive the migration. Greenfield only. For organizations that want a clean break from technical debt, that’s a genuine advantage. For those who’ve spent years building SAP configurations they rely on, it’s a wall.

Private Cloud supports both paths. Brownfield conversion, migrating existing ECC data, configs, and custom code into S/4HANA, is exactly why most ECC customers land on Private Cloud when they start evaluating their options.

Cost and Total Cost of Ownership

Public Cloud is cheaper to start. Faster to implement, no separate infrastructure bill, SAP absorbing the update overhead. Over three to five years the TCO advantage holds for organizations that can genuinely work within the standard process model.

Private Cloud costs more. No avoiding it. Dedicated infrastructure, longer implementation, more consulting hours, the premium is real and substantial. But the comparison only means something if Public Cloud can actually handle what your business needs. For complex enterprises, often it can’t.

Security, Compliance, and Data Control

Enterprise security standards apply to both. The practical gap is in who controls what. In Public Cloud, SAP owns the security configuration of the shared environment. You get strong security, but not on your terms.

Private Cloud hands significantly more control to your organization. How data gets stored, who can access it, what the security policies look like, those decisions are yours. For banking, pharma, government, and most regulated sectors, that control isn’t a preference. Regulators require it.

Updates, Upgrades, and Innovation Access

Public Cloud pushes two major releases per year. SAP sets the schedule. Features keep coming, the system stays current, but you have no say over when updates land.

Private Cloud lets you own the update calendar. Innovations still arrive, but critical period blackouts, extended testing windows, scheduled maintenance, all of that gets planned on your timeline, not SAP’s.

Implementation Timeline

Public Cloud for a mid-sized business on standard processes: three to six months, sometimes faster. Private Cloud for an enterprise migration: nine to eighteen months minimum, often longer when the landscape is genuinely complex.

Stat Callout: 61% of SAP S/4HANA Cloud users are on Public Edition, 38% on Private Edition. (Source: CIO/COMPUTERWOCHE Cloud ERP Study 2024)

What Are the Similarities Between Public and Private Cloud?

Worth knowing what you get regardless of which path you choose, because competitors rarely cover it.

Both Run on SAP HANA In-Memory Database

Same engine underneath both editions. Real-time processing, in-memory analytics, the performance characteristics that make S/4HANA worth the investment, none of that is edition-dependent.

Both Offer SAP BTP Integration for Extensibility

SAP Business Technology Platform is available in both. Extensions, third-party integrations, custom applications built without touching the ERP core, the clean core principle applies across the board.

Both Include Regular Updates and Innovation Access

SAP AI features, platform updates, new capabilities, both editions get them. Timing and scheduling control differ. The direction of innovation doesn’t.

Both Support High Availability and Security Standards

Enterprise uptime SLAs, redundancy, disaster recovery, built into both. Neither edition compromises on reliability standards.

GROW with SAP vs RISE with SAP: What Is the Difference?

Shortest version: GROW is Public Cloud, RISE is Private Cloud.

Longer version: GROW is the fast lane. Mid-market organizations, first-time SAP customers, businesses that want to be live in under six months and don’t have a complex legacy SAP landscape holding them back. Speed is the proposition.

RISE is the transformation lane. Enterprises carrying years of ECC history, integrations, and custom code that need a managed path to S/4HANA without blowing up everything that currently works. The managed services wrap is real and matters for organizations whose technical estate is too large to handle independently.

SAP markets both with equal enthusiasm, which creates genuine confusion. A practical filter: are you implementing SAP for the first time or moving to it from a non-SAP system? GROW. Are you migrating an existing SAP ECC environment with significant investment to protect? RISE.

Connecting these commercial packages to your actual infrastructure decisions is covered well in the SAP S/4HANA deployment options breakdown.

How Much Does SAP S/4HANA Public Cloud vs Private Cloud Cost?

SAP Public Cloud Pricing Model

Per user, per month. Infrastructure, updates, and maintenance wrapped in. No separate database licensing, no server bills. A mid-sized organization running finance, procurement, and supply chain on 100 to 500 users typically lands somewhere between $250,000 and $800,000 annually depending on module scope and headcount.

SAP Private Cloud Pricing Model

More moving parts. The RISE subscription covers managed infrastructure and software licensing, but implementation is a separate conversation with your partner. Mid-to-large enterprise Private Cloud implementations regularly run from $1 million to $5 million or beyond in consulting and project costs alone. First-year total investment sits considerably above Public Cloud in almost every scenario.

Which Edition Has a Lower Total Cost of Ownership?

Three to five year horizon, same standard processes, Public Cloud wins on TCO. The savings compound across implementation speed, infrastructure, and upgrade overhead.

Private Cloud is more expensive, full stop. The only context where the comparison gets complicated is when Public Cloud genuinely cannot meet your requirements. At that point TCO is beside the point, you don’t have a choice.

Should You Choose SAP S/4HANA Public Cloud?

Speed matters to you. Cost efficiency matters. Your business can operate within SAP’s standard process templates without significant customization. Those three things together make Public Cloud a strong fit.

It works best for first-time SAP implementations, mid-market organizations without large internal IT teams to manage complexity, and businesses in sectors where standard ERP processes cover 80% or more of operational reality.

Where it breaks down: if your business has genuinely differentiated processes that don’t fit a standard SAP template, Public Cloud becomes a constraint rather than an enabler. A SAP cloud migration strategy review against your current landscape will surface that quickly.

Should You Choose SAP S/4HANA Private Cloud?

When Public Cloud’s walls are genuinely walls, not just inconveniences, Private Cloud is where you end up.

Complex ECC landscapes. Custom code that your operations depend on daily. Industries where regulators dictate how data gets stored and who controls it. None of those realities fit the shared-infrastructure, standard-process model of Public Cloud.

For SAP ECC customers specifically, the brownfield migration path in Private Cloud is usually the most practical route. Years of configurations and custom development don’t get abandoned, they get modernized and carried forward. The alternative, rebuilding from greenfield in Public Cloud, only makes sense when the legacy system is more burden than asset.

Longer timelines and higher costs are real. Going in with that expectation set is better than discovering it halfway through a project.

How Does the SAP ECC to S/4HANA Migration Work in 2026?

2027 is closer than it feels. SAP ECC mainstream maintenance ends that year, and for large enterprises with complex landscapes, “we’ll deal with it next year” stopped being a viable strategy about 18 months ago.

The lead time problem is what catches organizations out. Scoping, budget approval, vendor selection, internal alignment, that process alone runs six to nine months before a single consultant starts technical work. The migration itself for a mid-to-large enterprise runs another twelve to eighteen months. Do that arithmetic and organizations starting planning conversations now in 2026 are the ones who’ll actually cross the line properly. Everyone starting in late 2026 is running a tight schedule. Anyone waiting for 2027 is in trouble.

The migration approach depends entirely on which edition you’re moving to. Public Cloud requires a greenfield redesign, your processes get rebuilt around SAP’s standard templates, and legacy code doesn’t come with you. Private Cloud allows brownfield conversion, existing ECC configurations, custom code, and data get migrated across while the underlying technical foundation upgrades. Neither is simple. The right call comes down to how much of your current system is worth preserving.

For the full methodology, SAP S/4HANA migration services covers what each stage looks like in practice. Strategic planning conversations start well in the SAP cloud migration strategy guide.

Stat Callout: SAP ECC mainstream maintenance ends in 2027. Organizations starting migration planning now have roughly 12 to 18 months to execute before the deadline becomes a crisis.

What Should You Look for in an SAP Implementation Partner?

Getting the edition right is half the decision. The partner is the other half. And that second half is where a lot of otherwise sound projects fall apart.

The most common version of this: a technically qualified partner who doesn’t know your industry well enough. SAP implementations in manufacturing bear almost no resemblance to those in financial services, pharmaceuticals, or retail. The compliance requirements are different. The process nuances are different. The integration landscape is different. A partner coming in to learn your sector on your project timeline and your budget is a risk you don’t need to carry.

Check their methodology for your specific edition. Public Cloud and Private Cloud implementations aren’t just different in scope, they follow fundamentally different approaches. A partner with a defined Public Cloud methodology should not be pitching the same framework for a complex Private Cloud ECC migration. If they can’t clearly articulate what changes, that’s worth probing.

Ask direct questions about scope management before you sign anything. Timeline slippage and scope creep are the two most cited complaints in SAP project post-mortems. Partners who surface the risks before contract signature, not after, are showing you something about how they’ll manage the rest of the engagement.

And find out what happens after go-live. The project end is not the system end. Business requirements change, edge cases surface in production that testing never caught, integrations develop problems months later. A partner who hands over documentation and disappears at cutover is a liability, not a resource.