Highlighted engagements.

Selected IT infrastructure engagements, set out in full: the situation each client faced, the work we carried out, and what changed.

The directory at the centre of this lender had been extended, patched and worked around for twenty years, and the institution had outgrown it. Nobody could say with confidence who held administrative rights, or what would break if a permission were withdrawn. A set of legacy IBM terminal applications, still in daily use on the lending desk, depended on it in ways that had never been written down.

A clean domain, with administration held apart

We rebuilt the directory on a new forest under a tiered administration model. Control of the directory and the servers now sits with dedicated, tightly held accounts; the accounts staff use each day cannot touch it. Their working access, to the lending systems and the transaction data included, carried on unchanged.

Sign-in that holds even when a password leaks

Staff authenticate with a hardware key and a known device before anything else is considered. The shared local passwords and the older sign-in protocols that had built up for compatibility were traced and switched off one at a time, each one checked for what still depended on it before it went.

The terminal applications moved last, and carefully

The IBM terminal applications could not be re-engineered, so the work was shaped around them. Their dependencies were mapped first, the old domain stayed live as a fallback throughout, and each application was proven against the new environment before its predecessor was retired.

The lender now holds a written, current account of who can administer what, the evidence sits behind it, and the cutover cost the business no scheduled downtime at all.

Scope
Active DirectoryTiered administrationFIDO2 with Conditional AccessWindows LAPSLegacy IBM terminal migration
Sector
Financial services
United Kingdom, regulated

This practice draws and engineers buildings, and its archive of design files, tens of terabytes, accumulated over decades, is the business. When we took the estate over from its previous provider, all of it depended on ageing hardware with no backups of any kind, no fault tolerance and no high availability. A failed disk would have been a catastrophe, and a quieter risk sat alongside that one: a file overwritten or deleted in error was simply gone.

Every save, committed to two machines at once

The file platform was built afresh as a hyperconverged cluster, with the storage mirrored synchronously between nodes over dedicated high-speed links. A save does not count until both machines hold it. A node, a disk or a link can now fail outright and the practice keeps drawing; the cluster rebalances itself when the hardware returns.

A way back from every mistake

Versioned backups now stand behind the cluster, tested by restoring from them, not assumed. The mirror protects the work from hardware; the backups protect it from people. A drawing overwritten on Friday afternoon can be brought back as it stood on Thursday, which is precisely what the old setup could never do.

Recovery written down as a sequence

Disaster recovery is documented in dependency order. It sets out which systems come back first, and what each one needs already standing before it can. We proved it by rebuilding a server from bare metal in an isolated environment, then watching it come back.

One hardware key, trusted everywhere

Staff sign in with a single hardware security key everywhere, including the servers that never touch the internet. The practice was given its own two-tier certificate authority, built in-house, so that even the offline systems trust the key.

The in-house software reviewed by Factor1

The practice runs line-of-business applications it built itself, and those went through Factor1, the security practice within the Centraline Group, alongside the finished environment: reviewed, hardened where it counted, and stripped of the redundant software the years had left behind.

Some months later a storm took one of the servers offline for two days. The practice learned of the failure from us, rather than from any interruption to its work.

Scope
Hyperconverged file platformHigh availability at every layerVersioned, tested backupsDependency-ordered recoveryFIDO2 passwordless authenticationOn-premises two-tier PKIFactor1 application review
Sector
Engineering practice
New York

What this provider asked us was narrow and serious: if ransomware reached the estate, and the attacker went for the backups first, as they now routinely do, would patient records survive it? On examination, the answer was no. The backups sat on the same network, reachable with the same credentials, and had not been restored from in living memory.

A copy that cannot be reached or rewritten

The backups were moved to an immutable tier under object lock, held apart from the production network. Nothing can alter or delete them inside their retention period, not a compromised administrator account, and not us. An attacker can take every credential in the building and the copy still stands.

Restored monthly, because untested is unproven

A full restore is run every month and the records opened and checked, with integrity verification between runs. The recovery objectives for the clinical systems are figures the provider has watched being met, not figures in a policy document.

The provider can now put a date on the last time its backups were shown to restore, and it is always within the month.

Scope
Immutable, object-locked backupsSegregated recovery copyMonthly restore testingTested recovery objectives
Sector
Healthcare
United Kingdom, regulated

Six offices, large video files moving between them all day, and one ageing virtual private network carrying everything. Whoever connected, an editor, a freelancer, an attacker with a phished password, landed on the whole internal network, and the security team knew it. The tunnel also had a habit of dropping mid-transfer, which the production schedule felt every time.

Access granted per application, not per network

Remote access now goes through identity, not the network perimeter. Each person reaches the specific applications they are entitled to, only from a device whose health has been checked, and freelancers on machines the group does not manage get a correspondingly narrower view. A stolen password now reaches a sign-in prompt and nothing beyond it.

The traffic sorted out at the same time

Routing across the six sites became application-aware, so a colour-grading session and a multi-gigabyte file delivery no longer fight over one line. Transfers that used to fail mid-way now simply complete.

The old tunnel is decommissioned. Connecting to the network no longer grants any access of its own.

Scope
Zero Trust Network AccessSASE architectureDevice posture assessmentSD-WAN
Sector
Media
United Kingdom and Europe, six sites

This firm's product teams could create cloud resources faster than anyone could keep account of them. Then the month-end invoices stopped being explicable. Resources nobody owned ran on for months, spending was a surprise rather than a figure, and the question of who was entitled to change production had several answers depending on who was asked.

Structure first, then everything moved into it

We built a landing zone to the Cloud Adoption Framework, management groups, policy guardrails and budgets defined up front, and brought the existing resources into it subscription by subscription. A resource now cannot be created without an owner, an environment and a cost allocation attached to it.

One set of rules for both halves

The servers still running in the firm's own building came under Azure Arc, so the same policies that govern the cloud resources govern them, and both halves of the estate report into one view.

The teams kept their speed. What changed is that the bill is now a number the firm can predict, and every running resource has a name against it.

Scope
Azure landing zoneCloud Adoption FrameworkPolicy guardrails and budgetsAzure Arc
Sector
Software
United Kingdom, cloud-native

This plant runs day and night, every day of the year, and the systems that schedule and feed the line run with it. The servers beneath them were years past their service life, but every conventional replacement plan began with the same impossible sentence: first, stop the line. The plant could not stop, so the approach was built around that constraint.

The cluster built alongside, then the work moved across

A hyperconverged cluster was stood up beside the old hardware and tested there while production carried on untouched. The workloads, already virtualised, then crossed over one at a time, live, each one watched on the new platform before the next followed.

Resilience the line can lean on

The cluster is built so that any single node can fail with the plant none the wiser, and maintenance that once needed a shutdown is now done by draining one node while the others carry the load.

The old servers were powered off months after the line had stopped depending on them. Production never paused once.

Scope
Hyperconverged infrastructureLive workload migrationRolling replacementN+1 resilience
Sector
Manufacturing
United Kingdom, continuous production

Resilience you can actually point to.

Resilience is engineered, then tested. Here is what we check holds before you have to rely on it.

No single point of failure

No one thing that takes it all down.

One server, one disk or one switch should never be able to put the business offline. We build in redundancy at every layer and test the failover, so a failed component does not interrupt the business.

Backups

Backups proven, not assumed.

Many firms hold backups. Far fewer test that they actually restore. We restore yours and confirm the files open, with integrity checked between restores, so the first real test is never the day you need it.

Maintenance

Done on schedule, before they cause problems.

Patching and health checks carried out of hours and documented, so they happen the same way every time on a set schedule.

Centraline logo Built from scratch & fully managed by Centraline