ERPClimb logoERPClimb
S/4HANA changeObjectSAP HCM on S/4HANA and the move to SuccessFactorsModuleHCM_SUCCESSFACTORS

HCM on ECC versus SuccessFactors on S/4HANA

On-premise HCM (Personnel Administration, Organizational Management, Time, Payroll) is not part of the S/4HANA core and is not converted along with finance and logistics. SAP's strategic direction is SuccessFactors Employee Central as system of record for people data, with on-premise HCM either retained as a separate system or retired in phases, connected to S/4HANA finance through integration rather than a shared client.

This page covers how classic HCM ran inside ECC as an integrated PA, OM, Time and Payroll suite in the same client as finance, and how that changes once a system moves to S/4HANA and adopts SuccessFactors. It focuses on what breaks operationally for reporting, authorizations and payroll cutover, and the sequencing decisions a project has to make before conversion, not after.

Reviewed by an ERPClimb SAP consultant on 23 Sept 2026· 1,183 words

Esta página ainda não está disponível em português.

Classic ECC behaviour

In ECC, HCM runs natively alongside FI, CO, MM and SD in the same system, often the same client. Personnel Administration stores employee master data in infotypes (0000, 0001, 0002, 0008 and hundreds more) maintained through PA20 and PA30. Organizational Management holds positions, jobs and reporting lines in the HRP/HRT structures, maintained mainly through PPOME. Time Management and Payroll read PA and OM data directly, and the payroll driver posts results straight into FI/CO using the same cost center and company code master data logistics already uses. Reporting runs on ad hoc query, HR queries and logical database PNP, all reading PA tables directly. Structural authorization controls who can see which employees based on org structure, layered on top of standard authorization objects. Because everything sits in one client, an org reassignment, a cost center change or a payroll posting run is a same-system, same-day operation with no replication lag and no interface to monitor.

S/4HANA behaviour

SAP no longer positions on-premise HCM as the strategic HR system. SuccessFactors Employee Central becomes the system of record for employee master data, using foundation objects and a position-based org model that is structurally different from PA infotypes and HRP structures. On-premise Personnel Administration, Organizational Management, Time and Payroll can continue to run, but SAP's direction is to run them as a separate, standalone system alongside S/4HANA rather than embedded inside the S/4HANA core client used for finance and logistics. Payroll can stay as on-premise SAP Payroll on that separate HR system, or move to Employee Central Payroll running on its own instance. Employee and org data needed by S/4HANA (cost center assignment, employee responsible fields, workflow approvers) is replicated in from SuccessFactors through integration middleware rather than read directly from PA tables, because those tables are no longer the master. The result is a multi-system landscape: SuccessFactors for HR master data, an HR system for payroll and time if kept on-premise, and S/4HANA for finance and logistics, joined by point-to-point or middleware-based integration instead of shared database tables.

Project impact

The practical fallout lands on reporting, authorizations, integration monitoring and user habits, roughly in that order of pain.

  • Custom ABAP reports and ad hoc queries reading PA infotype tables directly return empty or stale results once Employee Central becomes the master, because the authoritative record has moved off that database
  • Structural authorization built around PA/OM org structure has to be replaced by SuccessFactors role-based permissions; testing tends to focus on who can see data and misses who should be blocked, which surfaces as a data privacy incident rather than a bug ticket
  • HR business partners and managers who know PA30 and PPOME screens have to relearn the SuccessFactors UI for the same daily tasks, and adoption resistance shows up as shadow spreadsheets during the transition
  • Interfaces to third-party time, benefits or travel systems that pointed at PA tables or BAdIs on the HCM system need to be re-pointed at Employee Central or the replicated data set, and each one is a separate integration build
  • Month-end and payroll posting timing changes because payroll now runs on a system that is one or more replication hops away from S/4HANA finance; posting errors surface as suspense entries when cost center validation timing differs between the two systems
  • Cost center and org unit master data changes in S/4HANA finance no longer automatically align with SuccessFactors foundation objects, so a routine org restructure has to be coordinated across two systems on two release cycles

Migration actions

The sequencing matters more than the individual tasks; the split decision is a pre-conversion gate, not something to sort out afterward.

  • Decide the future-state HR landscape before touching the S/4HANA conversion: on-premise HCM stays as its own standalone system, moves fully to SuccessFactors Employee Central, or runs a hybrid with EC for master data and on-premise payroll retained; this decision blocks the conversion project plan and cannot be deferred
  • If HCM currently shares a client with the modules being converted, split it out into its own system first; this is a mandatory pre-conversion step, not optional cleanup
  • Inventory every custom report, interface and workflow that reads PA/OM tables directly and classify each as retire, redirect to replicated data, or rebuild against the SuccessFactors API
  • Map PA infotypes and HRP org objects to Employee Central foundation objects and business rules; this remapping is where hidden local customizations (custom infotypes, custom wage types feeding org logic) get discovered
  • Build and test the replication integration for employee and org data feeding S/4HANA cost accounting, including error handling for rejected records, before any parallel payroll run starts
  • Redesign authorizations from structural auth to role-based permissions and test negative access scenarios explicitly, not just positive ones
  • Run parallel payroll across at least one full cycle, including any retroactive or off-cycle runs, and schedule cutover on a payroll period boundary, never mid-cycle

Whose problem this is

Both functional and technical teams own pieces of this, but the overall direction is a business decision, not a technical migration call. HR leadership and IT strategy jointly decide whether to retain on-premise HCM, adopt Employee Central fully, or run hybrid, because the choice drives licensing cost, headcount for two skill sets, and the org's appetite for change management on the user side.

Common pitfalls

Several problems only show up once real payroll volumes and real org changes hit the new landscape.

  • Retroactive payroll spanning the cutover date gets calculated against inconsistent master data because one system has the old org assignment and the other has the new one
  • Ad hoc queries and legacy HR forms pass in unit testing against a small sample but fail in production because they silently return partial results instead of erroring out, and nobody notices until a manager complains a report is wrong
  • Replication integration tested with a handful of employees works fine, then times out or drops records during a mass salary review or annual reorganization batch update
  • Global employees with concurrent employment or international assignments, modeled one way in on-premise OM, do not map cleanly onto Employee Central's foundation object model, breaking scenarios that worked for years in ECC
  • Cost center validation differences between Employee Central and CO cause postings to land in suspense accounts at month end, discovered only when finance closes the books
  • Structural authorization gaps are found by an auditor or an employee who notices they can see a colleague's record, not by the test team, because negative-access testing was skipped

Take the next diagnostic step

Use these ERPClimb resources to explore the scenario. Verify all actions in your SAP system before making production changes.

Related SAP objects

Reviewed pages this object connects to in the ERPClimb knowledge graph.

Source: ERPClimb — https://erpclimb.com/sap-s4hana-changes/sap-hcm-on-s-4hana-and-the-move-to-successfactorsERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.