UKG Migration Guide: Pro, Pro WFM, and Workday Paths

A UKG migration is a data migration, not a version upgrade. Whether you are moving Workforce Central into UKG Pro Workforce Management, retiring UKG Pro Back Office for Pro Web, consolidating time systems into Pro, or leaving UKG for Workday, the work is employee master, historical time and attendance, accrual balances, schedules, and pay rules. About ninety percent of that data maps cleanly. The remaining ten percent is where these projects lose their timeline.

Key takeaway: UKG positions these moves as platform transitions, and the partners who implement them describe the same moves as reimplementations. The difference matters because the second framing puts data in the critical path. Accrual balances and pay rule logic are the two objects that reliably surface late, and both are cheap to validate before cutover and expensive to correct after payroll has run.

What is forcing UKG migrations now

Several deadlines and product retirements are landing at once, which is why UKG migration volume is high in 2026 rather than spread evenly.

UKG was formed on April 1, 2020 from the merger of Kronos and Ultimate Software. UltiPro became UKG Pro. Kronos Workforce Dimensions became UKG Dimensions and is now UKG Pro Workforce Management (Pro WFM). Kronos Workforce Ready became UKG Ready. UltiPro Time and Attendance became UKG Pro Time and Attendance, commonly abbreviated UTA.

The largest driver is the retirement of Workforce Central, announced in October 2022.

Timeline per RSM's summary of UKG's announcement.

The private cloud date has passed. On premises customers have until March 2027, which as of this writing is roughly eight months of supported runway for a project that partners routinely scope at nine to eighteen months. If you are on premises and have not started, the honest read is that you are choosing between a compressed timeline and running unsupported for a period.

Two smaller retirements are pulling volume as well. UKG is sunsetting the legacy Pro Back Office application in favor of Pro Web, and organizations still running the older UKG Pro Time and Attendance module are being pointed toward Pro WFM. Confirm your specific end dates with UKG directly, because they vary by product line and by contract, and published third party dates for the Back Office sunset are inconsistent enough that I would not plan against them.

One hardware note that catches people: the legacy Kronos 4500 terminal is retired alongside Workforce Central, and Pro WFM customers move to the InTouch DX terminal. That is a procurement lead time sitting inside your project plan.

The main UKG migration paths

Five moves account for most UKG migration work, and they have genuinely different data profiles.

Workforce Central to UKG Pro WFM. The highest volume path and the one the deadlines are forcing. UKG names Pro WFM as the successor and publishes a migration framing for it, but the partners doing the work describe it as a rebuild rather than an upgrade: new integrations, new configuration, retraining, and a data migration. The structural reason is that the two systems organize time data differently. Custom labor calculations built in Workforce Integration Manager do not natively carry across and have to be rebuilt in the target.

UKG Pro Time and Attendance to Pro WFM. Often searched as "UKG UTA to WFM." Organizations running the older Pro Time and Attendance module alongside UKG Pro consolidate onto Pro WFM for the deeper scheduling and pay rule engine. The employee master is already aligned because both sit under UKG Pro, which makes this look easier than it is. The hard part moves entirely into pay rules and accruals, since those are configured differently in the two products.

UKG Pro Back Office to UKG Pro Web. Searched as "migration from UKG Pro Back Office" and "UKG Pro Back Office to UKG Pro Web migration." This is the smallest of the five in data terms and the one most often treated as purely a UI change. Treat it instead as a chance to inventory what your payroll administrators actually do in the legacy application, because processes built around Back Office behaviors do not always have a direct equivalent, and custom reporting built on the old data access patterns generally needs rework.

Consolidating multiple time systems into UKG Pro. Common after acquisitions or where business units bought their own timekeeping. This is a multi source migration with survivorship decisions, which puts it in a different complexity class than any of the single source moves above. Conflicting employee identifiers across systems are the usual sticking point. If the move is specifically outgrowing UKG Ready, the UKG Ready to UKG Pro path covers it.

