Client case study
Time and Leave System
A two-decade-old HR system, off Windows and onto the latest .NET
Built for a large international organisation. We respect our clients' privacy, so the organisation is not named.
A nearly two-decade-old HR system with per-country timekeeping rules, moved from an over-ten-year-old version of .NET on old Windows servers to the latest .NET in Linux containers.
Background
The system is how the organisation's staff record working hours, request leave, claim overtime, and arrange remote working. Supervisors approve and HR finalises. It feeds the payroll system and it is the system of record if a dispute arises.
The application is nearly two decades old. Over that time it had passed through several generations of the .NET framework and accumulated a rules engine of dozens of parameterised rules, each mapping to a numbered paragraph of the staff regulations: core hours, lunch windows, rest breaks for night shifts, overtime multipliers and expiry, caps on remote working, and so on. Staff work in different countries around the world, so the rules are specialised per location, each with its own public holidays and working patterns.
The challenge
The system only ran on an over-ten-year-old version of .NET on old Windows servers that the organisation wanted to retire. The infrastructure team was moving to Linux and containers. A replacement product would have meant re-implementing the entire rules engine and re-integrating the badge scanners, MS Teams, Outlook and payroll, with years of historical records to migrate. The pragmatic answer was to bring the existing system forward. There was a second constraint: the user base is large, even though the entire system was being upgraded and modernised underneath, the look and feel of the legacy application had to be maintained so that staff, supervisors and HR were not faced with retraining or a change in how they work.
What we did
We ported the application from an over-ten-year-old version of .NET to the latest release as a series of verified slices while the system stayed in daily use. Each slice was tested against the behaviour of the old version before it replaced it.
- Ported the web application to the current .NET framework, replacing the legacy dependency-injection container and retiring dead components on the way.
- Containerised the application so it runs on the organisation's Linux infrastructure instead of dedicated Windows servers.
- Preserved the look and feel of the legacy application throughout, so users saw no change to the screens and workflows they already knew.
- Carried the rules engine across intact, including the country-specific rules for staff based around the world, with unit tests for each rule so payroll-affecting calculations behave exactly as before.
- Kept the physical and digital integrations working: RFID badge readers that clock staff in and out, adaptive-card approvals in MS Teams, Outlook calendar sync of leave via Microsoft Graph, and the two-way sync with the HR and payroll system.
- Added a TypeScript service alongside the .NET application for the MS Teams bot and Outlook calendar sync, sharing the same database.
- Built out an extensive automated test suite of unit, integration and end-to-end browser tests, ensuring continuity of behaviour for the upgraded system.
- Updated the rules engine to handle the latest organisation policy changes.
How AI-assisted delivery helped
Porting thousands of lines of C# across a decade of framework changes is exactly the kind of work where AI tooling pays for itself: the changes are numerous, mechanical in places, and dangerous where they are not.
- Role-specific AI agents for development, database administration, QA, security review, architecture and technical writing.
- AI-generated test coverage for the rules engine, so every rule was pinned before the platform under it changed.
- A monthly OWASP-based security audit of the whole codebase and its dependencies, with each finding verified in the code and tracked as new, resolved or still open, plus a go or no-go security gate before every release.
- Architecture, data model and disaster-recovery documentation kept current throughout the port.
Outcome
The organisation kept a system its staff already knew, on a supported platform, running on the Linux infrastructure it wanted to standardise on. The badge scanners, MS Teams approvals, Outlook calendar sync and payroll integration all carried on working through the change.
Have something similar?
A free, no-pressure discovery call. Bring the problem, we'll bring honest advice on scope, timeline and risk.