Sage People Migration Best Practices — Hard-Won Lessons

The five sage people migration best practices that separate clean cutovers from delayed ones: (1) inventory Apex, Flow, Visualforce, and Process Builder customizations in week one — not month three — so you size the customization triage realistically; (2) run the schema and custom-field discovery via the Salesforce Metadata API on day one, not via consultant-led workshops, because the live org schema is the only source of truth that matters; (3) pre-extract the Sage People → Sage 50 Payroll / HMRC RTI integration spec in parallel with HCM extraction, never sequentially after; (4) plan UK payroll cutover around tax-year boundaries (6 April) or month-end (28th–end), never mid-month and never near year-end close; (5) time the change-management programme around manager self-service training, because that's the user population whose adoption pace determines whether Fusion HCM feels successful in month one or month three.

Sage People is a Salesforce Platform org. Customers don't always realise how much Apex, Flow, Process Builder, and Visualforce has accreted under the standard product over the years. A typical 5-year-old Sage People org carries 40–120 Apex classes, 20–60 Flow definitions, 15–40 Process Builder processes, and 10–25 Visualforce pages — all of which need a Fusion-equivalence decision before HCM cutover. The best-practice approach reads the Salesforce Metadata API on day one to inventory every artifact, classify each by business purpose (onboarding workflow, custom approval, integration callout, data validation), and produce a four-option decision (native Fusion functionality, HCM Design Studio config, OIC integration, Visual Builder extension, or retire). Customers who skip this until month four discover in month five that 30 of the 60 Flows can't be replicated in Fusion's native model — and the cutover slips.

Custom field cleanup is one of the highest-leverage sage people migration best practices. Most 5+ year Sage People orgs carry 200–500 custom fields across Worker__c, Employment_Record__c, Salary__c, and Leave_Request__c — and the dirty secret is that 40–60% are either unused (no values populated in the last 24 months), redundant (duplicate of a standard field), or replaceable (Fusion has a native attribute that covers the concept). The best-practice sequence: extract a custom-field usage report on day one (% of records with non-null value, last-populated date per field), present it to HR and the business in week two, get a sign-off list of fields to migrate vs retire vs archive-only, then execute the mapping with that pruned set. The result is typically 100–200 fields migrated cleanly instead of 400 fields half-migrated with confusion.

UK payroll cutover is the highest-risk single moment in any Sage People → Fusion migration. Best practice: never cut mid-month, never cut within 30 days of tax-year-end (5 April), and never cut during HMRC peak submission windows (P11D in July, P60 deadline in May). The safe windows are after the May P60 deadline through late June, August through October (avoiding holiday-heavy December and January year-end close), and the first full month of a new tax year (6 April onwards, ideally with cutover on 6 April itself so RTI submissions never split between two systems). For Sage People customers also running TPR pension auto-enrolment, factor pension re-enrolment cycle dates into the calendar — re-enrolment falls every 3 years on the original duties start date, and cutover during the re-enrolment window adds compliance complexity.

Sage People uses Salesforce sharing rules — role hierarchies, criteria-based sharing rules, territory-based sharing, custom Apex sharing — to control which users see which Worker__c, Employment_Record__c, and Salary__c records. Fusion uses a completely different security model (BU-driven, reference-data-set-scoped, position-hierarchy-driven). The best practice is to extract the Salesforce sharing model as a security spec in week two of the project, translate it into Fusion's equivalent security profile / job role / data role / reference data set structure, and validate the translation by comparing 'who can see what' between source and target for a sample of 20–40 users before cutover. Customers who skip this discover at go-live that half their managers can't see their own direct reports' salary records, and credibility evaporates.

For a defined runout period: yes. The best practice is 4–8 weeks of Sage People read-only operation post-cutover for two reasons: (1) production HR and payroll teams need a fallback reference while Fusion adoption stabilises, and (2) UK auditors and HMRC may need access to source data during the first post-cutover audit cycle. Beyond 8 weeks, the answer flips — the Salesforce licence cost becomes hard to justify, and the operational risk of having two HR systems both technically live grows. The best practice is to plan the read-only runout, set its end date in the cutover plan, and execute decommissioning on schedule. The cloud-archive product (queryable Parquet on object storage) handles the long-term retention need at a fraction of the Salesforce licence cost.

Manager self-service is the user experience that determines whether Fusion HCM feels successful. Best practice: identify the top 30–50 managerial actions in Sage People (approve leave, view team headcount, run a salary review, request a position change, view a direct report's history), map each one to its Fusion equivalent, build a side-by-side reference card, and run training in waves grouped by manager seniority and business unit. For employees, the change is smaller (the self-service portal looks different, the payslip URL changes, leave requests live in a new place) — keep employee communication concise (one email two weeks before cutover, one email one day before, one quick-start guide), and don't over-rotate. The biggest change-management risk in Sage People migrations is over-communicating to employees and under-training managers.

The audit-grade documentation package every Sage People → Fusion migration should produce: (1) Apex/Flow/Visualforce inventory with disposition per item, signed by HR and IT; (2) custom-field inventory with migrate/retire/archive decision per field, signed by data owners; (3) sharing-rule translation spec mapping Salesforce sharing model to Fusion security profile, signed by HR and security; (4) UK statutory field mapping spec (NI number, tax code, P11D inputs, pension scheme), signed by payroll and HMRC compliance; (5) cutover plan with go/no-go decision points, signed by the steering committee; (6) reconciliation pack post-cutover showing Sage People vs Fusion at row, headcount, salary-sum, and leave-balance level, signed by HR, payroll, and audit. This package satisfies Big-4 external audit, internal audit, SOX, ISAE 3402, and FCA SMCR governance expectations.