UKG to Workday. Organizations replacing UKG entirely, usually for suite consolidation reasons. This is the most complete rebuild of the five, because Workday's object model differs fundamentally from UKG's, particularly in how it separates a person from their employment records. We cover this path separately in the UKG to Workday migration guide.

Why these are data migrations, not upgrades

The framing matters because it determines who gets staffed and when the data work starts. When a move is planned as an upgrade, the data workstream gets a line item and a junior analyst. When it is planned as a migration, it gets a lead, a validation gate, and time in the schedule.

A reimplementation rebuilds configuration and business logic in a new system rather than carrying it forward. The data must be extracted, mapped, transformed, and validated against the new system's rules, which means it follows migration discipline rather than upgrade discipline.

The pattern that shows up across every one of these paths is consistent. Roughly ninety percent of the data maps without argument: employee names, addresses, standard demographic fields, job codes, straightforward hour totals. That ninety percent is done in weeks and it creates a false sense of progress. The remaining ten percent carries the undocumented business rules, and it does not surface until real volumes hit the target and someone tries to run an actual pay period against them.

This is not a UKG problem. It is the same shape as every ERP and CRM migration, and it is why we wrote up why data migrations fail as a general pattern. What is specific to HR and payroll is the consequence. A wrong value in a customer record is an inconvenience. A wrong value in an accrual balance is a wage and hour exposure.

The five data objects that are dangerous

Every UKG migration touches these, and they fail in different ways.

Employee master and employment history

The employee master looks like the easy object and is not, because employment is effective dated and most systems store that history differently. Rehires, internal transfers, concurrent jobs, leaves of absence, and position changes all create multiple records for one human being, and the mapping between the source's model and the target's model is a design decision rather than a field mapping.

Terminated employees are the specific trap. Teams scope the migration around active headcount, then discover that year end reporting, ACA filings, and employment verification all require people who left. Decide the termination lookback window with payroll and legal before mapping, not after.

Historical time and attendance

The question is not whether to bring time history but at what grain. Punch level detail, edited punches with their audit trail, and approval records are legally significant in a wage and hour dispute, and they are frequently the records that cannot be reconstructed later. Summarized hours by pay period are cheaper to move and much weaker as evidence.

Workforce Central concepts including labor level transfers, pay rule versioning, and attestation records do not have clean one to one equivalents in Pro WFM. Where a concept has no equivalent, the honest answer is usually to archive the source data in a queryable form rather than force it into a target structure that changes its meaning.

Accrual balances

This is the object that breaks UKG migrations most often, and the reason is that an accrual balance is not really a stored value. It is the output of a rule applied across an employee's history: an earning schedule, tenure tiers, carryover caps, grant versus accrual mechanics, negative balance policies, and any manual adjustments a manager made along the way.

If you migrate the balance number without migrating the history that produced it, the target system cannot recompute it, cannot explain it, and cannot defend it when an employee disputes it. Mid period balances are worse, because the balance on a cutover date sitting mid accrual cycle depends on rules that are running at that moment in the source and not yet running in the target.

Two practical requirements. Cut over at an accrual period boundary if the calendar allows it, and if it does not, model the mid period calculation explicitly in both systems and reconcile per employee. Second, migrate or archive the earning history alongside the balance so the number can be reconstructed on demand.

Schedules

Future dated schedules are live commitments to people. Published schedules, shift swaps already approved, open shifts posted for bidding, and seniority based bid results all exist in the source with real employee expectations attached. Cutting over without them means someone shows up for a shift the new system does not know about.

Schedule templates and patterns are configuration rather than data and generally have to be rebuilt. Confirm which of the two your schedules are before assuming they migrate.

Pay rules

Pay rules are logic, not data, and they are the largest single driver of timeline on any WFM migration. Overtime calculation, premium and shift differentials, union rules, rounding, meal and break penalties, holiday eligibility, and retro pay handling all have to be rebuilt in the target and then proven equivalent to the source.

Custom logic built in Workforce Integration Manager does not carry natively into Pro WFM. Treat the rule inventory as a discovery phase with its own budget rather than a task inside configuration, because the rules that matter most are usually the ones nobody documented and only one person understands.

