The rules changed
A compliance requirement, an audit, an insurer's condition, or a vendor requirement you cannot decline. Somebody outside the business set a deadline you did not choose.
Business Continuity & Software Evolution
The business changed. The application did not.
End-of-life Linux and BSD rescue, server migration, runtime upgrades, fixes and new capabilities for PHP, Perl and Python applications.
Software gets old. Vendors stop supporting it. The business still depends on it.
We keep the application running while moving the underlying system onto ground that is still maintained. We preserve what works and change what the job requires. Where it needs to move, we move it. Where it can stay, we keep it working. Where the business needs more, we extend it.
Already know what you need?
Since 2000, working on production systems. Linux and BSD, and the languages that run on them.
No provider, framework or host pays us a commission. What we recommend is what we would do.
All engineering work is done on clones. Your system keeps serving until you approve the cutover.
A new regulation arrives that the application was never built to meet. A vendor reaches end of life. A customer introduces new requirements. A provider changes its platform. An interface the system depends on moves to a version it cannot meet.
The application may still be working exactly as it should. The environment around it is what changed.
A compliance requirement, an audit, an insurer's condition, or a vendor requirement you cannot decline. Somebody outside the business set a deadline you did not choose.
No more security updates for the version you run. A scanner flagging findings nobody can clear. The system is still online, still working, and nothing is arriving to fix it.
An API changed version. A payment processor was replaced. A partner switched from CSV to JSON. Something the application connects to moved, and it did not move with it.
No documentation. Patterns a new hire has never seen. A change nobody wants to risk making. The people who understood it are gone, and the reasoning went with them.
A report that has quietly been wrong for a year. A capability the business needs that the software will not allow. It works exactly as intended — what was intended is no longer what the business needs.
The copies exist. Nobody has proved they serve, nobody knows what is missing between the last one and the failure, and nobody has timed it. On a system whose install media and repositories are gone, that is not a restore — it is archaeology, under pressure.
Zero assumptions about recovery. We do it and time it.
These are not alternatives. The right approach depends on the application, its dependencies, operational requirements and the amount of change the business can accept.
Most systems move. Some cannot move yet. Some will not move at all — a license bound to the hardware, a vendor who is gone, source nobody has.
Where a system stays, the work is moving the boundary instead — what faces the outside is current software, and the application stays where it is.
Most estates are a mix. Which systems get work, and in what order, is your call — budget, timing or appetite.
The audit tells you what each one costs to leave as it is.
Engineering changes are built and tested on clones. Your system keeps serving until you approve the production cutover.
Two things, and everything is one of them.
Rescue
A system past end of life, kept working.
Some of it can stay where it is. Some needs layering or containerizing. Some has to move. The audit establishes which is which, and each path is priced on its own.
Four paths, assessed in that order, and we stop at the first one that works. Most jobs stop at the first — a hosting company does not earn on the deeper paths, and a development shop does not earn on the shallow one.
Everything is built on a clone. Production keeps serving until you approve the cutover.
More on EOL rescue →Where moving is not possible.
Your application stays exactly as it is. Everything around it moves to supported versions, on hardware we choose rather than the hardware it is stranded on, and we put protection in front of it.
Not the same as running new workloads in containers. Building for containers starts from a clean image; here the starting point is a system that already runs and has to behave the same afterwards. Price depends on what the source is and where it is going.
The frozen component stays frozen, so ongoing EOL maintenance is part of the arrangement.
More on containerizing →A working server moved to new hardware or a new provider.
The versions stay where they are.
Server and application migration →Code on a PHP version that stopped getting patches.
Usually compatibility work rather than a rewrite, including abandoned dependencies that need to be maintained as part of the work. Where a dependency has to be forked to survive the move, who holds it afterwards is agreed before we start.
PHP upgrade and modernization →Scripts and applications on interpreter versions that are no longer shipped.
Three different problems, one thing in common: the interpreter version is rarely the work. What is gone is the packages, the assumptions nobody wrote down, and the utilities that behave differently on the new base.
More on interpreter upgrades →A supported system brought to the latest release on the versions it already runs.
Usually not optional — an insurer, an auditor or a scanner set the deadline. No version moves, and nothing in the application code has to change. Proved on a copy first, because point releases move defaults even when they do not move versions.
More on patch upgrades →The job nobody will quote or quotes to be turned down.
Something is broken, wrong, or doing what it was told rather than what was meant. A display fault, a calculation that has been quietly wrong, a form that stopped submitting, a report that will not run.
PHP, Perl or Python. Scoped against what it does now, so the fix does not become a project.
Application fixes →Adding what the business needs without replacing what already works.
From one new field to a full feature with cross-vendor API and logic integration. Connecting it to something new. Removing steps somebody is doing by hand.
Built on ground that will accept it. Where the ground will not, that gets established first rather than discovered halfway through.
Application feature development →What your system actually is.
Stack dependencies and code compatibility in detail. It inspects your production system — the only thing that does — and it is where the constraints that are not in the code turn up: a license bound to hardware, a vendor who no longer ships, source nobody has.
Credited against the work if you go ahead, and it stands on its own if you do not. If we find evidence that something has already got in, you hear about it before anything else happens.
More on the audit →One document. Two readers.
Examined from the same position as any user, customer or partner — no privileged access, nothing behind a login the public cannot reach. It establishes what the technology does, what is exposed, and what each option costs and leaves standing.
It stays factual. It does not conclude and it does not characterize. We do not provide legal advice.
More on technical scope →What you run
What degrades them
Entry pointLegacy.
A new report, a new function, or a new tool connected. The new tool expects current versions and will not connect to yours. Changes to the application are slow, because few people understand it and there is no safe way to test them. The result is usually a second system built around the old one, and both then have to be maintained.
Triggers downstreamWork is done outside the system in spreadsheets and manual steps, and changes the business wants — a new product line, a new sales channel, a client with requirements the system cannot meet — are deferred or dropped. And a second system to maintain is more surface to patch and more nobody documented — it feeds security risk and slow recovery.
Entry pointEOL.
After standard vendor support ends, new vulnerabilities may remain unpatched unless extended support, backports or custom maintenance cover them. They are published in public databases, along with the versions affected, and attackers scan for systems running those versions. Older components also often cannot support current defenses such as multi-factor authentication or modern encryption.
Triggers downstreamA breach, caused by an unpatched component that has a published exploit. A compromised site is commonly used to host phishing pages, spam, or redirects to scam, gambling, pharma, or adult sites. Search engines flag it, browsers block it outright or show a warning before it loads, and the domain's search ranking drops. Recovering the ranking takes months after the site itself is clean. A breach is where legal exposure begins, and it is when slow recovery stops being theoretical.
Entry pointEOL, legacy, or a new regulation or requirement the current system does not meet.
PCI-DSS (card payments), HIPAA (health data), and GDPR (personal data) all require you to manage known vulnerabilities. An unpatched component with a published exploit is exactly what they are asking about. EOL components do not always fail an audit outright, as auditors will consider compensating controls. They do become a finding you document and defend every cycle. Where it cannot be justified, consequences include fines and, for card processing, losing the ability to take payments.
Triggers downstreamA failed audit, fines, or loss of card processing. And a finding with a date on it is what legal exposure is built from.
Entry pointA breach or contract failure on a system that was EOL or legacy — or a new regulation the system was never built to meet.
Regulators and courts assess whether you took reasonable care. What you knew, when you knew it, and what you did about it becomes the question, and a published EOL date is a date somebody else can point at. Contracts committing you to protect client data can be breached by an incident on an unsupported system. Cyber insurance policies commonly include conditions about maintaining and patching, which gives the insurer grounds to examine the claim closely.
Triggers downstreamRegulatory action, a client claim, a denied insurance claim, or a lawsuit, settlement, or class action. Nothing further. This is where the chain ends — but what the technology actually did is a question of fact, and it is usually the one nobody can answer.
Entry pointEOL and legacy, separately.
Backup and recovery tools support current operating systems and databases. Older versions are often unsupported, which makes backups harder to create reliably and harder to test. If the system depends on specific old hardware, sourcing a replacement after a failure can take weeks rather than hours. Restoring a system few people understand and that was never documented takes far longer than restoring a standard one. In some cases it cannot be rebuilt at all: no install media, no license that still activates, and no one who knows how it was configured.
Triggers downstreamDowntime measured in days or weeks, or a system that cannot be brought back. Nothing further, and nothing above it survives without this one.
Changes are proved before production cutover. We establish that first. All engineering work is done on clones.
The review — what your situation is. Free. One runtime instance. A broad overview — how much there is, what is forcing the timeline, and how much change the business can absorb. Context, before anything is opened up.
The audit — what your system is. Priced above. It examines stack dependencies and code compatibility in detail. It inspects your production system — the only thing that does — and it is where the constraints that are not in the code turn up: a license bound to hardware, a vendor who no longer ships, source nobody has.
The path forward — what can be done about it. Which paths are available, what each costs, and what each system costs to leave as it is. Across an estate, which systems have a deadline attached, which are required but undated, and which are elective. A fixed price in writing that is yours to keep.
Your call, your pace. We assess and recommend. You decide what happens and when, and how much of it happens at once.
If we find evidence that something has already got in, you hear about it before anything else happens.
We estimate the hours upfront. Take the quote as a fixed total or as a rate × hours — the number is the same either way.
Before we start, you get two figures: the quoted price and a hard ceiling at 25% above it. Anything past that ceiling on the quoted work is ours to absorb.
Within any single job, one rate covers due diligence, architecture and build. Due diligence is usually the largest share.
Start here
We'll sort your project by priority so the most urgent work gets handled first.
Each piece is priced on its own. You choose what to fund and when.
The first review is free, with no obligation to proceed.
Start a free review →9am–5pm Eastern, Monday–Friday. Onboarded clients have 24/7 access.
Prefer to talk first?