DigiBoffinsShaping Digital Ideas

Case file 034Logistics2025

Northgate Freight: AWS migration and DevOpsA platform that scales itself at peak.

Northgate's parcel-tracking platform ran on ageing servers that slowed every evening and fell over at peak. We moved it to AWS with no lost orders, and it now scales, deploys and recovers on its own.

Start a project like thisRead the story
Client
Northgate Freight Ltd
Sector
Logistics and parcel delivery
Scope
AWS migration, DevOps, cost optimisation
Timeline
7 months

Outcomes

Full results
Lower monthly hosting bill
43%
Uptime, up from 99.2%
99.98%
From merge to live, instead of a monthly window
12min
The challenge

Why Northgate's platform couldn't keep up

Northgate tracks 140,000 parcels a day for retailers and their customers. Its platform ran on twelve servers in a leased data centre, and a review of a year of incidents, bills and releases showed four problems.

See how we fixed it

  1. Capacity was fixed, so every evening rush slowed tracking pages, and the pre-Christmas peak took the platform down for hours.

    • Twelve servers sized for an average day
    • No way to add capacity in under a week
    • One data centre, so one failure took everything
    It fell over at peak01 / 04

    Key finding

    70 hrs

    of downtime in the year before the move

    Hours down per month
    JulyDecember

    “Every December we'd hold our breath and wait for it to go down.”

    Head of operations, research interview

  2. The servers were sized for December and sat mostly idle the rest of the year, on a lease that grew every renewal.

    • Hardware and licences on a five-year lease
    • Spare capacity bought for one month a year
    • Costs split across invoices no one owned
    Paying for peak all year02 / 04

    Key finding

    18%

    average server use outside December

    Monthly hosting bill, £k
    20202025

    “We were paying for Christmas twelve months a year.”

    Finance director, research interview

  3. Each release was a four-hour, out-of-hours window with steps done by hand, so fixes waited weeks and changes were batched until they were risky.

    • Manual steps from a 40-page runbook
    • No test environment that matched production
    • 18% of releases rolled back
    Releases were an event03 / 04

    Key finding

    1 a month

    release window, at four hours each

    “A two-line fix could wait three weeks for the next window.”

    Lead developer, research interview

  4. Backups went to tape once a night. Restoring after a failure meant rebuilding servers by hand, which the team had never practised end to end.

    • Nightly backups, so up to a day of data at risk
    • Restores never tested
    • On-call engineers woken for every alert
    Recovery took a night04 / 04

    Key finding

    9 hrs

    to recover in the last real outage

    “We had backups. We just didn't know how long a restore would take until we needed one.”

    Infrastructure manager, research interview
The solution

We moved it to AWS and took the ops work out

Four changes, made in waves so tracking never stopped: containers that scale with demand, a pipeline that ships every merge, a bill sized to real use, and a platform spread over three data centres that recovers on its own.

  1. Containers that scale with the traffic

  2. Every merge live in about 12 minutes

  3. A bill that follows real use

  4. A platform that heals itself

Swipe to see each screen

  1. Before: Twelve fixed servers, sized for an average day

    After: Containers that scale with the traffic

    The tracking platform now runs in containers on Amazon ECS. As traffic climbs in the evening, more start within a minute, and they wind down again overnight, so the busiest day of the year runs like any other.

    How we did it

    • Services split into containers on ECS with Fargate, no servers to manage
    • Scaling rules on CPU and queue depth, tested at six times normal traffic

    Result0 peak outages

  2. Before: A four-hour release window once a month

    After: Every merge live in about 12 minutes

    A pipeline builds, tests and ships each change through a staging copy of production. New containers take traffic only once they pass their health checks, and a bad release rolls itself back.

    How we did it

    • GitHub Actions pipeline with 612 automated tests and a security scan
    • Blue/green releases, with automatic rollback on failed health checks

    Result23 releases a week

  3. Before: Paying for December all year round

    After: A bill that follows real use

    Capacity now matches the hour, not the busiest day. Steady workloads moved to a Savings Plan, old data to cheaper storage, and every service is tagged so each team sees what it spends.

    How we did it

    • Compute Savings Plan for the base load, on-demand containers for the peaks
    • S3 lifecycle rules moving old tracking data to archive storage

    Result−43% a month

  4. Before: A failure meant a night of rebuilding

    After: A platform that heals itself

    Everything runs across three availability zones. When one fails, traffic moves to the other two, lost containers are replaced and the database fails over in minutes, with nobody woken up.

    How we did it

    • Multi-AZ Amazon RDS for PostgreSQL, with point-in-time recovery
    • AWS Backup copies to a second region, restored in a drill every quarter

    Result9 hrs → 6 min

