From Legacy To Cloud: My Brownfield Checklist For ...

From Legacy to Cloud: A Practitioner's Brownfield Checklist for SAP ECC HR to SuccessFactors EC & EC Payroll

Targeted at SuccessFactors Consultants navigating real-world brownfield migrations

About This Blog

Brownfield migrations from SAP ECC HR to SuccessFactors are deceptively complex. Unlike greenfield implementations, you carry the weight of years of customisation, embedded business logic, and data dependencies. This blog is written from the perspective of a Solution Architect who has navigated these journeys — it is not a marketing brochure but a field-tested checklist.

Use it as a structured companion throughout your project. Verify each item per your landscape. No two brownfields are the same.

01 — Discovery & Current State Assessment

Before a single configuration screen is touched in SuccessFactors, you must have an exhaustive picture of what exists in ECC. This phase shapes every downstream decision.

1.1 Current State Analysis

Audit all active SAP ECC HR modules in scope: PA, OM, PY (Payroll), TM (Time Management), Benefits, etc.
Document every custom Z-program, BADi, user exit, and enhancement — categorise by criticality and usage frequency
Inventory all interfaces: IDocs, RFCs, BAPIs, and file-based integrations connecting ECC to third-party systems (banking, attendance, GL, Benefits providers)
Identify every custom infotype and non-standard configuration — these have no direct SF equivalent and must each be resolved
Review existing payroll schemas, Personnel Calculation Rules (PCRs), and the full wage type catalogue
Analyse Features, Dynamic Actions, and User Exits in detail — map each one to an equivalent Business Rule or workflow in SF

1.2 Gap Analysis

Map every ECC HR function to its SuccessFactors equivalent — create a formal Gap Register
Flag every gap where standard SF functionality does not cover ECC custom logic — these will become extension or workaround items
Identify all country-specific legal and statutory payroll requirements; this is critical for EC Payroll scoping
Catalogue all output documents: SAP Scripts, SmartForms, Adobe Forms — each needs a SF equivalent or a third-party solution

📋Architect's Tip — Structure First, Then Processes

Resist the temptation to re-design everything at once. In a brownfield, adopt the customer's existing Enterprise, Personnel, and Pay structure into Employee Central first. Avoid changes here as they create ripple effects across configuration, data migration templates, and reporting. If process improvements are desired, use SAP Signavio to visualise, compare, and plan changes in a controlled manner — separate from the core migration track.

02 — Architecture & Landscape Planning

Define the target architecture (suitable through LeanIX application) before any configuration commences. Ambiguity here is expensive to correct later.

Decide on deployment model: full cloud (EC + EC Payroll) or a phased hybrid (EC as master, on-premise payroll temporarily retained)
Define Employee Central as the System of Record for all HR master data — this is non-negotiable in a full brownfield
Plan your middleware and integration strategy: SAP Integration Suite (BTP/CPI) is the SAP-recommended route; evaluate Dell Boomi or MuleSoft only if already in the landscape
Design the EC to EC Payroll replication model — understand what triggers payroll-relevant data sends and configure accordingly
Use SAP Cloud ALM (CALM) to manage the project, track test cases, monitor issues, and maintain deployment readiness — this should be agreed from Day 1

📋Architect's Note — Post S/4 2025 Prerequisite Check

If your customer is on or migrating to S/4HANA 2025+, Cost Centre replication must happen through the Master Data Integration (MDI) channel — not through the older ALE or direct CPI approach. Additionally, newer EC Payroll systems come with a modernised technical stack. Always verify these prerequisites before finalising your integration blueprint. Missing this has caused significant rework on projects.

03 — Code & Object Harmonisation Strategy

This is an often-overlooked step that pays enormous dividends during data migration and integration testing.

Where operationally feasible, retain the same codes for Pay Structures, Absence types, and Wage Types in both EC Payroll and SuccessFactors EC as existed in ECC
Identical codes in source and target systems dramatically simplify data migration template preparation, UAT reconciliation, and interface payloads
Document every case where a code must change and maintain a cross-reference mapping table — this becomes the Rosetta Stone for your migration team
Ensure wage type mapping is signed off by the payroll team, not just IT — business meaning of wage types must be preserved exactly

04 — Data Migration Strategy

Data migration in a brownfield is the highest-risk workstream. Years of accumulated ECC data — clean and otherwise — must land correctly in SF. Plan exhaustively.

4.1 Master Data

Extract and cleanse PA and OM infotype data from ECC before creating migration templates
Map every relevant ECC infotype / Custom Infotype to its SF EC portlet (Standard or Custom) and associated picklist values
Determine historical data scope: how many years of payroll history must be available in the new system for reporting and statutory purposes
Migrate all open items with precision: outstanding loans and advances, carry-forward leave balances, tax declarations, and provident fund histories

