PHP software engineers who change a live legacy application
We add senior PHP software engineers who change the application in pieces small enough for your own team to review. The application keeps serving customers the whole time.
Talk to a PHP software engineer
Tell us what the application does. A reply within one business day, with a technical person on the call.
A version number cannot tell you whether you are exposed
A branch is the numbered version line your application runs on. There is a check you can run tonight to find yours. It takes a minute, costs nothing, and will not settle the question.
Show data table
| Segment | Value (percent) | Share |
|---|---|---|
| No security fixes | 51.3 | 51.3% |
| Security fixes only | 39.6 | 39.6% |
| Actively supported | 9.1 | 9.1% |
Some Linux distributions backport security fixes into a branch php.net has retired. The version string on its own cannot tell you which case you are in.
Your application was built years ago, most likely by people who have since left, and revenue runs through it every day. The senior PHP software engineers we add begin by learning what the code actually does.
Find out which branch your application reports. Then read the published end-of-life dates for that branch on php.net. Both halves are public, and neither of them involves us. More often than not, you will land in the first block above.
Then comes the part nobody says out loud. The Debian project answers it directly in its own security notes. Rather than raising version numbers, Debian backports security fixes into the version shipped in the stable release. The stated reason is that a release should change as little as possible. Several distributions work that way. Many hosts do not.
So a site reporting an old branch may be quietly patched, or may be sitting wide open. The number it prints is identical in both cases. Not knowing which one you are is not a gap in your diligence. It is the position. It is answerable. You answer it by looking at what the host actually ships, not at what the application reports about itself.
Whether you should still be on PHP at all
This is the question underneath the other one, and it usually arrives with a different person in the room.
A great deal of PHP was written badly, much of it before the language had the tools to write it well. Some of that code is exactly what people picture when they hear the word. That is a fair observation and there is no point arguing with it.
W3Techs measured this on 1 September 2026: of all websites whose server-side programming language it could identify, 70.2 percent run PHP. That figure buys one thing only, which is that an ecosystem this size is not going anywhere. It says nothing about the quality of any single application, including yours.
Nobody is buying a language. The alternative to a working application is not a better one written in something else. It is rebuilding whatever behaviour exists only in the running code, a good deal of which lives only in the heads of people who have already left. That is the branch hardest to cost before it starts.
One question settles it. How much of what this application does lives only in the running code? Where the answer is very little, a rebuild is a real and reasonable choice. Where the answer is years of it, a rebuild is a rediscovery project wearing a rewrite's clothes.
Why this sits where it does
If revenue runs through an application you did not build
Nobody can give you a straight answer about what moving it would cost, or what it would break. Every quote carries a range wide enough to be useless. Meanwhile it works. Not brilliantly, but it works, and something in front of it is always on fire. And if it fails on a Friday evening, you carry that personally.
If you own this codebase and cannot get headcount for it
You know what needs doing and roughly in what order, but you do not have the people. On a spreadsheet this work reads as maintenance, so a permanent hire is hard to argue for. Everything else depends on it anyway. So it goes on the list, and every month the change gets one month larger.
The risk is in the size of the change, not in the version number
Two counts from the same application, the same upgrade and the same practitioner, done two different ways.
Show data table
| Item | Files changed |
|---|---|
| Changed in a single leap to PHP 8 | 1,000 files |
| Changed in the PHP 8 step, done in stages | 25 files |
Cooke wrote that the single leap ended up at over 1000 files changed. In his words, it was too many to cope with.
Both counts come from Lawrence Cooke, writing on dev.to in April 2024. Same application, same end state. The difference is entirely in how the work was cut. That is the difference between a change your team can actually read and one they simply give up on. A review nobody can perform has stopped being a control. That is where the expensive mistakes go through.
Which gives you a question worth putting to every firm bidding for this. Put it to us as well. How many files will my team be asked to review at one time? A firm that has thought about the risk will answer with a number. An answer about process instead of a number is the one to worry about. It means the size of the diff was never something anybody planned.
How a change actually gets made
01
Find out where you stand
Which branch the application runs. Whether the host backports security fixes into it. Which extensions and third-party packages are load-bearing, and what a move would touch.
What lands on your side
A written statement of where the application actually stands
02
Agree the scope
Scope is agreed in writing before work starts. It names the milestones, and what each one has to satisfy to be finished. You sign it off before anybody opens an editor.
What lands on your side
A signed scope with milestone exit criteria
03
Change it in pieces
Work lands in your repositories and deploys to your cloud accounts. A senior software engineer reviews every change. Each one carries tests and passes a gate before it merges.
What lands on your side
Reviewed pull requests in your own repositories
04
Anything that changes the scope
Work that turns out bigger than the scope is written down and put to you first. Nothing in the build moves on a re-scope you have not explicitly accepted. The estimate you signed off does not quietly drift.
What lands on your side
A written change note you approve before anything moves
When the skill is not on the market
We have worked with more than 50 companies across 7 countries. We have been operating since 2015. Our longest active partnership has run more than a decade.
Start with the need. A global industrial-automation client could not source Magento expertise at the speed its work required. Magento is PHP, so this is the same labour market your application draws on. The shortage was not of software engineers. It was of software engineers who had carried this kind of application before.
Then the shortlist. We define the need first: skills, overlap hours, and the outcomes the work has to produce. Then a shortlist, already vetted by our own technical team. You interview them if you want to, and none of them if you would rather not. If a shortlist does not produce the right fit, we send another.
The team came next. Seven specialists, formed for that engagement, working to the roadmap the client set. Formed on demand is the point. Nobody was on a bench waiting, and nobody was pulled off other work and rebadged. We would run the same sequence for a PHP gap you cannot hire into.
What you are buying, and what makes it bigger
Three different arrangements, not three tiers of one, read against the same four axes.
| Against | Find out where you actually standA scoped piece of work with a written output | Ongoing maintenanceAn annual maintenance arrangement, or lean mode for lighter ongoing support | A team formed for a gap you cannot hire intoPHP software engineers working alongside yours |
|---|---|---|---|
| What it produces | Find out where you actually standA written statement of which branch you run, whether the host backports patches into it, which extensions and packages are load-bearing, and what a move would touch. | Ongoing maintenanceChanges made and reviewed as they come up, each through the same written change note as a build. | A team formed for a gap you cannot hire intoNamed software engineers on your roadmap, in your repositories, reviewed like everything else. |
| Who holds the roadmap | Find out where you actually standYou do. The output is information, and what you do with it is yours to decide. | Ongoing maintenanceYou do. We work the queue you set. | A team formed for a gap you cannot hire intoYou do. They work to your priorities, not to a plan of ours. |
| What moves the size | Find out where you actually standHow many ways into the application there are, whether automated tests exist, how many third-party extensions are load-bearing, whether we can touch the hosting, and whether an outside date fixes the calendar. | Ongoing maintenanceHow much is still changing. How many integrations sit around it. How much of the application has tests. | A team formed for a gap you cannot hire intoHow scarce the skill is, and how much has to be learned before anybody is useful. |
| How long it runs | Find out where you actually standUntil the written statement is delivered. | Ongoing maintenanceThe annual maintenance arrangement is annual. Lean mode is for lighter ongoing support. | A team formed for a gap you cannot hire intoFor as long as the gap exists. Our longest active partnership has run more than a decade. |
Who answers when it breaks, and exactly where that stops
This is the commitment the rest of the arrangement rests on. Here it is with its limits attached, rather than discovered later. It is a term of the ongoing support arrangement, whether that is the annual maintenance arrangement or lean mode. It is not a blanket property of every engagement we run.
- An outage, or anything that stops your team working: a named person acknowledges it within four working hours.
- Something broken that can be worked around: twenty-four working hours.
- Everything else: seventy-two working hours.
- Working hours means our working day, Monday to Friday, 10:00 to 19:00 India Standard Time. That is 04:30 to 13:30 UTC.
- European teams get substantial afternoon overlap with that day.
- The target is acknowledgement by a named person who engages with the issue. It is not resolution.
- How long a fix takes depends on what the issue turns out to be. That is not something we commit to.
Two of those lines make the commitment smaller. They are there on purpose. A target that promises a fix rather than an answer is a target nobody can hold. The size of a fix is not knowable before somebody has looked at the problem. What is knowable is that a person who understands the application has picked it up. And that they told you so, inside a window you were given in writing. That is worth asking for in writing from anyone else you are talking to.
Start the conversation
Tell us what the application does. You will get a reply within one business day, with a technical person on the call.
Who should not hire us
The right call when
Revenue runs through a PHP application somebody else built, and nobody can tell you where it stands.
You want the branch moved, the extensions untangled or the hosting sorted, in pieces your team can review.
You need PHP software engineers alongside yours for a gap you cannot hire into fast enough.
The wrong call when
Very little of what your application does lives only in the running code. Where that is true, the case for rebuilding is genuinely strong, and this is not the work for it.
You need round-the-clock cover. Our default is India Standard Time working hours. Where a live sync is needed, a project coordinator can host it. An overlap shift can also be arranged on request, agreed at scoping. What we do not offer is continuous cover.
Your engagement requires a certified vendor. We do not hold SOC 2, GDPR or HIPAA certifications ourselves. We engineer systems that pass your audits. Where the certification itself is the requirement, we say so upfront and point you on.
For the conversation you have without us
Every line below stands on its own. Each one can be pasted into a message with nothing else attached to explain it.
Forwardable
PHP work with Atyantik, in five lines
- Ownership Intellectual property belongs to the client from day one.
- Where the code lives If the client has repositories and cloud accounts, Atyantik works inside them. If not, Atyantik provisions them and hands over the keys.
- Review A senior software engineer reviews every change. Each one carries tests and passes a gate before it merges.
- Response On an ongoing support arrangement, a named person acknowledges an outage within four working hours. The working day is 10:00 to 19:00 India Standard Time, or 04:30 to 13:30 UTC.
- If it ends On offboarding, the client keeps everything, including the operational runbook.
Before the first call
The questions that come up about a live PHP application, answered before anyone picks up the phone.
How do we find out whether the PHP version we run is actually exposed?
Should we rebuild in something else instead of staying on PHP?
How is each change reviewed before it reaches our live application?
Who owns the code, and where does it live?
What happens when the work turns out bigger than the scope we agreed?
Can we interview the PHP software engineers you propose?
What if the PHP software engineer we work with leaves?
Tell us what the application does
One conversation to start, and a reply within one business day with a technical person on the call.
Describe what the application does, what worries you about it, and what you already know about where it runs.
You will get a reply within one business day, with a technical person on the call.
There are two good outcomes here and we mean both. Either this is work we take, or we tell you it is not ours and where we would look instead.
- A reply within one business day.
- A technical person on the call.
- Nothing you share goes anywhere else.