Also in the platform

  • Infrastructure as code

    Every resource defined in Terraform, reviewed like application code.

  • Locked down

    Private networks, least-privilege access and encryption everywhere.

  • Quieter on-call

    Alerts only for what needs a person; the rest fixes itself.

  • Tested backups

    Copies in a second region, with a restore drill every quarter.

  • Cost by team

    Every service tagged, with a monthly report of who spends what.

How we worked

Migrated in four waves, with tracking live throughout

A team in Zirakpur worked with Northgate's two infrastructure engineers in Leeds. Each wave moved a few services, ran beside the old servers for a week, then switched over.

Timeline

30 weeks in all

  1. 1Assess

    3 weeks

    Every server, dependency and bill mapped, and the move planned in waves

  2. 2Foundation

    5 weeks

    Accounts, networks, security and the pipeline, all in Terraform

  3. 3Migrate

    14 weeks

    Four waves, each run side by side before switching over

  4. 4Optimise

    8 weeks

    Savings Plan, storage tiers, scaling tuned on real traffic

The team · 8 people

  • Cloud architect1
  • DevOps engineers3
  • Backend engineers2
  • Database engineer1
  • Site reliability engineer1

Working together

Demo
Every Friday
Overlap with Leeds
4 hours a day
Switch-overs
Sunday mornings
Shared tools
Slack, Jira, PagerDuty

The stack

Amazon ECS · AWS Fargate · Amazon RDS · Amazon S3 · CloudFront · CloudWatch · AWS Backup · Terraform · GitHub Actions

The results

Faster, steadier and cheaper to run

In the six months after the move, the platform got through its first December peak without a minute of downtime, on a bill 43% smaller than the data centre's.

a month to host, down from £38kData centre £38k → On AWS £21.7k
£21.7k
of releases rolled back, down from 18%Data centre 18% → On AWS 2%
2%
of tracking pages slower than a second at peakData centre 34% → On AWS 3%
3%

Measured across all traffic to the tracking platform, July – December 2025. Compared with the same months of 2024 in the data centre. The bill includes compute, database, storage, network and support.

Built with

The services behind these results. Each one you can start with on its own.

All services
In their words

What the client said

December used to be the month we dreaded. This year our busiest day came and went, and nobody on the team even noticed.
HMHelen MarshHead of Technology, Northgate Freight Ltd
N

Northgate Freight Ltd

Logistics and parcel delivery · Leeds

Worked together
7 months
Orders lost in the move
0
Still working together
Yes, on support

Outgrowing your servers, or your hosting bill?

Tell us what you run today and what worries you about it. We'll show you how we'd move it, and what it would cost to run.

Start a project like thisSee more work
  • Free 30-minute call with the team
  • Reply within one working day
More case studies

Related cloud and DevOps case studies

All case studies

Tell us what you’re building.

Share a few details and we will come back to you to plan the next step.

What happens next

  1. 1

    You share your idea

    A few lines on your goals, users and timeline are enough to start.

  2. 2

    We talk it through

    We discuss your goals on a call and suggest an approach.

  3. 3

    You get a proposal

    We follow up with a proposal and clear next steps.

Project details

Fields marked * are required. We never share your details.

Chat with DigiBoffins

Hi! Click on the WhatsApp icon below to reach our team instantly.

Our team typically replies within a few minutes.

DigiBoffins

Support Team