4.2 Key Data Objects

Personal and employment data: IT0000 through IT0009, IT0016, IT0019, and other active infotypes
Org structure: Org Units, Positions, Jobs, and all relationships between them
Payroll cumulations and results (mandatory for mid-year go-lives)
Benefits enrolments, leave balances, and bank account details

⚠️Architect's Warning — Data Quality Before Migration

Never attempt to cleanse data after migration into SF. Dirty data in SF is significantly harder to fix than in ECC due to UI constraints and validation rules. Run automated data quality checks on ECC extracts first: duplicate employee IDs, missing mandatory fields, invalid relationships, and expired assignments. Fix in ECC, then migrate. This sequencing alone prevents the majority of data migration defects seen in the field.

05 — Employee Central Configuration

Build the Foundation Object hierarchy precisely: Company → Business Unit → Division → Department → Location — get sign-off before building dependents
Configure Event Reason Derivation rules with care — these drive payroll triggers downstream and incorrect rules cause missed pay changes
Set up Position Management to replace ECC OM, if in scope
Configure the Time Off module to replace ECC Time Management absence processing (see Section 6 for positive time complexity)
Define Business Rules to replace ECC Dynamic Actions, Features, and User Exit logic — each requires individual design and testing
Set up Workflow and Approval chains to replace ECC workflow, ensuring delegation and escalation paths are covered

06 — Time Management Migration (High Complexity)

Time evaluation is frequently the most technically demanding workstream in a brownfield. Do not underestimate it.

Perform a detailed analysis of all on-premise Time Evaluation schemas and rules before designing SF Time Tracking configuration
Map every time evaluation rule to its SF equivalent — gaps require workarounds that must be documented and signed off by the business
If the customer is on Positive Time Management in ECC (clocking in/out for all employees), the complexity doubles — assign a dedicated time specialist
Assess the Attendance Recording System (ARS) connected to ECC: if it does not already clean and convert raw clock data into First-In / Last-Out records, this conversion must happen at the ARS before data reaches SF Time Tracking — do not attempt this transformation inside SF
Validate overtime rules, break deductions, and shift differential logic independently — these are the most common sources of payroll variance

07 — EC Payroll Configuration

EC Payroll uses the same underlying payroll engine as ECC Payroll. However, the delivery model, prerequisites, and integration patterns are fundamentally different.

7.1 Payroll Schema & Rules

Re-implement ECC payroll schemas and PCRs in EC Payroll (if you are not using any Lift and Shift tool) — do not assume identical behaviour without regression testing each rule
Migrate the full wage type catalogue and validate the mapping against ECC — involve the payroll team in sign-off
Recreate all custom payroll functions and operations; document each one with its business purpose

7.2 Legal & Statutory Compliance

Configure all statutory requirements per country: PF, ESI, TDS and Form 24Q for India; PAYE and P60 for UK; W-2 and 941 for USA; country-specific equivalents for others in scope
Set up off-cycle payroll, advance payment processing, and payroll reversals before UAT
Configure and fully test Year-End processes: Form 16, W-2, P60, or local equivalents — do not leave these to post-go-live

7.3 Payroll Control Center (PCC)

Payroll Control Center is mandatory for EC Payroll and is not optional — plan configuration time accordingly
Configure PCC alert rules, validation checks, and monitor groups to replicate the pre-payroll checks previously done manually in ECC
Design the full pre-payroll, payroll, and post-payroll process flow within PCC and train the payroll team on it before go-live

📋Architect's Note — DME / Bank Payment Files

Review the bank payment (DME) procedure used in the legacy ECC system carefully. If the customer uses a non-standard DME configuration or a custom bank integration, plan the migration of this integration from ECC to EC Payroll as a separate workstream. Bank file failures on pay day are not acceptable — test this end-to-end, including the bank's own validation, before go-live.

08 — Integration Architecture

Integrations are where brownfield projects most commonly fail on Day 1. Every connection from ECC to an external system must be assessed, redesigned, and tested.

8.1 SAP-Recommended Integration Patterns

Use CPI (SAP Integration Suite) for: Cost Centre replication, GL account master data, and Bank key replication from S/4 Finance to EC Payroll
Use ALE (IDoc-based) for: posting the payroll accounting document from EC Payroll to S/4 Finance — this is the SAP-supported pattern and should not be deviated from without strong justification
Post S/4 2025: Cost Centre replication must use Master Data Integration (MDI) exclusively — validate this requirement against the customer's S/4 release before finalising the integration blueprint