Parallel run and validation strategy

The validation method that works for HR and payroll migrations is a parallel run, and the detail that determines whether it works is the grain of comparison.

A parallel run processes the same pay periods in both the source and target systems simultaneously, then compares results employee by employee, so that discrepancies are found before the target becomes the system of record.

Run two to four full pay periods in parallel, and include at least one period that contains something irregular: a holiday, a payroll correction, a bonus cycle, an open enrollment change. The clean periods will match. The irregular ones are the test.

Compare at the employee, pay code, and period grain. Not at the total. Totals are the most common self deception in payroll validation because two errors of opposite sign net out, and a gross payroll figure matching to the dollar tells you very little about whether four hundred individual employees are right. Investigate every variance, including one cent variances, because a penny difference is almost always a rounding rule difference that will produce large differences somewhere else in the population.

The same discipline applies to the objects that a parallel run does not naturally cover. Accrual balances need a per employee reconciliation against recomputed values on the cutover date. Historical time records need record level comparison rather than totals. Schedules need a forward looking check that every published future shift exists in the target with the same employee attached. Our general method for this is in how to validate data after a migration, and the sequencing of the switch itself is in building a data migration cutover plan.

One principle worth holding: a record that was found broken and then corrected has not passed validation. It failed and was fixed, and it needs to run through the check again. In payroll this matters more than anywhere else, because corrections applied under time pressure are how one defect becomes three.

Decision framework: sequencing a UKG migration

If you are on Workforce Central on premises, your supported runway ends March 31, 2027. Start with a pay rule inventory rather than a data extract, because the rule rebuild is your long pole and everything else can be parallelized around it.

If you are moving UTA to Pro WFM, do not let the shared employee master convince you this is simple. Scope accruals and pay rules as though it were a full migration, and scope employee master as the small piece it genuinely is.

If you are moving Pro Back Office to Pro Web, inventory administrator processes and custom reporting first. The data exposure is limited, and the risk sits in workflows and reports built around the legacy application's behavior.

If you are consolidating several time systems into UKG Pro, resolve employee identifier survivorship across all sources before mapping anything. Which system wins on conflict, and on what tiebreak, is a business decision that otherwise gets made implicitly by whichever load runs last.

If you are leaving UKG for Workday, budget for object model translation as a design phase, not a mapping task, and expect the employee history structure to be the hardest conversation.

If your cutover date is fixed and your runway is short in every case, cut historical scope first. History is the cheapest thing to archive and the most expensive thing to migrate badly, and it is the only one of these five objects that does not block day one operations.

What UKG migration services should actually cover

If you are evaluating UKG migration services, the questions that separate vendors are not about UKG certification. Everyone bidding will have that.

Ask how many mock load cycles the quote assumes, and what happens if you need more. Ask who is accountable for the pay rule inventory and whether rule discovery is inside the fixed price or outside it. Ask what the parallel run plan is, at what grain results are compared, and how many periods are included. Ask what happens to historical time detail that has no equivalent structure in the target, and whether archiving is in scope. Ask for the reconciliation evidence package as a named deliverable.

A vendor who answers those five precisely is pricing the work honestly. A vendor who answers them vaguely is pricing the mapping and planning to absorb the rest as change orders, which is the standard failure mode in this category. Our approach to the data workstream specifically is described under HR data migration services.

Settle validates the full dataset against the target system's rules before load rather than discovering them from load failures, which is what removes reload cycles from the schedule. Engagements are fixed and scoped, at roughly half the equivalent consulting-led cost, and the saving comes from cycles that do not have to run rather than from rates.

What this looks like from inside

At Deloitte I worked a payroll and time consolidation where the accrual conversion was scoped as a balance load. Take the balance from the source, put it in the target, reconcile the total, move on. The totals reconciled. We went into the first live cycle believing the object was closed.

