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.