8.2 Integration Inventory

Third-party Time & Attendance systems: re-evaluate the interface; ARS raw-data transformation must happen upstream, not inside SF
Benefits providers: map existing file-based or API integrations from ECC to equivalent SF integrations
GL Posting: reconfigure payroll-to-FI symbolic account assignments and posting key mappings
Banking / DME: re-implement or migrate bank file generation as a dedicated workstream
Custom ABAP reports: each must be evaluated individually — replace with SF Story Reports, Workforce Analytics, or retain on-premise where justified

09 — Parallel Payroll & Testing

This is the most critical phase for an EC Payroll go-live. It is non-negotiable and should not be compressed regardless of schedule pressure.

Run a minimum of 2 to 3 parallel payroll cycles with ECC and EC Payroll running simultaneously on the same period
Perform gross-to-net variance analysis at the individual employee level — do not accept aggregate totals as proof of correctness
Investigate and formally resolve every variance before approving cutover — even small amounts indicate logic differences that will compound over time
Conduct UAT with the actual payroll operations team, not only with IT — their domain knowledge is essential to validating results
Test all payroll edge cases explicitly: retroactive changes, new joiners mid-month, mid-month exits and full-and-final settlements, maternity and paternity pay, statutory deductions, and arrear processing
Keep enough timeline buffer specifically for mid-year go-live scenarios — YTD balance migration and reconciliation adds significant effort that is routinely underestimated

10 — Cutover Planning

Define the cutover weekend activity list with named owners, time slots, and dependencies — this document must exist weeks before go-live, not days
Freeze all ECC payroll transactions during the cutover window — agree the freeze date formally with business stakeholders
Perform the final data extract and delta migration (changed records since the initial load) as the first cutover task
Run and sign off the initial payroll in EC Payroll during the cutover weekend before declaring go-live
Prepare a documented rollback plan: define the specific criteria that would trigger a rollback and the steps to execute it — even if you never use it
Coordinate bank and payment file generation timing with Finance and Treasury — payroll and banking are tightly coupled; misalignment causes payment delays

11 — Change Management & Training

Technology rarely fails a SuccessFactors implementation. People and processes usually do.

ECC HR users have deep muscle memory for the SAPGUI interface. The SF Fiori-style UI represents a paradigm shift — invest in change management proportionally
Conduct separate, role-based training sessions for HR Administrators, Payroll Processors, Line Managers, and Employees — their workflows and touchpoints are completely different
Create concise role-based job aids and reference cards, not lengthy manuals — users on go-live day need quick guidance, not a textbook. WalkMe is SAP's recommended tool for change management
Establish a Hypercare support model covering at least the first 2 to 3 payroll cycles post go-live, with dedicated expert availability

12 — Post Go-Live Stabilisation

Monitor the first three payroll runs with heightened vigilance — assign your most experienced payroll consultant to be available throughout each run
Establish a clear support escalation path between the SF cloud operations team, your functional consultants, and the customer's Basis/ABAP team for any technical issues
Validate all third-party integrations end-to-end after go-live — do not assume they are stable because they passed UAT
Reconcile year-to-date balances carefully, especially for mid-year go-lives, before closing the first payroll month
Schedule a formal Post-Implementation Review at 90 days to assess stability, identify improvements, and document lessons learned

Risk Register: What to Watch

Risk / Challenge Mitigation Strategy

Mid-year go-live payroll balances	Perform thorough YTD migration validation + minimum 2–3 parallel payroll runs before cutover
Custom payroll logic gaps (schemas, PCRs, BADIs)	Early PCR/schema review in Phase 1; map every custom object before configuration begins
Integration failures on Day 1	Full end-to-end integration testing with finance, banking, and third-party systems pre-cutover
Employee data quality issues	Data cleanse before migration, not after — run data quality reports during Discovery phase
Legal/statutory non-compliance	Country-specific legal sign-off from HR compliance team; validate payroll results with tax advisors
Time evaluation rules complexity	Engage a dedicated time consultant early; positive time management doubles the complexity
MDI prerequisite gaps (post S/4 2025)	Check modernised stack prerequisites before planning; replicate cost centres only via MDI post S/4 2025
Resistance to UI paradigm shift	Invest in Change Management early; role-based training before go-live, not at cutover

Final Thought

A brownfield SuccessFactors implementation is not a product installation — it is a business transformation. The checklist above is your technical compass, but the journey requires equal parts rigour, stakeholder partnership, and honest risk management.

No shortcut in planning is ever recovered later. Plan thoroughly. Test honestly. Communicate openly.

SAP SuccessFactors — Solution Architect's Field Guide — Brownfield Migration Checklist

Source link