Catchup Transaction Script

Context & Problem

Brigham Young University was transitioning from its legacy ERP system People Soft to Workday; modernization that would overhaul the university’s infrastructure for Human Capital Management, Financial Management, and Payroll.

This migration involved hundreds of thousands of employee records, many of which changed every semester due to BYU’s large student workforce. Between semesters, thousands of students were hired, terminated, or reassigned to new positions.

The challenge: the “go-live” tenant build required a two-month preparation window, during which new employee data continued to accumulate. Once the build was complete, my team had only one week to synchronize all that missed data into Workday. This included compensation, job records, emergency contacts, tax information, financial details, position updates and much more.

Even with a 50-person team, manually processing over 100+ million transactions within a week was impossible.

That’s where the Catchup Transaction Script came in.

The Solution

The goal was to automate the process of loading, validating, and updating Workday's data in bulk. The system I designed and implemented worked like this:

1. Data Source: A SQL table stored all the transactional data that needed to be loaded and processing information.
2. Processing Layer: A Python script ingested that table, formatted the data per endpoint requirements, and sent API requests to Workday.
3. Error Handling: Any failed requests were logged back to the SQL table with detailed error messages for reprocessing.
4. Testing Mode: The script supported test runs by allowing the user to specify different tenants than the production tenant.

While configuration for different endpoints was developed collaboratively, I personally architected, coded, and tested the entire script engine.

This automation reduced the transition team from around 50 members to just 8 people:

• 3 handled data preparation and script execution
• 5 focused on validating loaded records

By removing nearly all manual entry, the script made the one-week transition possible. Without it, BYU would likely have had to delay its ERP go-live date, which would have affected every department on campus.

Impact

• Reduced data entry team from ~50 to 8 people
• Automated migration of 100+ million transactions
• Enabled on-time ERP transition within the one-week window
• Improved accuracy and eliminated human error from the data load

Reflection & Future Improvements

While the script succeeded, it was admittedly a first-generation tool, rigid and context-specific. If I were to rebuild it today, I would:

• Generalize the configuration system to avoid duplicated endpoint definitions
• Add a spreadsheet interface, allowing users to generate and upload Excel templates directly
• Implement modular workflows, so actions like “hire employee” or “update compensation” reference centralized configurations
• Enable data pre-validation, pulling information from the Workday tenant before updates to support true “mass editing”

In short, I’d evolve the Catchup Transaction Script from a one-time migration utility into a reusable mass-editing automation framework; a system capable of maintaining data integrity across ongoing ERP operations.

Takeaway

This project reminded me how powerful automation can be when human limits collide with tight timelines. By merging engineering precision with real-world urgency, a seemingly impossible transition became achievable.

Even more importantly, it showed how the right tools, designed with clarity, adaptability, and validation in mind, can turn a team of 50 into a team of 8 without sacrificing accuracy or reliability.

Summary

Role: Lead Developer

Tech Stack: Python, SQL, Workday API

Impact: Automated ERP data migration; reduced human workload by 80%+

Team Size: 8

Category: Enterprise Automation / Data Integration