Most Workforce Central estates were built by several people over many years. Pay rules were added when an agreement changed, a site opened or an audit asked a question, and the reasoning rarely went into a document. The system works, and nobody is quite sure why. That is the real starting position of a migration, and it is why the work is harder than it looks on a plan.
Support for Workforce Central is winding down. Cloud-hosted support and product engineering ended on 31 December 2025, and support for on-premises Workforce Central ends on 31 March 2027. The question for most organisations still on it is no longer whether to move but how to do it without a payroll incident. Check how those dates apply to your own hosting and contract with UKG.
What the example looks like
The scenario below is illustrative, not a client. It is a composite of the shape these projects take, written to show the work rather than to claim a result.
Take a manufacturer or logistics business of around three thousand employees across several sites, with a mix of salaried staff, hourly shift workers and one or two union agreements. Timekeeping and scheduling run on Workforce Central. Payroll sits in a separate system, fed by a nightly file. A handful of supervisors know which pay rules are real and which are historical accidents.
It is a rebuild, not an upgrade
UKG WFM is a different platform. Some configuration can be carried across with tooling, but a meaningful part has to be redesigned, and the interfaces built for Workforce Central generally have to be rebuilt as well. Timecard and schedule history does not simply come along, so what you need for audit and reporting has to be archived on purpose.
Treat it as a project with the shape of a new implementation, because that is what it is.
How the work runs
1. Inventory before anything else. Every pay rule, accrual, schedule pattern, report and interface is listed and given a disposition: carry over, rebuild or retire. In the example this is where the surprises appear. Some rules exist for an agreement that has since been renegotiated. Some reports have not been opened in years. Retiring them is the cheapest saving in the whole project.
2. Design from policy, not from the old system. The temptation is to copy Workforce Central rule for rule. That reproduces every historical accident in the new platform. The better route is to write down what the policy and the agreements actually require and configure that, using the old system as evidence rather than as a specification.
3. Rebuild the integrations. The payroll file is the one that matters. It is rebuilt, documented and tested against realistic volumes, then monitored. A failed interface should raise an alert the same hour, not surface as an underpayment the following week.
4. Rehearse the data. Employee records, organisation structure and accrual balances are loaded more than once. Each load is reconciled: record counts, balance totals and a sample of individual employees checked by the payroll team. Balances are where errors hurt people, so they get the most scrutiny.
5. Run pay in parallel. For at least one full pay cycle, and more where agreements are complex, the new platform calculates pay alongside the old one. Every variance is explained line by line. Some turn out to be errors in the new configuration. Some turn out to be errors in the old one that nobody had noticed.
6. Cut over on the pay calendar. The cutover is timed around pay periods and period-ends, not around what suits the project plan. There is a rehearsed sequence, a written rollback, and engineers staying through the first live cycles. Managers and schedulers are trained on their own jobs rather than on a tour of the menus.
The go-live test
This is the part we would hold to hardest. Go-live should be decided by one thing: the parallel pay runs reconcile, and the person responsible for payroll has signed the variance report.
A date on a plan is not a go-live criterion. A project that lands on schedule and underpays people has failed, however clean the cutover looked.
Where mid-sized companies get caught
- No single owner of the rules. The knowledge sits with two or three people. Capture it early, while they are still available.
- Integrations treated as an afterthought. They are scoped last and tested least, and they are where most post-go-live incidents start.
- Testing owned by the project team. The people who live with the result, payroll and operations, have to own acceptance, or the testing proves the configuration matches itself.
- No plan for after go-live. Rules change when agreements do, platform updates arrive on UKG’s schedule, and someone has to own both.
What we usually recommend
Start with an inventory and a disposition for every rule and interface, build the cutover plan around your pay calendar, and agree the pay-accuracy exit criterion before the project begins rather than at the end. Then keep the platform supported afterwards, because the configuration drifts the moment nobody owns it.
That is the shape of our UKG Workforce Management practice, and it starts with a readiness assessment that gives you the inventory, the plan and a costed estimate whether or not you go further.