Three Systems, Two Headcounts, One Migration
A retail chain with 2,800 employees across five countries runs on three systems: a legacy payroll platform, an HRIS installed in 2011, and a spreadsheet-based headcount tracker maintained by each regional HR team. Finance reports 2,712 active employees; HR reports 2,884. An initial review finds 46 records marked active for people who left, 118 workers recorded as employees but engaged as contractors, and 73 people on payroll with no HRIS record at all. Duplicate records exist because of name variants and rehires. An access audit also found three former employees whose system accounts were still active more than 60 days after termination. A new global HRIS goes live in five months. The applicable data protection law requires accurate records, defined retention periods and breach notification within a fixed window.
1. In what order do you remediate the data before migration, and what do you deliberately leave unfixed?
Read the worked answer
Migration copies whatever it is given, at scale and at speed. Clean first, but do not aim for perfect - set a threshold and move.
Sequence.
- Agree definitions with Finance and Legal. "Active employee", "headcount", "FTE" and "contractor" need one written definition before anyone reconciles. Much of the 6% gap (2,712 versus 2,884) is a definitional disagreement wearing a data-quality costume.
- Reconcile at record level using a stable key - employee ID, never name. Name variants and rehires are why the duplicates exist.
- Classify before you clean. The 118 workers recorded as employees but engaged as contractors carry tax, benefits and misclassification exposure. That is a legal determination, not an HR admin fix: get Finance and Legal sign-off, then correct the record.
- Resolve the exceptions: the 46 terminated-but-active, the 73 payroll-only records, and the duplicates merged under written survivorship rules - keep the record with the longest continuous history and retain the older ID as an alias.
- Then map fields to the new system.
Left unfixed on purpose: historical job titles, legacy address formats and any field the new platform does not carry. Perfecting data that will not migrate is a distraction from the five-month deadline.
2. Who owns HR data, and what governance would stop this recurring after go-live?
Read the worked answer
Ownership is split and must be written down. HR owns the worker record - identity, job, manager, status, location. Finance owns pay elements and the general ledger mapping. IT owns the platform, access and integrations. Each country has a named data steward who signs off changes in their scope. Without named owners, everyone assumes someone else is checking.
Controls that prevent recurrence.
- Single entry point. Managers and HR enter changes once; payroll and reporting read from the system, never from spreadsheets. Retire the local trackers officially, or they persist unofficially.
- Validation at entry - a termination cannot post without a date, a hire date cannot post-date the start.
- A change log with reason codes, so an auditor can reconstruct why a status changed.
- Quarterly reconciliation of HRIS to payroll and to the access directory, with a named signer.
- Retention rules configured, not documented - the law requires defined retention, and "we delete when we remember" fails audit.
Monthly KPIs: record accuracy on a 50-record sample (target 99%), duplicate rate below 0.5%, count of missing mandatory fields, and reconciliation breaks open longer than 30 days.
3. Three terminated employees retained system access for more than 60 days. How do you handle this, and what do you tell the executive committee?
Read the worked answer
Treat it as a security incident, not a data-quality defect. Data quality is about accuracy; this is unauthorised access to personal data.
Immediately, within 24 hours. Revoke the accounts and confirm revocation with the system owner, not the ticket queue. Pull access logs for the three accounts across the full period: what was viewed, exported, downloaded or emailed. Preserve the logs. Ask the CISO to run the investigation - HR should not investigate its own process failure.
Assess obligations. Under most data protection regimes an exposure involving employee personal data requires a risk assessment and, where the risk is not remote, notification to a regulator and possibly to affected individuals within a fixed window. Legal decides; HR supplies the record inventory of what those accounts could reach. Brief Legal now, not after the investigation closes.
Fix the cause. The termination step in the HRIS is not triggering deprovisioning. Build an automated feed from HRIS status to the identity system, with a same-day service level and a weekly exception report.
To the executive committee: one slide on the incident and remediation, one on migration risk. The honest framing is that records are 6% out of alignment, 118 workers are misclassified and access controls failed - the migration is the forcing function that surfaced all three, not the cause.