What the New Experience is, and what it is not
UKG is rolling out the New Experience, a redesigned interface layered across the UKG Pro suite. For most administrators and employees, the headline change is what they see: refreshed navigation, reorganized menus, and a more modern layout. The underlying configuration, business rules, and data model largely carry forward.
That framing matters, because it sets the right expectation. A redesigned interface is not a reimplementation. But it is also not a cosmetic event that teams can ignore until launch day. Anything that depends on where things live in the interface, how people navigate to them, or how saved configurations surface can shift in ways that affect day-to-day work.
The practical question is not whether the new interface looks better. It is whether the transition is a non-event for the people who run payroll, manage schedules, and pull reports every cycle. Getting there takes a readiness pass before the switch and a stabilization pass after it.
Why an interface change still carries operational risk
Interface modernizations rarely break the math. They break habits, saved paths, and the quiet assumptions built into how a team operates. A payroll administrator who has run the same close process for years navigates by muscle memory. Saved searches, favorited views, and bookmarked screens are part of that process. When the navigation model changes, the process has to be relearned even if the data behind it is identical.
There is also a real regression surface. Security roles control what each user can see and do, and a role that behaves correctly in one navigation model can expose or hide the wrong things in another. Reports and saved analytics that teams depend on need to be confirmed present and accurate. Integrations that move data between UKG and payroll, finance, time, or benefits systems should be unaffected by a UI change, but should be tested rather than assumed.
A readiness checklist
The goal of a readiness pass is to enter the transition knowing what each user group needs, what could regress, and how each item will be verified. The areas below are where transitions of this kind tend to generate the most help-desk volume.
Navigation, saved views, and self-service
- Inventory the saved searches, favorited views, and bookmarked screens your power users rely on, and confirm each has a clear equivalent in the new interface.
- Walk the highest-frequency tasks (the payroll close, schedule edits, time approvals, employee changes) step by step in the new navigation before launch.
- Check employee and manager self-service flows on both desktop and mobile, since those are the screens with the highest user count and the lowest tolerance for confusion.
Security roles and access
- Re-verify each security role against what users should and should not be able to see and do, rather than assuming role behavior carries over unchanged.
- Pay special attention to roles that touch pay, banking, tax, and personal data, where an access regression is a compliance issue, not a convenience issue.
- Confirm delegation, approval routing, and any role-based dashboards still resolve to the right people.
Reporting and saved analytics
- List the reports and dashboards that feed payroll, finance, and leadership, and confirm each is present, runs, and returns the same numbers.
- Validate scheduled and exported reports that downstream systems or people depend on, not just the on-screen views.
Integrations and payroll continuity
- Identify every integration moving data into or out of UKG (payroll, finance, time, benefits, identity) and confirm each is in scope for testing through the transition.
- Run at least one full payroll cycle in a non-production or parallel posture where possible, so continuity is proven rather than assumed.
- Keep a rollback and escalation plan for the first live cycle, with named owners for each system in the chain.
Change management and training
- Segment communication by audience: administrators, managers, and employees each experience a different slice of the change.
- Provide short, task-based guides for the handful of actions each group performs most, rather than a single exhaustive manual.
- Brief the help desk on the most likely questions before launch, so the first week is supported rather than reactive.
Stabilization after the switch
Readiness gets a team to launch. Stabilization is what keeps the first few cycles from becoming a backlog of small breakages. The first payroll cycle after a transition is the one that surfaces the issues that only appear under production rhythm: an edge-case approval path, a report a single team relied on, a saved view nobody thought to inventory.
A short stabilization window with a clear intake for issues, a triage owner, and a daily standup through the first cycle turns those breakages into quick fixes instead of accumulating frustration. The same discipline applies to any HCM transition, which is part of why a readiness method built for one platform tends to transfer to the next.
How RJR helps
RJ Reliance is not an official UKG New Experience migration program, and any organization should follow UKG's own guidance and timeline for the rollout. What RJR brings is the readiness and stabilization discipline that makes platform transitions land cleanly: inventorying what each user group depends on, verifying security and reporting, proving payroll continuity through integrations, and standing up a stabilization window so the first cycles are supported.
That work sits inside RJR's System Optimization and Managed Services practices, and the method is platform-transferable. Teams preparing for the New Experience can treat it as a structured readiness pass rather than a wait-and-see.
This article is operational guidance, not legal or vendor-specific implementation advice. Confirm the rollout details, timing, and requirements that apply to your environment with UKG.
Frequently asked
Is the UKG New Experience a reimplementation?+
No. It is a redesigned interface across the UKG Pro suite. The configuration, business rules, and data behind it largely carry forward. The work is readiness and stabilization around navigation, security roles, reporting, and integrations, not rebuilding the platform.
Will the change affect payroll?+
It should not change payroll calculations, but anything that depends on navigation, saved views, security roles, reporting, or integrations can shift. The safe posture is to prove a full payroll cycle through the transition rather than assume continuity.
What is the biggest regression risk to watch?+
Security roles and reporting. A role that behaved correctly before can expose or hide the wrong things after a navigation change, and saved reports that feed payroll, finance, or leadership need to be confirmed present and accurate. Both should be re-verified rather than assumed.
When should readiness work start?+
Before launch, not after. A readiness pass inventories what each user group depends on and identifies what could regress, so the transition is planned rather than discovered. A short stabilization window after the switch then catches the edge cases that only surface under production rhythm.
When does it make sense to bring in outside help?+
When the environment has many integrations, complex security roles, heavy reporting dependence, or a payroll operation that cannot absorb a rough first cycle. The readiness and stabilization method is platform-transferable, so the same discipline that smooths one HCM transition applies to the next.
Topics
- UKG
- Change management
- System Optimization
- Payroll
- Readiness



