← Back to selected work

Renovotec · Led dashboard modernisation

LastMile

Changing the foundations of a delivery platform—not starting again with an empty project.

Commercial platform · Migration completed; rollout unconfirmedC# · .NET 8 · EF Core · QuestPDF
Problem
Modernise an established delivery dashboard with obsolete dependencies.
My part
Led the .NET / EF Core migration and replacement application services.
Outcome
Migration completed; modernised dashboard rollout not yet confirmed.
LastMile dashboard showing depot delivery and parcel charts
The LastMile dashboard in a local environment. Displayed totals illustrate the interface; they are not measures of my personal impact.

What changed

AreaBeforeMy migration work
Platform.NET Framework 4.8 / EF6.NET 8 / EF Core
User rolesLegacy dependenciesReplacement user-role service and authentication integration
Interface contractsMVC5 response conventionsPreserved expected JSON property names
Diagnosticslog4netILogger and slow-report logging
PDF reportsRotativa and Razor viewsQuestPDF implementations for operational reports

Context and scope

An established delivery platform carries accumulated expectations: who can sign in, what each role may access, which fields an interface receives and how operational documents are laid out. Modernisation has to account for those expectations as well as the framework version.

My scope was the dashboard migration and replacement application services, not the original LastMile product. The platform is commercially available; the rollout of the modernised dashboard remains unconfirmed. That distinction separates completed engineering work from customer deployment.

What I owned

LastMile is an established commercial electronic proof-of-delivery platform. I modernised its dashboard and led the move from .NET Framework 4.8 and Entity Framework 6 to .NET 8 and EF Core.

My responsibility was understanding an unfamiliar system, replacing obsolete dependencies and carrying its existing behaviour through the migration.

Compatibility was the work

Changing the target framework was only part of it. Authentication, user roles, data access, mapping and the responses expected by the existing interface all needed attention.

I implemented a replacement user-role service and preserved MVC5-compatible JSON property names. Those are small-looking details with a large consequence: the rest of an application already depends on them.

Under the hood: services and diagnosis

The development history records role assignment during authentication, controller access changes, repository registration and data mapping alongside the framework migration.

Logging also moved from log4net to ILogger. Later work added logging for reports taking more than twenty seconds. That threshold helps investigation; it is not a claim that reports became twenty seconds faster.

Reports had to keep doing their jobs

I replaced Rotativa-based PDF generation with QuestPDF across operational reports, including signatures, barcode labels, run sheets, depot operations and proof of delivery.

This was more than replacing a package reference. Existing views contained the information, layout and orientation each report needed. I worked through those report types individually, rather than treating compilation as proof that the output was correct.

What was delivered

The migration and replacement services were completed, followed by operational reporting changes. LastMile itself is available to customers; rollout of the modernised dashboard remains unconfirmed.

Engineering decisions and trade-offs

The following decisions connect the implementation to its practical constraints. Each separates what I changed from what still needs verification.

Preserve interface contracts

Constraint
Existing screens depended on response conventions from the older MVC application.
My approach
I preserved expected JSON property names while moving the implementation to the new framework.
Implication
Compatibility reduces the changes required of existing consumers. A successful build alone cannot demonstrate that every screen still behaves correctly.

Replace incompatible services deliberately

Constraint
Some legacy dependencies could not simply be carried into the new runtime.
My approach
I implemented replacement user-role behaviour and authentication integration, alongside repository and mapping changes.
Implication
The work concerned application behaviour as well as package compatibility. Access-sensitive paths require explicit verification rather than assumptions based on sign-in success.

Rebuild reports as reports, not package references

Constraint
The previous PDF approach depended on views and rendering behaviour that needed replacing.
My approach
I implemented operational reports in QuestPDF, including proof of delivery, signatures, labels and run sheets.
Implication
Each report has its own information and layout needs. Changing rendering technology creates an output-verification task, not merely a compilation task.

Make slow work observable

Constraint
A slow report needs diagnostic evidence before its cause can be established.
My approach
I moved logging to ILogger and added logging for reports exceeding twenty seconds.
Implication
The threshold identifies work worth investigating. It is not a benchmark result or evidence of a twenty-second improvement.

Evidence and limits

Different evidence answers different questions. This record distinguishes a visible demonstration, implementation history and validated operational outcomes.

Development history

What it supports: Records migration completion, service replacements and subsequent operational reporting work.

What it does not establish: Does not independently confirm deployment of the modernised dashboard to customers.

Dashboard screenshot

What it supports: Shows the application context and delivery/parcel reporting interface.

What it does not establish: Displayed totals are interface data, not a measure of my impact or verified customer volume.

Migration comparison

What it supports: Makes the changed frameworks, services, diagnostics and reporting approach explicit.

What it does not establish: Summarises implementation scope; it is not a published performance study.

Lessons and next acceptance checks

Migration work rewards attention to behaviour that is easy to overlook: a property name, a role assignment or a document’s orientation. Those details are part of the product contract even when they are not the headline feature.

Before claiming deployment success, the remaining evidence would need to establish the release status and acceptance results for access control, representative dashboard paths and report outputs. I keep that gap visible rather than borrowing the original platform’s commercial status.

See the work

Another side of the work

Frank →PickByLight →PackingBench →Teremware × MAI →OpsBridge →

Talk to me about a role →