A large industrial manufacturer had thirty years of piecework pay logic buried in legacy MES code. When they moved to UKG Pro WFM, CloudApper WorkBridge became the decoupled calculation engine that preserved their pay-for-performance culture without forcing it into a platform not built to hold it.
Table of Contents
When manufacturers move to UKG Pro WFM, the conversations that dominate the pre-go-live period tend to cluster around scheduling, compliance, and time capture. What gets underestimated — sometimes dangerously so — is the pay calculation logic that has been running quietly in the background for decades, usually buried inside a legacy MES, a custom database, or a collection of spreadsheets that one person in payroll truly understands.
For a large industrial manufacturing company in the US Midwest, that logic was thirty years old, encoded in more than thirty pages of PL/SQL stored inside a legacy manufacturing execution system. It had worked. It had never failed. And it was completely unreadable to anyone who hadn’t written it. When the company made the decision to migrate to UKG Pro WFM, the question was not whether their piecework pay culture would survive — it was how to get the pay math out of a system that couldn’t travel with them.
The answer was CloudApper WorkBridge, which was configured as a dedicated piecework calculation engine sitting between the MES and UKG Pro WFM. But the technical solution was almost secondary to the business decision that preceded it: recognizing that pay calculation logic is not a feature of a WFM platform, and that trying to force it to be one would cost more than building it correctly.
Why Piecework Pay Is the Last Thing UKG Touches — And the First Thing That Breaks During Migration
Pay-for-performance manufacturing cultures are built over years. They shape how employees think about their work, how supervisors manage their teams, and how finance models labor costs. A piecework system that pays employees based on units produced — factoring in multipliers, shift premiums, team proration, indirect time categories, and minimum wage guarantees — is not a payroll feature. It is a business philosophy that happens to run through payroll.
UKG Pro WFM is an extraordinarily capable platform for scheduling, timekeeping, leave management, and labor cost analysis. It is not designed to replicate the custom pay calculation logic that a manufacturer built over multiple decades to reflect a specific agreement with its workforce. This is not a criticism of UKG — no enterprise WFM platform is designed to replace what is effectively a specialized calculation engine tied to unique labor economics. But it is a gap that creates real risk when organizations assume the platform migration will handle it.
In this company’s case, the piecework formula involved multiplying raw units produced by a piecework price, then applying a proprietary performance multiplier that varied by individual output and team contribution, then layering shift premiums, indirect time categories for non-production hours, and a minimum wage floor guarantee for any period where calculated earnings fell short. Every one of those elements required data that lived in the MES — job start and end times, units produced, scrap counts, team assignments — not in UKG.
The original PL/SQL code had calculated all of this for three decades. Migrating to UKG Pro WFM without a plan for that logic meant either rebuilding it inside a platform not designed to host it, or losing the pay culture entirely. Neither was acceptable.

Decoupling the Math from the System
The approach CloudApper took was architectural rather than configurational. Rather than attempting to push piecework calculation into UKG Pro WFM’s native pay rules, CloudApper WorkBridge was deployed as a fully decoupled calculation layer between the two systems. The MES continued to do what it always had: track production events. UKG Pro WFM continued to do what it is designed for: manage workforce records and process payroll. CloudApper sat in the middle and owned the math.
The integration worked on a webhook model. When a production event occurred in the MES — a job start, a job completion, a unit count submission, a scrap entry — the event was transmitted to CloudApper in real time. CloudApper applied the full piecework calculation logic: unit counts, the performance multiplier, team proration rules, indirect time categorization, shift differential application, and the minimum wage guarantee check. The result was a single, accurate pay amount attached to the correct pay code, posted directly to the employee’s UKG Pro WFM timecard.
From a payroll processing perspective, nothing changed. Pay codes appeared in UKG timecards exactly as they always had. From an audit perspective, everything improved. Every calculation was logged, traceable, and explainable — a significant improvement over the original PL/SQL that had grown opaque over three decades of patches and modifications.
An additional element that mattered to the workforce was a piecework audit dashboard embedded as a tile in UKG. Employees could see their calculated earnings — units, rates, multipliers — in real time, without asking a supervisor or waiting for a paystub. In a culture built on pay-for-performance, that transparency was not cosmetic. It was part of how people understood their relationship to the work.
As described in the broader context of customizing UKG Pro without disrupting future updates, the most sustainable approach is always to build custom logic outside the core platform rather than inside it — so that platform updates don’t break business-critical calculations.

What This Means for Other Manufacturers Considering UKG Pro WFM
The problem this company faced is not unusual. Manufacturing organizations that have operated for decades have almost certainly built pay calculation logic somewhere it was never supposed to live permanently — an MES, an ERP, a set of Access databases, a collection of Excel macros. That logic reflects years of negotiation, iteration, and institutional knowledge. It works. And it will not survive a platform migration unless someone plans for it deliberately.
The standard advice in WFM implementation circles is to simplify pay rules before go-live. That advice is often correct for rules that exist because of organizational complexity that no longer applies. It is almost never correct for rules that exist because of a workforce agreement or a compensation philosophy. Simplifying a piecework multiplier to make an implementation easier is not a configuration decision — it is a labor relations decision with real downstream consequences.
What CloudApper’s approach demonstrates is that the alternative to simplification is not manual workarounds or months of delay. CloudApper WorkBridge creates a structured, maintainable layer for exactly this category of problem: pay logic that is too specific for a WFM platform to hold natively, but too important to abandon or approximate. The logic is preserved, documented, and decoupled from both the legacy system and the new platform — which means it survives future upgrades on both sides.
For IT and HRIS teams managing UKG Pro WFM implementations at manufacturing sites, the practical takeaway is to treat pay calculation logic as a distinct workstream in the implementation plan, not an assumption that the platform will absorb. CloudApper iPaaS and the WorkBridge platform are specifically designed for this category of requirement — extending UKG’s capabilities without modifying its core, and creating clean, auditable data flows between production systems and the WFM platform.
The manufacturer in this story did not simplify its pay culture to fit a new system. It preserved the culture and built a system that could support it. Thirty years of pay logic was retired without losing a single calculation rule. The result was a cleaner architecture, a more auditable process, and a workforce that could see exactly how its earnings were calculated — in real time, inside UKG.
For any manufacturing organization where compensation is tied to production output and workforce trust depends on pay accuracy, that outcome is worth planning for from day one of the implementation.
If your organization is planning a UKG Pro WFM implementation and you have complex piecework, performance-based pay, or legacy calculation logic that doesn’t fit the platform’s native capabilities, CloudApper can help you assess the right approach before go-live. Reach out to the CloudApper team to start the conversation.








