CentOS 5, 6 and 7
CentOS 5 ended in 2017, 6 in 2020, 7 in June 2024. You are not an outlier and you are not late.
EOL rescue & migration
Your application works. The ecosystem is the problem.
Move the foundation. Keep the building.
We clone your existing server, reproduce the working stack, cut over in your maintenance window, and keep the old server available for rollback.
Engineering changes are built and tested on a clone. We build against a copy, and it keeps running until you approve the cutover.
Start with a free review.
For new clients: one free review covering one application on one server or hosting instance. Review terms →
Production keeps serving
Your current server keeps running while we build the new one.
Rollback is planned before cutover
Traffic returns to the original server. The rollback plan accounts for any data written during the cutover period.
Keep your existing stack
Minimal, vetted changes at the OS layer — targeting zero changes to your application.
It worked for years. Then the ground underneath stopped moving.
Your application was built around it, your configuration is understood, and nobody wants to change a working production system without a reason. The problem isn't that your application stopped working. It's that the operating system underneath it stopped receiving support and security updates.
You didn't make a bad decision. The environment simply reached the end of its supported life. Now the goal is to move the foundation without disturbing everything built on top of it.
Ubuntu 16.04 and earlier
Different family, same predicament, and largely ignored because everyone is writing about CentOS. The population is bigger than people assume.
Anything else stranded
Older Debian, long-abandoned RHEL, SUSE, and FreeBSD boxes untouched for fifteen years. CentOS is where we specialise, not where we stop.
For businesses running applications that are too important to replace casually. Legacy PHP applications. Internal business systems. Customer portals. Custom databases. Vendor-dependent applications. Old Linux and BSD servers that everything else was built around.
Linux and BSD: CentOS and successors · Ubuntu · Debian · RHEL · FreeBSD incl. jails and ZFS. End of life means no more security patches or bug fixes. Repositories are gone, supported packages stop being produced, and installing anything newer means unsupported workarounds.
Fix the foundation. Don't demolish the building.
We start with the smallest change that keeps your application working. The review establishes which path fits your system.
We offer all five paths. Your application, its dependencies and the business requirements decide what is needed. You choose the scope and timing.
Starting prices are shown below. Your scope and total price are agreed before work begins.
| Path | When it applies | What changes | Starting price |
|---|---|---|---|
| 1 — Minimal change | A working application can move with limited changes | Supported base; application preserved | From $199 |
| 2 — Layer and containerise | The existing runtime must be retained | Supported surrounding services and isolation | From $199 |
| 3 — API-fy it | The application works but needs a modern interface or integration layer | New or enhanced API connecting the existing application to a modern layer | From $499 |
| 4 — Refactor and modernise | Compatibility requires code work | Code adapted to a current stack | From $1,000 |
| 5 — Customise and extend | The business needs additional capabilities | New features and workflow changes | From $5,000 |
Path 1 — Minimal change
from $199 Right for most casesThe minimum required for continuous operation.
The starting price is the simplest version of it: one runtime instance, a same-branch move, with the target OS and web stack stood up. The free review establishes whether this is the likely path; the mandatory audit confirms the scope before engineering begins.
Your operating system moves to something supported. Your application stays where it is, with minor changes only where the new base genuinely requires one.
Solves: patches arrive, repositories exist, installing things works again, and a drive failure stops being terminal.
Leaves open: the application is still the version it was. It will still refuse an integration that needs something newer.
Path 2 — Layer and containerise
from $199 The hard casesWhere Path 1 is not possible.
Your application stays exactly as it is. Everything around it moves to supported versions, on suitable hardware agreed with you rather than the hardware it is stranded on, and we put protection in front of it.
This is 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, with its own library versions and fifteen years of undocumented state, and it has to behave the same afterwards.
Solves: a supported, patchable, integrable platform with one frozen component inside it — rather than a frozen platform. The workload moves to suitable hardware agreed with you, so ageing disks and a machine in its eighth year stop being the thing that ends it.
Carries on: the frozen component stays frozen, so ongoing EOL maintenance is part of the arrangement. Infrastructure, licenses and recurring maintenance are identified and priced separately in the proposal.
Path 3 — API-fy it
from $499 Connect to a modern layerKeep the application working. Give it a modern way to connect.
We develop a new API or enhance the one you already have, so a modern interface or service can use the existing application's functions and data through that API.
The existing application continues to do its job. The modern layer handles the new interface or integrations, while the API connects the two. The review establishes which operations can be exposed and what changes the application needs to support them.
Solves: access from modern interfaces, services and integrations without replacing the whole application.
Leaves open: the existing application's runtime and dependencies still need maintenance or containment. An API does not remove their EOL exposure.
Path 4 — Refactor and modernise
from $1,000 Makes change possibleWhere the stack cannot be made compatible.
Your application is rebuilt to do exactly what it does now, on code that runs on a current stack. Same functions, same behaviour, proven side by side before anything switches.
Solves: the compatibility constraints addressed by this work. No ongoing maintenance of the replaced EOL components, and the server can host other things alongside — which usually consolidates servers you pay for separately.
Path 5 — Customise and extend
from $5,000 Requires a modernised applicationThe only path that is a choice.
Keeps what worked, drops what never did, and adds what you have been unable to build for years. Either Path 4 gets the application there first, or it is already current. Larger projects run well beyond the starting figure.
Solves: the ceiling. New features become possible again.
We assess the paths in this order and recommend the least change that meets the requirement. Paths can be combined where needed: containment or migration can support an API, and an API can support later extension. Most jobs are Path 1. We explain the recommendation and price each component separately.
This is a business call. If your system has a supported upgrade path and a clean migration route, we will tell you.
How we work out which one you are in
The review. Free, one runtime instance. What you run, how far it has drifted, and the realistic target. It establishes the initial direction. The mandatory audit confirms the dependencies, constraints and final scope before engineering begins.
The audit. Mandatory for every job. $100, fully credited toward the service you choose. 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 licence bound to hardware, a vendor who no longer ships, source nobody has.
Assessment does not change your application or configuration. Production inspection, cloning and database capture can consume resources; any operation that may require locking, a pause in writes or a maintenance window is coordinated before it runs. Engineering work begins after you agree the path and price.
Five steps after the review
01
Audit
Mandatory. $100, fully credited toward the service you choose. Dependencies, compatibility and constraints examined before the plan is finalized.
02
Clone
We build the target and put your data on it. Production untouched.
03
Build & test
Output matches, mail delivers, cron fires — not just that pages load.
04
Cutover
Final sync and switch, in your quiet hours. Nights and weekends included.
05
Rollback held open
Original server available for 30 days, with a plan for traffic and new writes.
Downtime model. Everything except the final sync happens while your production server is online. The switch is a short, agreed maintenance window in your quiet hours — scheduled by you, not by us.
Access, credentials and data. We work with the least access that does the job, on infrastructure you control where you prefer it. Credentials are yours to issue and revoke, transfers are encrypted, and a verified backup exists before anything is touched.
Schedule. The proposal sets the build and test schedule, the cutover window and the rollback period. Data volume, transfer speed, dependencies and acceptance testing determine the timing.
Clone location and retention. Before data is copied, agree where the clone will run, who can access it, which sensitive data is needed for testing, and how long copies are retained. Confidentiality and data-handling requirements are established before access is granted.
What you actually get
Not a vague engagement. Things you keep, each of which you can point at.
Migration plan you can read and question
Dependency and stack inventory
Target OS recommendation, with reasoning
Clone and test environment
Application testing against real behaviour
Cutover in your maintenance window
Rollback capability, not rollback theory
Original server retained for 30 days
Honest split of what needs doing now vs later
We deliver. You test and approve.
You do not have to understand package sets, containerisation or any of the rest. Working it out without gambling with the server that runs your business is what you are paying for.
We deliver
The build, the reproduction, the testing we can do, the cutover, and the rollback if it comes to that.
You test and approve
We can confirm pages load, mail delivers and cron fires. We cannot know that invoice totals match, or that the report finance relies on came out the way it always does — nobody outside your business can. Nothing switches until you say so.
Proof
Where the five paths came from
Our practice is led from the CTO seat at a concierge hosting company, where end-of-life upgrades are policy driven. Hundreds of production systems moved off unsupported operating systems, on a schedule. Migrating since 2000 — porting between Linux and BSD, and Perl to PHP, before most of the systems on this page were built.
Our processes carry the experience forward. A concierge provider cannot suspend a customer and move on — the system has to be moved, and if the application cannot come with it, something else has to be worked out. We built each path because we ran out of alternatives.
Our hosting work includes receiving abuse complaints, processing and escalating them, and issuing notices to the customers responsible. That operational experience informs the risks described here.
From our own logs
We once installed a required package by hand on an EOL box, resolving the dependencies ourselves. It installed. It worked. Days later the server began crashing, at no fixed hour, with nothing useful in the logs and nothing pointing at the package.
The failure does not arrive when you make the change. It arrives later, somewhere else.
Why EOL migration is different from a normal server upgrade
A normal upgrade moves versions on a system that still receives support. Here the ground underneath has stopped moving, and that changes the method.
No in-place pathThe oldest generations have no supported route forward, and a cross-family move is a rebuild by definition.
Everything moves forwardOn a supported system a problem waits for a patch. Here the only route is onward.
Repositories are not only staleThey are moved, gone or untrusted. Reinstalling a package you already have is beyond reach, and what is still reachable comes from somewhere you did not choose.
Installing anything is a risk eventNew packages expect libraries you do not have. On an unsupported system, installing software is itself a risk event — which is what the story above is.
Testing is not optional, even for usAfter twenty-five years we still build a clone before touching an EOL system. Not because we are unsure of the method, but because these systems fail in ways experience does not predict.
A hardware failure can become a recovery problem
No attacker required. The hardware has been running as long as the software. A drive fails, the repositories are gone, the install media is archived, and the stack cannot be reinstalled as it was.
The failure and the ability to recover from it arrive in the same moment.
It stops being your problem alone
Unpatched servers get found, and what happens next involves people who never agreed to be part of your maintenance schedule.
Someone else's infrastructureCompromised boxes get put to work. The attacker wants your site working — a working site is better cover.
Reputation outlives the serverDomain reputation warnings and abuse blocklists can remain after a server move; recovery requires addressing the incident and the affected listings.
The exposure is not only technicalAn unsupported OS is a documented security or compliance finding long before there is a breach.
And then the downtimeA planned migration has a window you chose. A compromise has one you did not.
The support ticket nobody wantsHours of research against minutes on a supported system, and whoever touches it owns what breaks next. Replies get thinner, then the answer is out of scope, and after that the host asks you to leave.
Unpatched system · known vulnerability · automated scan · compromise · abuse complaints · host action · emergency move
Every step follows from the one before it, and the only step you control is the first.
The mechanics of all of this →When the work needs a closer look
What licensing and closed source actually change
Some applications are harder to move for reasons that have nothing to do with the machine. A licence bound to specific hardware. A vendor-certified appliance where any change voids support. Software validated at a cost nobody will pay twice. Source code that is genuinely gone, from a company that closed in 2011.
These hinder migration. They do not always prevent it. What decides it is whether the constraint is technical or contractual.
A technical constraint is usually workable. A licence tied to hardware, a driver that exists for one kernel, a binary nobody has the source for — these are problems with the machine, and machines can be reproduced.
A contractual one is not, by engineering. If the support agreement voids on any change, no amount of technical work makes that untrue. The answer there is containment, or a conversation with the vendor, or accepting the finding — and that is a decision for the business rather than for us.
Either way, this is what the audit is for. None of it is in the code, none of it shows up in a package list, and it is the most common reason a migration plan turns out to be the wrong plan.
What increases workload and moves the price
Server size and how much data has to move. How far the OS has drifted — 7 against 6 against 5. Application complexity and hardcoded assumptions. Compatibility work the code genuinely calls for. Number of sites, services and cron dependencies. Whether the estate is one server or several.
The free review establishes the initial direction. The mandatory audit confirms which paths fit, the scope and price, and what can safely wait.
Most people assume leaving an EOL system means rewriting everything. Usually it means the opposite.
The same stack, on supported ground — minimum to no config or application changes
Most of what runs on these systems comes forward without rewriting. Newer PHP branches sit on a supported base directly; older ones come with you, in a container or from a maintained build. Same web server, same modules, same database engine, same configuration shape. What changes is the ground: security patches arrive, repositories exist, and installing software becomes routine again.
Modernising is a separate decision
Once you are on supported ground you can move the web stack forward, upgrade the database, and bring code current — deliberately, one at a time, with rollback available at every step. On an unsupported system every change is a risk event. On a supported base, changes are just changes.
Migrating is not always possible, and it is not always right
The business depends on this application. Our job is to keep it working and reduce the exposure within the constraints you have.
Some systems cannot move
Where the constraint is contractual rather than technical, and the contract is not going to change. A support agreement that voids on any modification. A validation nobody will pay for twice. These are not engineering problems, so engineering does not solve them.
Others could move and should not
An application that earns steadily and would cost more to rebuild than it returns. One internal tool that twelve people depend on. A business with a known horizon, where the server only has to outlast the plan. An owner who has been through a migration that went badly.
What containment means. You cannot patch what has no patches, so the work shifts to shrinking what can be reached: network isolation, a maintained proxy or firewall in front of the frozen stack, services cut back to what genuinely needs to run, monitoring for outbound spam and odd destinations, verified offsite backups tested by restoring them, and application-layer patches where the vendor still exists.
The image comes first. Month one, before anything else: a full capture of the machine as a portable image, taken while it still boots. Hardware failure stops being terminal, and a rebuild becomes possible on a schedule rather than in an emergency.
Containment reduces exposure, buys scheduling room, and makes a hardware failure survivable. It leaves the kernel unpatched and the audit finding standing. We can buy you time. Safety comes from moving — and where moving is genuinely off the table, containment is the honest second best. Reviewed once a year.
How far you have drifted decides the work
Usually contained
CentOS 7
The most common case. Expect PHP 5.4-era code, though many systems have a newer PHP layered on from a third-party repository. Frequently a same-stack move to supported ground, with script work only where the application calls for it.
Rebuild
CentOS 5 and 6
Ten to fifteen years of drift. Dead repositories, dependencies nobody can name, and code written against versions that predate most current documentation. Migration, upgrade and script work in one project — priced as separate components.
Cut short
CentOS 8
Discontinued in 2021 after two years. The shortest jump of the four and often the quickest, which is some consolation for having been moved twice.
Rehearsed
Ubuntu 16.04 and earlier
Several LTS releases behind. The jump crosses multiple major versions, so it is rehearsed on a clone rather than attempted in place.
What each path involves technically
Path 1 — technical work
Technically: we reproduce the package set from the running system rather than from a manifest, including anything installed from a third-party repository that no longer exists. Same PHP branch, same modules, same configuration shape. Where the supported base only carries a later point release of something you already run, you get that point release — a security-patch step within your existing version, not a version change.
Path 2 — technical work
Technically: containerisation with the application's own library versions intact, layer separation for database, mail and front-end services, egress firewalling so it reaches only what it must, and custom ingress rules around known vulnerabilities.
Path 3 — technical work
Technically: map the application's functions and data flows; develop or enhance the API; define request and response formats, authentication and operation-level authorization, input validation, error handling and logging. Reads and writes use the application's business rules, with transaction handling and tests that compare API results against existing behavior. The modern layer uses the API rather than taking unrestricted access to the legacy database.
Path 4 — technical work
Technically: deprecated and removed function inventory, static analysis, database structure changes, and language stack porting where required. Both versions run in parallel against the same input, so behaviour is compared rather than assumed.
Path 5 — technical work
Technically: requirements against what the application actually does now, database structure changes, and customisation that preserves existing workflow rather than replacing it.
In place, or on a clone?
An in-place upgrade moves the OS, not your application. Packages move forward. Your code does not. An application expecting PHP 5.4 lands on a distribution shipping PHP 8, and now you are debugging it on a server mid-transition rather than on a clean target you can rebuild at will.
Free tooling exists for this and it is built for adjacent releases — one major version to the next, on a system that is still close to supported. It moves packages and never looks at what runs on them. The question on this page is whether the application survives, so it is not part of the answer.
We may use migration tools for pre-upgrade checks and dependency assessment. The migration itself is built and rehearsed on a clone, where the application can be tested before production cutover.
| DIY / in-place upgrade | Our clone-and-cut migration | |
|---|---|---|
| Production system | Modified directly | Engineering changes tested on a clone; production access and cutover coordinated |
| Failure recovery | Restore from snapshot | Return traffic and reconcile new writes under the rollback plan |
| Problems surface | Mid-upgrade, on the live box | During cloning and testing |
| Application compatibility | Mixed into the OS upgrade | Tested separately on the target |
| Half-finished state | Neither old system nor new one | Target is disposable and rebuildable |
| Downtime | Open-ended risk | Planned cutover window |
Check the age of any guide you follow. Supported upgrade paths have changed recently, and at least one that was widely documented no longer exists. If your migration plan is more than a year old, verify it still works before you schedule anything. More in the vendor report →
Questions people ask before they move
What do I do now that CentOS 7 has reached end of life?
Choose a supported destination based on application compatibility, dependencies and support requirements. AlmaLinux, Rocky Linux and RHEL are candidates for RHEL-family workloads. In most cases your web stack can keep the same shape, so the application does not need rewriting; it needs a supported base underneath it.
Is it safe to keep running an unsupported OS?
Discontinued vendor patches, unavailable repositories and incompatible dependencies increase exposure and make recovery harder. Extended maintenance and containment can reduce specific risks, but their coverage and remaining limitations need to be assessed.
Can I upgrade CentOS 7 in place?
Tooling exists and it does work. We use its pre-upgrade check as reconnaissance because the report is genuinely useful, and we use a clone for the migration itself. Recovery from a failed in-place upgrade depends on a verified backup or snapshot and its restore procedure. Our approach retains the original server and plans how traffic and data return to it.
Do I have to rewrite my application to leave CentOS 7?
Usually the opposite. Newer PHP branches run on a supported base directly, and older ones come with you in a container or from a maintained build. The stack keeps its shape while the ground underneath becomes solid again. Older sources — CentOS 5 and 6 — carry enough drift that some code work is normally required.
Can I keep my existing PHP version?
In a same-stack rescue, yes — directly where the branch is recent enough, otherwise in a container or from a maintained build. Same web server, same modules, same database engine, same configuration shape, on ground that still receives patches. Moving PHP forward is a separate decision you make afterwards, with rollback available at every step.
What are my options if I am on Ubuntu 16.04?
The same predicament with a different family. 16.04 left standard support in 2021. The path forward is a supported LTS release, and because the jump crosses several major versions it is rehearsed on a clone rather than attempted in place.
Will there be downtime?
Most of the work happens while your production server stays online and serving traffic. The only interruption is the final sync and switch, performed in an agreed maintenance window in your quiet hours.
What happens if something doesn't work after cutover?
The original server remains available for a month after cutover. The agreed rollback plan covers returning traffic and reconciling any database writes, uploads or other state created on the new server. Switching traffic alone does not reconcile that data.
Do you do Windows?
Only in one direction. We move workloads off Windows onto Linux or BSD. We do not take on ongoing Windows server work — Linux and BSD is what we do.
How much does it cost?
The published figures are starting prices. Your scope and total price are agreed before work begins; the $100 audit is mandatory for every job and is fully credited toward the service you choose. A CentOS 7 same-stack rescue is priced like a server migration. A CentOS 5 or 6 rebuild is migration, upgrade and script work, priced as separate components so you can see what each part costs.
Start here
Find out what your server needs
Send us your OS version, application runtime version, and a basic description of the server. We will tell you whether this is likely to be a straightforward same-stack migration or a rebuild — and what each would involve.
You have probably been putting this off for a while. Most people have. Nobody here is going to make you feel bad about it.
For new clients: one free review covering one application on one server or hosting instance. Review terms →