We turn HCM contracts into systems people actually use.

An HCM implementation is the multi-month process of standing up a new human capital management platform (UKG, ADP, or otherwise) across the systems, data, and operational workflows of your organization. The work includes platform configuration to match your policies and pay rules, data migration from legacy systems, integration with payroll and downstream tools, change management for HR and managers, and parallel testing through several pay cycles before go-live.

Most HCM implementations involve three to five distinct workstreams running concurrently (configuration, data, integration, training, and testing) with phase gates that prevent you from going live before each is genuinely ready. Mid-market implementations typically run 4-8 months; enterprise scope can extend 9-18 months depending on platform complexity, location count, and how many systems need to integrate.

RJR has delivered 100+ HCM implementations across UKG and ADP environments. The implementation work itself is rarely the constraint. The constraint is partner discipline around scope, timeline, and the day-after-go-live operational support that determines whether the platform actually delivers value.

A UKG Pro implementation typically runs 6-12 months for organizations of 1,000-5,000 employees, with timeline driven primarily by scope (which UKG Pro modules are in play), location and policy complexity, and the state of your legacy data. Multi-state employers, organizations with union populations, and environments running heavy custom integrations to ERP, finance, or scheduling systems extend toward the upper end of that range.

The phases are predictable (discovery and design, configuration, data migration, integration, parallel payroll testing, and post-go-live stabilization), but the parallel testing phase is where timelines compress or extend most often. Two clean parallel pay cycles is the floor; three is more common when payroll complexity warrants additional verification before cutting over.

RJR's UKG Pro work covers 25 UKG-certified consultants across implementation, optimization, and managed services. The honest answer on timeline is that we won't compress it past where the data and testing actually support. Going live on a partially-validated platform creates operational debt that costs more in the first six months than the time saved during implementation.

System Implementation is the work of standing up a new HCM platform from scratch — discovery and design, configuration, data migration, integration, testing, and go-live. It's a defined-scope engagement with a clear endpoint: the platform is live and operational. System Optimization is the work of improving an HCM platform that's already running — closing configuration gaps, retiring workarounds, building the integrations that didn't ship in the original scope, and remediating data quality issues that surfaced after go-live.

The practical signal: if you don't have the platform yet, you need Implementation. If the platform is live but isn't doing what you expected (manual workarounds, broken handoffs between systems, payroll exceptions piling up), you need Optimization. Most organizations end up in Optimization not because the original implementation was bad, but because business needs evolve faster than the original configuration accounted for.

RJR delivers both as distinct service pillars with the same UKG-certified consultants behind each. The methodology differs (Implementation runs against a project plan with phase gates; Optimization runs against a prioritized backlog of issues with measurable improvement targets), but the operational discipline carries across both.

The partners that consistently deliver successful HCM implementations share four traits worth probing during evaluation. First, platform certifications and bench depth: not just the partner's headline numbers, but how many certified consultants would actually staff your engagement and how the team handles attrition mid-project. Second, methodology discipline: ask for the actual phase-gate criteria, the parallel testing standard, and how change requests are scoped against the original SOW.

Third, post-go-live support model. Most implementations look fine at go-live; the real signal is what happens in the first 90 days when payroll exceptions surface, integrations break under load, and end users hit configurations that didn't match how they actually work. Ask whether the implementation team transitions to a managed services or a hypercare engagement, and how that handoff is structured.

Fourth, references that match your actual situation, not the partner's flagship logos, but engagements your size, in your industry, on the platform and modules you're implementing.

RJR delivers across both sides of the implementation work — business process design, policy analysis, and change management on one side; data conversion, historical archiving, integration architecture, and configuration depth on the other. Most HCM problems live at the seam between business intent and technical execution. Handling both within the same engagement closes the gaps that emerge when those workstreams sit with separate vendors. With 100+ implementations across UKG and ADP and clients ranging from a few hundred employees through global enterprise, our people, processes, and technology scale with organizations as they grow.

Implementation rescue starts with an honest assessment of what's actually broken, and the answer is rarely just "the partner is bad." Most failing implementations have multiple issues compounding: scope expanded mid-project without timeline adjustment, parallel testing skipped or compressed, configuration gaps masked by manual workarounds, and stakeholder alignment that drifted as priorities shifted. RJR's first step is a structured assessment, typically over 2-3 weeks, that documents the actual state across configuration, data, integration, and operational readiness, separating what's salvageable from what needs rework.

