Skip to main content
Xalicon

Logistics

Modernizing a logistics portal without pausing operations

Incremental migration of a business-critical customer portal and driver workflow using the strangler pattern, with no cutover event.

  • Next.js
  • TypeScript
  • Node.js
  • PostgreSQL
  • Kafka
  • React Native
  • Kubernetes
  • AWS
Start a similar projectAll case studies

Sample case study — illustrative, not a delivered client engagement

Atlas Freight Services is an invented company used to demonstrate our case-study format and our approach to this kind of work. The technical detail reflects how we would genuinely deliver it; the client name is fictional and the figures under Results are design targets rather than measured outcomes.

Client

Atlas Freight Services

Illustrative regional freight operator running a fifteen-year-old portal

Industry
Logistics
Year
2025

The business challenge

Customers booked shipments and tracked deliveries through a portal built fifteen years earlier on an unsupported framework. It had no automated tests, no staging environment, and deployments happened at night with a written checklist. Two previous rewrite attempts had stalled. Meanwhile drivers still captured proof of delivery on paper, so customers could wait a day for confirmation, and the operations team fielded the resulting calls.

Objectives

  • Make the portal safe to change without a full rewrite
  • Keep the system available throughout — no maintenance windows
  • Digitise proof of delivery for drivers working without reliable signal
  • Give customers accurate tracking without calling operations
  • Leave the client’s own engineers able to continue the programme

Discovery and strategy

What we did before writing code

  • Catalogued every portal route and measured actual usage over ninety days of access logs
  • Found that a third of routes had not been used in a year and could be retired outright
  • Interviewed drivers about working conditions, which established offline capability as non-negotiable
  • Reviewed the database for undocumented consumers — six reporting jobs and two partner integrations
  • Agreed a slice sequence starting with tracking, the highest-traffic and lowest-risk capability

Solution

What we built

  • Routing layer

    A reverse proxy placed in front of the legacy application, allowing traffic to be shifted route by route with immediate rollback.

  • Characterisation test suite

    Automated tests written against the live legacy system, capturing existing behaviour precisely enough to verify each replacement — and documenting behaviour nobody had written down.

  • Incremental migration

    Tracking first, then booking, then account management. Each slice ran in parallel with output comparison before traffic was moved.

  • Offline-first driver app

    A React Native application with local storage and a queued mutation log, so a full day’s work can be completed with no connectivity and synchronised deterministically on reconnection.

  • Event backbone

    Shipment milestone events published to Kafka, giving both the portal and partner integrations a single consistent source of tracking state.

  • Data decoupling

    Change data capture kept legacy and new stores consistent while the six reporting consumers were migrated at their own pace.

Architecture

How it fits together

Strangler-pattern migration

The routing layer is the control point: each capability can be migrated, verified and reverted independently, with no coordinated cutover.

  1. Routing layerPer-route traffic control with instant rollback
  2. Legacy portalServing un-migrated routes until each is replaced
  3. Migrated servicesNode.js services behind a Next.js customer portal
  4. Driver applicationOffline-first React Native app with queued sync
  5. Event streamKafka milestone events consumed by portal and partners
  6. Change data captureKeeps legacy and new data stores consistent

Design approach

Decisions in the interface

  • Designed the driver app for one-handed use in a vehicle: large targets, minimal typing, camera-first proof capture
  • Made sync state explicit in the interface so drivers always know what has been uploaded
  • Rebuilt the customer tracking view around the question customers actually ask: where is it and when will it arrive
  • Kept the visual language of the legacy portal during migration so customers were not relearning the product mid-transition

Development process

How the work ran

  • Each slice delivered behind the routing layer with output comparison against the legacy path before traffic shifted
  • Traffic moved in increments — 5%, 25%, 50%, 100% — with automated rollback on error-rate thresholds
  • Offline sync verified with automated tests simulating extended disconnection and conflicting updates
  • Client engineers paired on every slice and led the final two independently
  • Legacy routes decommissioned only after thirty days with zero traffic

Technology stack

What it runs on

  • Next.js
  • TypeScript
  • Node.js
  • PostgreSQL
  • Kafka
  • React Native
  • Kubernetes
  • AWS

Challenges resolved

What went wrong, and what we did

Every project has these. A case study that omits them is a brochure.

  • Undocumented database consumers

    Six reporting jobs and two partner integrations read the legacy schema directly. Change data capture kept both stores consistent while each consumer was migrated on its own schedule, avoiding a coordinated cutover that would have been impossible to arrange.

  • Conflicting offline updates

    Two devices could update the same job while offline. A per-field last-writer-wins policy with an explicit conflict queue for genuinely ambiguous cases resolved this without silently discarding a driver’s work.

  • Behaviour nobody could explain

    Several pricing rules existed only in legacy code with no documentation or owner. Characterisation tests captured the behaviour exactly, and the rules were then reviewed with the commercial team — two turned out to be long-standing bugs customers had adapted to.

Results

Objectives and design targets

Because this is a sample case study, these are the objectives and design targets agreed in scope — not measured business results.

  • Migration approach

    No maintenance windows

    Illustrative objective, delivered through per-route traffic shifting

  • Routes retired

    About one third of the legacy surface

    Based on usage analysis during discovery

  • Proof of delivery

    Target: confirmed within minutes

    Design target replacing next-day paper confirmation

Client feedback

In their words

Placeholder quote

This quote is sample content shown to demonstrate the layout. It is not attributable to a real person or organisation and will be replaced only with a genuine, approved testimonial.

  • “Sample content for design demonstration. This quote is illustrative and is not attributable to a real client.”
    Sample Client ContactOperations Director (illustrative)

Related services

The practices behind this work

More work

Other case studies

All case studies

Similar situation?

Start a project like this one

Tell us where you are. We will tell you how we would approach it and what we would want to understand first.

Start Your ProjectTalk to us first

Prefer email? contact@xalicon.co