01 Background
The client
Global Broadband Solutions (GBS) is a telecom and internet service provider in the Democratic Republic of the Congo. Alongside connectivity, GBS runs and maintains infrastructure for its customers, including the email systems those organisations depend on every day.
One of those systems served a government client. For the institution, email is how public work gets done. For GBS, it is their name on the service.
- Sector
- Telecom and ISP
- Region
- Central Africa
- End customer
- Government body
- Engagement
- 2 days
02 Diagnosis
The problem
The email server had not received a security update since 2014. The software was from the same era. By the time we were brought in, the whole system was more than a decade out of support.
Out-of-date software is not a paperwork problem. Every weakness found in those eleven years is publicly documented, and for many the tools to exploit it are freely available. A mail server has to be reachable from the internet to do its job, so it is discovered and probed constantly.
-
No security updates for over a decade
Known weaknesses across every layer of the system, none of them patched, all of them reachable from outside.
-
No safe way to upgrade in place
The gap between the old system and a current one was far too wide to bridge on a live server. Attempting it would very likely have broken the service outright.
-
Downtime was not acceptable
This was live email for an organisation that could not go offline. A message that bounces during a migration may never be sent again.
Underneath it all sat the risk that rarely gets noticed until the damage is done. An unmaintained mail server is a prime target for hijacking as a relay for someone else’s spam, and when that happens the domain is blacklisted worldwide and legitimate email quietly stops arriving. That outage lasts far longer, and is far harder to undo, than any planned migration.
03 Execution
Our solution
We built the replacement alongside the live system rather than touching it, so the existing server kept working right up to the moment it was no longer needed.
-
Established control before changing anything
Administrative access had degraded over the years. Nothing else can safely start until you can prove you control what you are about to move.
-
Backed everything up, then verified it
A full backup of accounts, mail data and configuration, checked against the live system to confirm it was complete. A backup nobody has verified is an assumption, and assumptions are what turn migrations into incidents.
-
Built the new server in parallel
A clean build on Ubuntu 24.04 LTS with a current, fully supported mail platform. The old system stayed live throughout, so the migration never depended on production being taken down.
-
Moved everything across, including the awkward parts
Accounts, credentials, mailboxes and settings. Two things that commonly go wrong in a migration this old were handled deliberately: users kept their existing passwords, so nobody had to be told to reset anything, and mailbox contents were rebuilt and re-verified so every folder appeared where the user expected it.
-
Cut over with zero downtime
A final catch-up sync brought the new system up to date and traffic switched across. People kept sending and receiving throughout. Measured downtime: zero seconds.
-
Hardened it so it cannot be turned against them
The biggest single risk to any mail server is being used as an open relay, where an attacker pushes spam through your server so it arrives carrying your organisation’s reputation. The server now relays only for authenticated users on approved domains.
Alongside it: encryption enforced with valid certificates, automatic blocking of repeated failed logins, the firewall cut back to what needs to be open, and automatic security updates so the system cannot drift back into the state we found it in.
04 Duration
Timeline
05 Stack
Tech stack
- Ubuntu 24.04 LTS
- Current supported mail platform
- Enforced TLS/SSL
- Intrusion prevention
- Automated security patching
06 Outcome
The outcome
| Criteria |
// After
BPDoxS
|
// Before Legacy server |
|---|---|---|
| Operating system | Current and fully supported |
Unpatched since 2014 |
| Mail platform | Current supported release |
Decade-old release, out of support |
| Open relay risk | Closed, authenticated senders only |
Present, with blacklisting the likely outcome |
| Encryption | Enforced across all domains |
Outdated and inconsistent |
| Brute-force protection | Repeated failures blocked automatically |
None |
| Security patching | Automatic, so it cannot drift again |
Abandoned since 2014 |
| Password resets | None, users kept their credentials |
Expected on any migration this old |
An eleven-year-old mail system replaced in two days, with zero downtime and zero data loss.