What we had not modeled was that a tenure banded accrual tier changed mid period for anyone crossing a service anniversary in the cutover window, and the source applied that change on a different day than the target did. It affected a small number of people. Every one of them noticed, because the people who watch their PTO balance closely are the people who have plans, and the correction had to be worked individually while the next cycle was already running.

The population was small enough that no sample would have found it and no total would have shown it. It was only visible by recomputing balances per employee against the rules on the cutover date, which is a check that takes hours if it is automated and weeks if it is not.

Frequently Asked Questions

What is a UKG migration?

A UKG migration moves employee, time, accrual, schedule, and pay rule data between UKG products, into UKG from a legacy system, or out of UKG to another platform. The most common moves in 2026 are Workforce Central to UKG Pro Workforce Management, UKG Pro Time and Attendance to Pro WFM, UKG Pro Back Office to Pro Web, and UKG to Workday. Despite being framed as platform transitions, the partners who deliver them generally describe them as reimplementations.

When does UKG Workforce Central support end?

Workforce Central hosted on the Kronos Private Cloud reached end of life on December 31, 2025. On premises deployments reached end of engineering on the same date and have support through March 31, 2027. UKG announced the retirement in October 2022. The legacy Kronos 4500 terminal is retired alongside the product, with Pro WFM customers moving to the InTouch DX terminal.

Is migrating from Workforce Central to UKG Pro WFM an upgrade?

No. It is a reimplementation. The two products organize time and attendance data differently, and custom labor calculations built in Workforce Integration Manager do not natively carry into Pro WFM and must be rebuilt. Integrations, configuration, and reporting generally need rework, and historical data with no structural equivalent in the target is usually better archived than forced across.

What is involved in a UKG UTA to WFM migration?

Moving from UKG Pro Time and Attendance to Pro WFM shares an employee master with UKG Pro, which removes one of the harder objects. The work concentrates in pay rules and accruals, since the two products configure them differently, and in historical time detail. Scope the rule inventory as its own discovery phase rather than as a configuration task.

What does the UKG Pro Back Office to Pro Web migration involve?

UKG is retiring the legacy Pro Back Office application in favor of Pro Web. The data exposure is smaller than the other UKG paths, and the risk sits in administrator workflows and custom reporting built around the legacy application's data access patterns. Confirm your specific timeline with UKG, because published third party dates for this retirement are inconsistent.

How do I transfer data from UKG to another system?

Extract through UKG's reporting and API layer, map to the target's object model, transform, stage, and validate before loading. The objects that need the most attention are effective dated employment history, punch level time detail with its audit trail, accrual balances together with the history that produced them, future dated schedules, and pay rule logic. Pay rules are rebuilt rather than migrated, since they are logic rather than data.

Can I migrate data from UKG without losing historical time records?

You can retain them, but not always inside the target system in their original structure. Where the target has no equivalent concept, such as certain Workforce Central labor level and attestation constructs, the defensible option is an archive that keeps the records queryable with their audit trail intact rather than reshaping them to fit. Decide the live versus archive split with payroll, legal, and HR before mapping.

How long does a UKG migration take?

Partners commonly scope nine to eighteen months from discovery to go live for Workforce Central to Pro WFM, driven mainly by pay rule complexity, the number of source systems, and how many test cycles the team runs. Smaller moves such as Back Office to Pro Web run considerably shorter. The main variable is how early exceptions in accruals and pay rules surface, because each discovery triggers another correction and reload cycle.

Who should own a UKG migration internally?

Payroll owns the meaning of pay rules and accrual policy, HR owns employee data definitions, and IT owns the movement. Name a single accountable owner per object and put the name in the plan. The people who can tell you what a rule actually does are usually operators rather than managers, and they need to be in the discovery sessions.

Bringing it together

Every UKG migration path shares the same shape. The employee names and addresses move fine. The accrual balances, the pay rule logic, and the historical time detail are where the schedule goes, and all three are validatable against your real data today rather than discoverable from a failed load in month seven.

If you are planning a UKG move and want the data workstream scoped against your actual source systems, Settle will run the validation before you commit to a cutover date. Book a scoping call.