From there, the path forward depends on what we find. Some implementations need targeted intervention: fix the specific configuration gaps, complete the integrations that didn't ship, and run rigorous parallel testing before going live. Others need scope reset: acknowledge what's not going to work in the current architecture, redesign the affected components, and adjust timeline expectations with the executive sponsor. The honest rescues are the ones where the assessment surfaces issues the original partner won't acknowledge.

RJR has handled implementation rescues across UKG and ADP environments where the original partner's work was either incomplete or structurally flawed. The work is rarely glamorous (it's disciplined remediation rather than dramatic intervention), but the outcome is a platform that actually works, with operational debt cleared rather than papered over for the next vendor to discover.

Yes, and it's increasingly common as organizations consolidate post-M&A or run different platforms for different functions: UKG for time and labor, ADP for payroll, Workday for finance-adjacent HCM, or some combination. The relevant question isn't whether a partner can technically work across platforms, but whether they have certified depth on each platform you actually need rather than generalists who claim breadth without operational experience.

Multi-platform engagements have specific complexity worth understanding upfront. The integration work between platforms is usually where issues surface: data mapping that doesn't quite reconcile, timing windows that don't align, exception handling that requires manual intervention. The platforms themselves are stable; the seams between them are where multi-platform implementations succeed or fail. A partner handling multiple platforms within the same engagement can architect the integration layer holistically rather than coordinating across separate vendors who each optimize for their own platform.

RJR has 25 UKG-certified consultants alongside ADP delivery depth (including ADP Workforce Manager, ADP Workforce Now, and ADP Lyric) and partnership relationships with both vendors plus Boomi, Paylocity, and NCR for adjacent integration work. Multi-platform clients get a single accountable partner who understands how the platforms interact operationally, not just how each one works in isolation.

Go-live is the start, not the end. Hypercare is the structured period immediately after go-live where the implementation team stays engaged at higher coordination intensity to handle the issues that surface only when real production traffic hits the system: payroll exceptions for edge-case populations, integration timing issues that didn't appear in testing, configuration gaps where end users hit policies the original setup didn't anticipate, and reporting needs that emerge once data is flowing for real.

RJR's standard hypercare engagement runs through two complete pay periods post-go-live. Two pay cycles is the right cadence because most production issues surface within those cycles: payroll exception handling, parallel reconciliation discrepancies, and the operational rhythms that need to stabilize before the implementation team disengages. Hypercare structure typically includes daily standup coordination between RJR and your internal team, escalation paths for production-impacting issues, a defined backlog for remediation items, and weekly executive reporting that tracks resolution velocity.

After hypercare, clients typically transition to one of three paths: Managed Services for ongoing operational support, a quarterly optimization cadence for periodic improvements, or self-sufficient operation with no further engagement. The transition decision depends on internal team capacity and the platform's operational complexity. RJR runs hypercare as a bounded engagement with measurable exit criteria (payroll exceptions resolved to baseline rate, integration error volumes within tolerance, end-user support tickets trending toward expected steady-state) rather than open-ended billable hours that drift past where the implementation team adds real value.

A typical RJR implementation team includes an engagement manager who owns timeline and scope, a lead consultant per workstream (configuration, data migration, integration, testing), supporting consultants on each workstream, and an executive sponsor on the RJR side who carries accountability for the overall engagement. Mid-market implementations typically run 5-8 people on the RJR team; enterprise scope can extend to 12-18 depending on workstream parallelism and scope complexity.

The lead consultants are platform-certified and bring delivery experience from prior implementations, not generalists assigned to whatever's open. Supporting consultants build certification and specialization as they go, but lead positions on each workstream are filled by people who've completed multiple comparable engagements. The engagement manager isn't a dedicated administrator; they're a senior practitioner who understands the platform substantively and can intervene when workstreams need rebalancing.

On the client side, successful implementations typically have an executive sponsor (HR or operations leadership), a project lead managing internal coordination, and subject-matter experts available for each workstream: payroll, time and labor, benefits, HR operations, and IT for integration architecture. RJR works against a clear RACI from the engagement start so accountability boundaries are explicit, not assumed. The teams that struggle most are the ones where role boundaries blur during high-pressure phases. The teams that succeed are the ones where every workstream has a named accountable owner on both sides.