A hands-on modernization of an established shipping application. The work focused on reproducing the live application's workflows, replacing Telerik and DevExpress controls, rebuilding date pickers and multi-column selectors, replacing XtraReports with HTML-based PDF generation, consolidating shared business logic and validating quotation behaviour with Playwright.
The starting point was an established .NET Framework shipping application with a separate Web API codebase. Both applications contained implementations of overlapping business operations. For example, a change to UPS rule retrieval could require corresponding updates in both codebases, followed by separate deployments.
The legacy user interface also relied on Telerik and DevExpress controls, including XtraGrid, date pickers and multi-column combo boxes. The modernization replaced these with reusable Razor, JavaScript and jQuery-based components. DevExpress XtraReports was also removed; invoice PDFs are now generated from language-specific HTML templates through an iText conversion pipeline.
The most important constraint was functional parity. Existing postal-code normalization, decimal handling, shipment calculations, carrier-specific rules and quotation behaviour all had to be preserved. I introduced a separate CoreServices class library shared by the ASP.NET Core web application and Web API, and used Playwright to compare the quotation journey in both applications against the same database.
This case study focuses on the engineering decisions behind that work: removing duplicated logic, creating reusable UI components, replacing report generation, isolating carrier implementations and validating the modern application against the established system.
The goal was not simply to move code from .NET Framework to ASP.NET Core. The modern application had to preserve the behaviour of an established, live shipping system while addressing architectural limitations in the original application.
Existing users already depended on established workflows and business rules. The replacement needed to reproduce those behaviours as closely as possible, including less visible rules affecting shipment creation, quotations and carrier requests.
The legacy web application and Web API maintained separate code for overlapping operations. A change to a rule such as UPS service retrieval could require the same business change in both projects, followed by separate deployments.
The old interface relied on Telerik and DevExpress controls. Those dependencies had to be removed and replaced with reusable Razor, JavaScript and jQuery-based components without losing the familiar grid and listing workflows.
The legacy pages used commercial grid components from Telerik and DevExpress, including XtraGrid. Instead of introducing another commercial grid library, I developed a shared grid-rendering approach. Pages define their own columns and filters, while common rendering and interaction logic is reused across the application.
Each listing supplies column metadata through a
GridHeaderColumnViewModel. The configuration defines
header text or localization keys, widths, filter types, element
IDs, current values and dropdown options.
The common _GridHeader.cshtml partial renders both
the column-header row and the filter row. It supports text,
select, date and date-range filters, as well as columns with
no filter.
Pagination, listing toolbars and loading overlays are shared components. Common JavaScript manages filtering, AJAX row loading, selection, bulk actions, dropdown behaviour and pagination updates.
Each business area retains its own row markup and actions. For example, the invoice listing has invoice-specific columns and actions while reusing the common header, filter and pagination infrastructure.
The migration also removed other DevExpress widgets used throughout the legacy application. Rather than replacing one commercial control suite with another, I recreated the required interactions with custom JavaScript and jQuery-based controls that fit the new Razor pages.
DevExpress date-picker controls were replaced with custom date-selection components and browser-side behaviour. The shared grid renderer also supports single-date and date-range filters, with the selected values passed into the listing's filtering workflow.
Multi-column combo-box widgets were rebuilt as custom JavaScript and jQuery controls. This retained the application's need to present structured choices across multiple columns without depending on the original DevExpress component.
The replacement controls were built around the actual workflows rather than a generic third-party widget API. Razor supplied the page markup, while JavaScript and jQuery handled the client-side interactions and connected them to the application's existing request flows.
Invoice generation was another part of the legacy stack that needed to move away from DevExpress. I replaced the XtraReports-based approach with custom HTML invoice templates and an iText HTML-to-PDF pipeline, keeping document layout in editable HTML and CSS while preparing the invoice data in the application service layer.
The invoice service builds an invoice DTO from the invoice, order, customer and billing information. Invoice line items, totals, VAT values and customer details are prepared before the document is rendered.
The generation flow selects the English or German invoice template based on the user's language. It also supports separate new-style and older invoice layouts.
Invoice details and dynamically generated line-item rows are inserted into the HTML placeholders. iText's HTML converter then renders the completed HTML document into a PDF.
The generated PDF is post-processed for page numbering and footer placement. The service also generates the structured ZUGFeRD XML and combines it with the PDF as a PDF/A-3 electronic invoice.
The legacy web application and Web API had separate implementations for overlapping business operations. I addressed this by moving shared business functionality into a separate class library referenced by both ASP.NET Core applications.
In the legacy structure, a change to UPS rule retrieval could require corresponding updates in the web application and the Web API. With the shared CoreServices library, the business implementation is maintained centrally and consumed by both applications.
Carrier-specific shipment creation is separated behind a shared
ICarrierShipmentService contract. The central shipment service
receives all registered implementations through dependency injection and
selects the implementation matching the requested carrier.
public interface ICarrierShipmentService
{
Task<CreateShipmentResponse> CreateShipmentAsync(
CreateShipmentRequest request,
string webrootPath);
string CarrierName { get; }
}IEnumerable<ICarrierShipmentService>
CarrierName
Adding another carrier starts with a new implementation of the common interface and a dependency-injection registration. The central shipment creation dispatcher does not need a new carrier-specific branch for that implementation.
Functional parity also depended on retaining data transformations and calculations that were easy to overlook. These rules were consolidated into a dedicated shipment request normalizer in CoreServices.
The normalizer also contains a specific sender-postcode whitespace rule for the Czech Republic to Germany route.
This prevents formatting differences from silently changing the values sent through shipment workflows.
The calculation is applied to shipment and order request types through the shared normalizer.
To verify that the new application reproduced the existing quotation behaviour, I wrote Playwright tests that executed the quote-generation journey in both applications and compared the steps. Both applications pointed to the same database during this comparison.
Execute the quotation journey in the legacy and modern applications using equivalent shipment information.
Validate the quote-generation page throughout the journey, rather than comparing only the final displayed price.
Use the comparison to surface differences that could indicate a missed rule or an unintended change during migration.
The modernization combines the ASP.NET Core application stack with shared service architecture, browser-side components and automated end-to-end validation.
Modern web application and Web API entry points.
Shared business services, carrier logic and reusable components.
Relational data storage and lightweight data access.
Reusable listing UI, filters and interactive page behaviour.
End-to-end comparison of legacy and modern quote workflows.
Template-driven invoice PDFs with post-processing and ZUGFeRD XML embedding.
This work is centred on more than replacing an older framework. It combines a shared service foundation, reusable interface components, carrier-specific implementations and regression testing to make the application easier to evolve while protecting the workflows that existing users rely on.
Discuss a .NET Modernization ProjectDiscuss how to modernize an existing .NET Framework application while protecting its business rules, user workflows and integrations.