Best practices for time and attendance data migration in wd-r1-2023

Our organization is planning a time and attendance migration to Workday R1-2023 and I’d like to hear from others who’ve completed similar projects. We’re debating how much historical time data to migrate versus what to keep in the legacy system for reference only.

Specifically interested in experiences around:

  • How far back did you migrate time entry history?
  • Did you migrate time off balances only, or full transaction history?
  • What validation strategies worked best for ensuring data accuracy?
  • Any gotchas with historical data that affected payroll or compliance reporting?

We have 7 years of time and attendance data in our current system covering 2,800 employees. Our initial thought is to migrate 2 years of history to support trending analysis and audit requirements, but I’m curious what others have found to be the sweet spot between completeness and complexity.

The compliance angle is a good point - we have similar FMLA tracking requirements. Did you use Workday Studio for the migration, or standard EIBs? How did you handle employees who had multiple time off plan changes during the historical period?

Based on multiple time and attendance migrations, here’s my comprehensive perspective on the key focus areas:

Data Mapping Strategy: The critical decision is determining what constitutes “required” versus “nice to have” historical data. For regulatory compliance, you need enough history to demonstrate adherence to FMLA, state leave laws, and collective bargaining agreements - typically 2-3 years. For operational purposes, current balances plus 1 year of transactions usually suffices. Map your source time off types to Workday time off types carefully - differences in accrual frequencies, carryover rules, or caps will cause balance discrepancies. Create a detailed mapping document that shows how each source time type converts to Workday, including any business rule changes. For time entry history, consider migrating only exception-based entries (absences, overtime) rather than every regular hour worked - this reduces volume significantly while preserving audit trail.

Validation Approach: Implement validation at three levels. First, validate source data completeness and quality before extraction - identify employees with negative balances, missing accrual rates, or orphaned transactions. Second, validate reference data resolution during transformation - every time off type, worker ID, and position must resolve to valid Workday references. Third, validate results post-load through reconciliation reports. Build automated balance reconciliation comparing source system to Workday by employee, time off type, and balance date. For transaction history, validate that transaction counts and hour totals match between systems. Set tolerance thresholds - we used 4 hours variance as acceptable given rounding differences in accrual calculations. Any variance beyond tolerance requires root cause analysis and correction before proceeding.

Historical Data Considerations: Older data presents unique challenges. Time off plans may have changed multiple times - different accrual rates, carryover rules, or caps. Document these changes and decide whether to migrate with original plan rules or adjust to current configuration. For employees who transferred between locations or changed eligibility status, their time off history may span multiple plan assignments. Consider consolidating to their current plan for simplicity, but preserve original transaction dates for audit purposes. Historical data quality issues are common - duplicate transactions, manual adjustment entries without documentation, or balance corrections that weren’t properly recorded. Build exception handling into your Studio integration to flag these anomalies for manual review rather than loading bad data into Workday.

One often-overlooked aspect: coordinate with payroll on the cutoff strategy. If you migrate mid-pay-period, you’ll need to handle partial period accruals carefully to avoid double-accruing or missing accruals. We recommend migrating at pay period boundaries to simplify reconciliation.

Finally, don’t underestimate the effort required for validation and reconciliation. Plan for 40-50% of your migration timeline to be dedicated to data quality activities rather than just the technical load process.

Validation strategy is critical. We created a three-tier validation approach: 1) Pre-migration validation in the source system - clean up bad data before extraction, 2) Transformation validation in Studio - verify all lookups and mappings resolve correctly, 3) Post-migration reconciliation - compare loaded data in Workday against source totals. For time off balances specifically, we generated balance reports from both systems as of the migration cutoff date and reconciled them employee by employee. Any discrepancies over 8 hours triggered manual review. This caught issues with pending time off requests that weren’t included in the balance calculations. Historical data quality degrades over time, so the further back you go, the more cleanup you’ll need.

For time and attendance, we used a combination approach. Current time off balances loaded via the Time Off Balance EIB - that’s straightforward. For transaction history, we built a custom Workday Studio integration that called the Submit Time Off web service to create historical transactions. This preserved the transaction dates and reasons accurately. For employees with plan changes, we loaded their transactions chronologically and let Workday’s accrual engine recalculate based on their current plan configuration. One gotcha: make sure your time off types in Workday exactly match your source system categories, including the accrual frequencies and carryover rules, or historical balances won’t reconcile correctly.

We typically recommend migrating only current time off balances and 1 year of transaction history for most clients. The validation effort increases exponentially with more historical data, and older data often has quality issues that require extensive cleanup. For audit purposes, keep the legacy system accessible in read-only mode rather than trying to migrate everything. Focus on getting current balances accurate - that’s what actually impacts ongoing operations.