Legacy Application Modernization: A Resource Planning Case Study
Project managers at a engineering & control system integration firm could only see resource allocations at monthly granularity. For larger projects spanning multiple months, this was workable, but not for shorter engagements. Usage suffered because the tool didn't fit the rhythm of the business.
Overview
The tool the firm had could do more. But after years without development, the gap between what the resource planner offered and what people needed had grown wide enough that most users had given up.
The firm brought ASQI in to fix both problems: modernize the platform and add the weekly visibility their project managers had been asking for. What we found was a codebase frozen in time, running .NET Framework 2.0, with a decade of direct SQL updates that had bypassed the application. Before we could add new features, we had to bring the foundation into the present.
This is the story of modernization, the technical archaeology required to make it work, and the business value it unlocked.
The Challenge
The system integrator serves industrial clients across multiple sectors. Their internal resource planner tracked engineer and project manager allocations across active projects. In theory, it provided visibility into who was working on what. In practice, it had become a checkbox rather than a tool.
Monthly Blindness
The core limitation was granularity. Project managers could only assign resources at the monthly level. If an engineer was allocated to Project A for October, that was the entire picture. There was no way to see that the first two weeks were light while the last two were overcommitted.
Leadership reports pulled from the same database, which meant forecasting was equally coarse. Capacity planning happened at 30-day resolution in a business where project phases shift weekly. By the time utilization data appeared in reports, the decisions it should have informed were already made. The result was reactive planning and low usage because it didn't provide enough value to justify the effort.
Years of Drift
The codebase told its own story. Built on .NET Framework 2.0, it predated most modern web development patterns. The Kendo UI components were several major versions behind. Authentication needed updates as well.
Over the years, changes had been made directly to SQL Server rather than through the application. Schema updates, data corrections, stored procedures, and new columns had accumulated outside the Entity Framework models. The application and its database had drifted apart.
This drift created a maintenance trap. Any attempt to update the application risked breaking integrations that existed only in direct SQL. Any attempt to add features required understanding which parts of the database the application actually controlled.
Platform Modernization
Before adding weekly visibility, we had to modernize the platform. This wasn't optional. The .NET 2.0 runtime was end-of-life, dependencies had known vulnerabilities, and the architecture couldn't support the changes the firm needed. The modernization work was the prerequisite for everything else.
.NET 2 to 8 Migration
Upgrading across six major .NET versions required more than changing target frameworks. The patterns and practices had evolved substantially. Authentication, dependency injection, configuration management, and the MVC pipeline itself all worked differently in modern .NET.
Database Archaeology
The most interesting challenge was reconciling what the application thought the database looked like with what the database contained. Direct SQL updates had added columns, changed constraints, created stored procedures, and modified relationships that the Entity Framework models didn't reflect. The application's view of its own data layer was frozen in time. The database kept evolving.
We reverse engineered these changes back into the models, examining each table, comparing it to the existing definitions, and updating the models to reflect reality. The detective work involved comparing schema snapshots, reviewing stored procedure definitions, and tracing data flows through the application to understand which tables were being used and how.
Once the models matched the actual schema, we resynchronized Entity Framework migrations by applying a new migration to the existing history. This brought the migration chain back in line with reality and ensured future model updates would apply cleanly.
Data preservation was non-negotiable. Throughout this process, we verified that existing data remained intact. Test environments were refreshed from production and validated after each migration step. The goal was to modernize the platform without losing a decade of resource allocation history. Every schema change was tested against production-equivalent data before being applied to the live system.
UI Refresh
The frontend used Kendo UI components that were several major versions behind current releases. Upgrading these components modernized the user interface and brought access to newer features, but also required updating how the application consumed them.
Kendo had evolved over the years. Component initialization, event handling, and data binding worked differently in current versions. Views were updated to use modern Kendo patterns, and custom JavaScript was refactored to match current conventions. The result was a more responsive interface built on supported components.
From Monthly to Weekly Granularity
With the platform modernized, we could address the core business need: weekly resource allocation and visibility. This was the feature that would change how project managers worked.
The new model allows resource assignments at the week level. Project managers can now allocate engineers to specific weeks within a month, more accurately reflecting resource assignments. An engineer might be 100% on Project A for weeks one and two, then split between Project A and Project B for weeks three and four.
This granularity changes the planning conversation. Instead of "I need this engineer for November," it becomes "I need this engineer for the first two weeks of November, then half-time through month-end." Project managers can see potential conflicts at the week level and resolve them before they become problems.
Forecasting improves correspondingly. Leadership reports now include weekly utilization rather than monthly averages. Capacity constraints are visible at the resolution where decisions get made. The gap between the planning tool and operational reality closes.
Results
The modernization delivered both the platform modernization and the weekly visibility feature. The application now runs on .NET 8 with current Kendo UI components and modern authentication. Project managers can assign resources at the week level and leadership has access to weekly utilization data.
User Adoption
The weekly granularity addresses the core limitation that drove low usage. Reports now provide data at the resolution where planning decisions happen. The tool is becoming something people consult rather than something they update for compliance.
Performance
Complex EF interactions were made lean to lower latency on pages. Bug fixes accumulated during the modernization work resolved long-standing issues that had persisted in the legacy codebase.
Technical Debt Addressed
The database and application models are synchronized. Entity Framework migrations work correctly. Future development can proceed through the application rather than through direct SQL.
Custom Software Development
Have a legacy application that's holding your business back?
ASQI specializes in modernizing business-critical software:
- Legacy .NET and web application upgrades
- Database reconciliation and migration
- Modern authentication integration
- Custom feature development
Related Articles
The Architecture Advantage — The same architectural principles that drove this modernization project.
When to Migrate to Optix — Decision framework for evaluating legacy system migration timing.