A multi-hospital US health system with a workforce of more than 12,000 wanted its legacy Kronos workforce-management environment switched off — without losing the timekeeping history that HR, payroll, finance and audit still depend on. In 2025, Syntra ETL extracted, reconciled and archived that history into DataVault, stood up a browser-based archive with an Employee 360° view and a full report set, and took the health system through a ten-stage decommissioning process to sign-off. The objective was never a database export — it was a historical archive people can actually use once Kronos is gone.
The health system had moved on from its legacy Kronos workforce-management environment operationally — but could not switch it off, because years of timecards, punches, accruals and approvals still had to be retrievable for payroll queries, HR investigations, audits and compliance requests.
Keeping a retired workforce-management application alive purely for read access is an expensive habit: licences, databases, servers, and a shrinking pool of people who still know how to navigate it. Every year it stays up, the cost recurs and the expertise thins.
The obvious alternative — dump the Kronos tables into a database and call it an archive — fails the first time somebody needs an answer. Raw timekeeping tables are unreadable without the reference data that gives them meaning: what a pay code represents, which work rule applied, how a punch maps to a pay period. The requirement was therefore a usable archive: searchable, reportable, exportable, and complete enough that the business would sign off on decommissioning the source.
Retiring a timekeeping system for a 24/7 clinical workforce is a different problem from archiving a finance ledger.
A punch means nothing without its pay code, work rule, pay period and employment record. Configuration and reference data were archived alongside the transactions so historical entries can still be interpreted years later.
Employees to timecards, timecards to punches, punches to pay codes, pay codes to pay periods, all to departments and cost centres. Flatten those relationships and you have files, not an archive.
At the scale of a multi-hospital system, the archive holds detailed workforce records for thousands of clinical and non-clinical staff. Security and auditability were treated as core design requirements, not optional archive features.
The existing Kronos report estate had accumulated over years. Rebuilding all of it would have been waste; losing the wrong one would have been a compliance gap. Each report was triaged before anything was rebuilt.
Because the source was going to be switched off, "looks right" was not good enough. Record counts, employee populations, transaction volumes and hours totals all had to reconcile between Kronos and the archive, with evidence.
Timekeeping, payroll-related and HR records carry different legal and regulatory retention obligations. The archive had to support per-category retention rules and controlled purge — not one blanket policy.
Eighteen data areas, covering transactional history and the reference data needed to interpret it.
Detail on each area: time, attendance, schedules & workforce history · data retention · Kronos Workforce Central connector.
Historical Kronos data lives in DataVault — a structured archive built for retaining information from systems being decommissioned, not a general-purpose database.
Data retained in its original or normalised structure, so historical information stays traceable back to the source system.
The links between employees, pay periods, timecards, punches, pay codes and departments are maintained rather than flattened.
Archived records keep source-system identifiers and migration metadata, so any row can be tied back to where it came from.
Authorised users search, view, drill down, report and export through a browser — search → view → drill down → report → export, with no access to Kronos required.
Access controlled by user role and data-access requirement, with restricted access to sensitive workforce information.
Retention configured per record category — Kronos record → retention rule → archive period → controlled purge — with nothing purged outside approved rules.
Search criteria include employee ID and name, department, location, pay period, date range, pay code, job, cost centre, employment status and timecard status. See Kronos legacy data access and cloud archive.
More than twenty-five standard reports run against the archive rather than against Kronos — which is what allows them to keep working after the source is decommissioned.
Every existing Kronos report was reviewed during discovery and classified into one of three outcomes — retire (no longer required), archive as data only (information retained, no dedicated report needed), or recreate in Syntra (a continuing business or audit requirement). Only the third category was rebuilt. That avoided recreating an entire legacy report estate for its own sake while guaranteeing that critical business and compliance reporting survived the retirement.
See Kronos historical reporting, reporting after migration and the historical reporting solution.
Individual reports answer known questions. Most historical enquiries are not like that — someone asks about one employee and one period, then follows the thread. So alongside the report set, the archive provides a single employee-centred view: search once, then navigate.
In practice: an HR or payroll user investigating a historical query searches for the employee, selects a year or pay period, and retrieves the relevant timecard with its supporting detail — without a Kronos login, and without anyone reading raw database tables.
When the source application is going to be switched off, data completeness stops being a quality measure and becomes the precondition for the whole programme. Reconciliation evidence was produced as part of sign-off.
Source count equals archive count, across every major entity.
The employee population reconciled by active and terminated staff, employment periods, departments and locations.
Timecard counts, punch counts, pay-code transactions, hours by pay period, hours by employee, overtime hours and accrual transactions.
Where the source information permitted, hours and payroll-interface totals reconciled between the source and the archive.
More on this: Kronos migration reconciliation · data validation.
Kronos was not switched off the moment extraction finished. A controlled sequence took the health system from inventory to retirement, with the business holding the gate at each end of it.
Inventory the Kronos data, reports, integrations and downstream dependencies.
Extract the agreed historical data from the Kronos environment.
Load and structure the information inside DataVault.
Automated record-count and control-total reconciliation.
Configure the standard report set and rebuild the agreed critical Kronos reports.
HR, payroll, IT and nominated business users validate the historical information themselves.
Archive and Kronos both available for a short validation period.
Capture any remaining records or changes.
The health system approves archive completeness and historical-access capability.
Legacy Kronos application and infrastructure retired under the customer's own IT process.
Stage detail: migration assessment · cutover strategy · decommissioning · legacy decommissioning guide.
Given the scale and the healthcare operating environment, security and auditability were design requirements from the start rather than features added to a finished archive.
Kronos → DataMove extraction → validation & reconciliation → DataVault → archive access & reporting → Kronos decommissioned.
Secure extraction of the historical Kronos data — the eighteen data areas plus the configuration and reference values — transformed and loaded into the archive, including the final incremental extraction before decommissioning.
The historical repository itself: source-data and relationship preservation, source-system identifiers and migration metadata, role-based security, audit trail, configurable retention — plus the reconciliation evidence behind decommission sign-off.
The reporting and analytics layer over the archive — the standard report set, the rebuilt critical Kronos reports and the Employee 360° historical view that staff use for payroll, HR and audit enquiries.
Historical workforce information remains available without keeping the Kronos application operational.
The supporting databases, servers and associated infrastructure could be stood down where no longer required.
Users query a modern browser-based archive instead of navigating a retired workforce-management system — for many, an improvement on the original.
Historical information stays searchable and can be produced for payroll, HR, audit and other authorised enquiries.
Information retained under approved retention policies rather than by keeping an entire application alive indefinitely.
The same architecture extends to the next application the health system retires — an enterprise decommissioning platform rather than a Kronos-only archive.
Because a table dump is not usable. Historical timekeeping data only makes sense with the reference and configuration data that explains it — pay codes, work rules, pay periods — and with the relationships between employees, timecards, punches and departments intact. The archive preserves both, then puts search, drill-down, reporting and export on top, so business users can answer questions without a database query.
Eighteen data areas: employee, employment and organisation records; timecards, time entries, punches, pay periods and pay codes; schedules, attendance, accruals, exceptions, approvals and adjustments; labor distribution; historical payroll-interface information; audit history; and the configuration reference data needed to interpret all of it.
Through a browser-based archive: search by employee ID or name, department, location, pay period, date range, pay code, job, cost centre, employment status or timecard status; view and drill into the record; run any of the standard reports; and export to Excel, CSV or PDF where permitted. The Employee 360° view lets a user search once and then navigate across profile, employment history, timecards, punches, schedules, attendance, accruals, hours and approvals.
Only the ones that needed to be. Every legacy report was triaged during discovery into retire, archive-as-data-only, or recreate in Syntra. Reports with a continuing business or audit requirement were rebuilt on the platform; the rest were not. That sits alongside a standard set of more than twenty-five archive reports covering employee history, time and attendance, pay and hours, attendance and leave, and scheduling.
Four layers of reconciliation: record counts per major entity, employee population by active/terminated status, employment periods, departments and locations, transaction volumes (timecards, punches, pay-code transactions, hours by pay period and by employee, overtime, accruals), and payroll control totals where the source permitted. Reconciliation evidence formed part of the sign-off package, and the source stayed available in parallel during validation.
All three. DataMove handled secure extraction, transformation and loading. DataVault is the historical repository — source and relationship preservation, traceability, role-based security, audit trail, retention rules and the reconciliation evidence. DataLens provides the reporting and the Employee 360° historical view.
Yes — that was one of the reasons for choosing it. The same architecture extends to the next application an organisation wants to retire, making it an enterprise decommissioning platform rather than a single-system archive. See legacy system archival, and our work retiring five systems at Catholic Healthcare Trust.
If you are paying to keep a workforce-management system alive purely for historical access, we can preserve the history in a searchable, reportable archive and take the application off your estate. Tell us the system and your retention obligations.
Similar Projects
Selected by shared source platform, target platform, industry and project type.