Position-based management means every employee sits in a defined position — a position has a job code, department, cost centre and reporting line. Hiring requires an open position; you cannot hire without one. This provides strict headcount control and makes succession planning straightforward (you plan for positions, not people). Headcount-based management is less structured — departments have target headcounts, but individual positions are not pre-defined. Hiring is controlled by department-level approval rather than position vacancy. Most enterprise implementations choose position-based management because it provides the governance and reporting granularity that finance, audit and compliance teams require. This decision must be made early because it fundamentally shapes how the org structure is built, how hiring workflows operate and how headcount reporting works. Changing from one to the other post go-live is a major re-implementation.

Employee Central uses a single global instance with country-specific configuration layers. The global data model (org structure, job information, employment records) is consistent worldwide, but each country adds local fields, business rules and compliance requirements on top. Country-specific elements include: statutory fields (social security numbers, tax identifiers), local pay components and frequency rules, country holiday calendars, time-off entitlement rules based on local labour law, and statutory reporting requirements. Each country is a localisation configuration exercise — SAP provides country packs for 200+ countries that include the standard statutory requirements, but every organisation has country-specific policies that need configuration above the standard. We scope each country individually based on actual HR policy complexity, employee count and local regulatory requirements — not on a fixed per-country multiplier.

The minimum: current employee snapshot (active employees with current job, compensation, org assignment and personal data). Beyond that, it depends on business need. Employment history (hire dates, transfers, promotions) is commonly migrated because managers and HR need to see an employee's career trajectory. Compensation history (prior salary changes, bonus records) is useful for compensation planning and pay equity analysis. Prior performance ratings are occasionally migrated for succession planning context. Address and emergency contact history is rarely worth migrating. Our general guidance: migrate what your HR team will actively reference in daily operations and what compliance requires for audit purposes. Everything else can be archived in the legacy system and accessed on demand. Migrating data that no one uses adds cost and complexity to the project without adding value — and every additional data category increases migration testing effort.

MDF (Metadata Framework) is Employee Central's extension mechanism — it allows you to create custom data objects, fields, picklists, business rules and associations without writing code. Think of MDF as a no-code data modelling tool built into SuccessFactors. When your organisation needs to track data that Employee Central's standard model does not cover (certifications, work permits, equipment assignments, custom compliance records), MDF objects are how you extend the system cleanly. The key advantage: MDF objects are configuration, not custom code — they survive quarterly releases, support role-based permissions and participate in standard workflows and reporting. The common mistake: using generic objects (custom MDF tables) where SAP provides standard objects with built-in business logic. Our approach uses standard EC objects wherever they exist and MDF only for genuinely custom requirements — because standard objects receive feature enhancements from SAP while MDF objects do not.

Single-country Employee Central with basic payroll integration: 3–5 months. Multi-country (2–4 countries) with S/4HANA integration and position management: 5–8 months. Large-scale global deployment (5+ countries, complex integration landscape, SAP HCM migration): 8–14 months phased across country waves. The process discovery and data model design phase (3–4 weeks) is included in all timelines and is non-negotiable — it determines the success of everything that follows. We always recommend aligning go-live with a natural HR cycle boundary: start of fiscal year, beginning of a benefit enrolment period or start of performance review cycle. Mid-cycle go-lives create reconciliation overhead and double-entry periods that are entirely avoidable with timing alignment.