Yii2 development services: maintenance, rescue and migration
Three things bring people to this page. A Yii2 application that has to stay safe to run. A Yii 1.1 codebase that current PHP will not take. And a framework that has started to block the business. If you are picking a framework for something new, this is not the page for it.
01Capabilities
How a Yii2 system usually reaches us
Yii2 arrives here as maintenance, refactoring and migration work on applications that already earn money, never as a greenfield framework choice. This is the legacy-rescue page in our PHP family: language-level modernization across a PHP estate sits on the PHP page, and anything genuinely new belongs on the Laravel page.
- Support
Keeping a live Yii2 system supported
Ongoing maintenance on an application customers use daily, including healthcare platforms like CancerDocs and leisure and rental platforms like WaiverKing. Dependency currency, security patching, incident response and the small feature work the business still needs. This is software maintenance and support rather than a project.
- Refactor
Refactoring a codebase that has drifted
Applications where the framework is fine and the code around it is not: logic in controllers, no test coverage, dependencies pinned to whatever worked in 2017, releases that take weeks because nobody trusts them. Structure and a deployment pipeline usually buy more than a framework change would.
- Upgrade
Yii 1.1 to Yii 2 migrations
Yii 1.1 stopped getting active development a long time ago, and an application still on it cannot take current PHP versions or current libraries. Moving to Yii 2 is not glamorous, it is not a rewrite either, and it buys you a supported floor to make the next decision from.
- Exit
Planned moves off the framework
Where Yii2 genuinely blocks the business we plan a staged move rather than a big-bang port: new capability built outside the monolith, boundaries cut inside it, and pieces retired as they are replaced. The application stays shippable the whole way through, which is how legacy software modernization is supposed to feel.
02Case studies
Three Yii2 systems, and what we did with each
Three published Yii2 engagements, across leisure, SaaS and healthcare.
See all case studies
LeisureSaaS modernization for Paddle Sports Center in CaliforniaA kayaking and paddleboard rental business in the Santa Barbara area wanted one system for equipment, customers, time and billing. That system is Adventure Rental System.15-20%Increase in revenue
SaaSWaiverKing: Software Development for Waiver Form CreatorWaiverKing is a document management business serving primarily the health and fitness industries. The platform is partnered with MindBody Online, one of the largest business-systems providers for gyms and yoga studios.Weeks to hoursTime for an update to reach live
HealthcareCancerDocs: HIPAA compliant Healthcare Software DevelopmentDevelopment in accordance with HIPAA Security Rules within a medical project.
03Fit
Stay, harden, or start moving off
We decide by what the system is doing now, not by the framework's reputation. Yii2 is declining and we will not pretend otherwise: maintenance rather than a roadmap, and a hiring pool that has moved on. It still runs real businesses well, which changes the advice in both directions. Two of the six rows below send you nowhere near us.
| Your situation | What we recommend |
|---|---|
| Starting something new, and Yii2 is on the shortlist because you already know it | Different pageOur Laravel page. A shrinking community is a cost you pay in hiring and dependency risk for as long as the system lives. |
| A working application, small steady change, and somebody already looking after it | Do nothingKeep PHP and the dependencies current, keep tests around the critical paths, and spend the budget on the product instead of the framework. |
| Still on Yii 1.1, and the PHP version underneath is stuck with it | Move to Yii 2A contained piece of work, not the first step of a rewrite. It gets you onto supported PHP and current libraries, which is what unblocks everything else. |
| The real problem is hosting, patching or what the server is exposing | Different workLeave the framework alone and fix the runtime and the exposure. That is DevOps consulting, and a migration does not make an unpatched server safe. |
| Nobody has deployed it in years and the original team is gone | Buy an auditA quality audit costs a fraction of the wrong decision. We would rather sell you that than a migration we cannot yet justify. |
| The application works, changes rarely, and somebody has proposed a port anyway | We argue againstA migration with nothing blocked behind it freezes product work for two or three quarters and hands you the same features you had. |
Scope
What we own on a Yii2 engagement is the recommendation and what follows from it. Whether the system stays where it is. What a move would cost you in frozen product work. And whether the thing can still be deployed and patched while we work on it. unicrew has been keeping systems like this running since 2012, with 100+ senior in-house engineers across six countries, under an ISO 27001:2022 certified information-security management system. Where the honest answer is less work than you came for, that is the answer you get.
Yii2 is not going to get a second life, so the only question worth asking is how long you need this system to keep earning. If the answer is a couple of years, hardening what you have is cheaper and less risky than a migration nobody has budgeted properly. If it is longer, start moving the domain logic out now, while the people who understand it are still available. The mistake is treating that as a technology decision when it is a timeline decision.
Oleksandr TrofimovChief Technology Officer, unicrew04Delivery
The order a handover has to run in
These applications arrive with thin documentation and an original team that has moved on, so the first two steps are not negotiable however urgent the feature request is. Nothing gets refactored before we can build, deploy and read the thing.
- Prove you can deploy itAll we need to start is read access to the repository and whatever deployment access still exists. Before anything else we get the application building and deploying from source into an environment we control. On a neglected codebase that step alone regularly surfaces undocumented server configuration, patches applied straight to production, and a dependency nobody can install any more.
- Map what runs and what nobody remembersThe data model, the cron jobs, the extensions, the payment and third-party integrations, and the parts of the schema no code touches. On a decade-old application the surprise is nearly always a scheduled job or a webhook that lives outside the repository.
- Get the floor current and the critical paths coveredSupported PHP, updatable dependencies, and characterisation tests around whatever the business cannot survive being wrong. This is where the security exposure actually gets closed, and it is the part that makes every later decision cheaper. Each step goes through the same QA and test automation practice we use on our own builds.
- Then decide: stay, refactor, or moveThe deliverable is a written recommendation with the reasoning behind it, because this is a decision you will have to defend internally: what state the system is in, what we would fix first, what we would leave alone, and what a move would cost in frozen product work. Often it is refactor and stay. It is very rarely a rewrite.
05Client voices
What two of these owners said
They’ve been helping us grow our platform together since the beginning, from a couple hundred companies to around 2,000. Artelogic has been front and center in this process.
We’ve seen a 15-20% increase in revenue, which is through the efficiency gains and the ability to accurately track time on a permanent basis rather than just by a quarter hour or an hour. I’ve worked with a lot of development teams over the years and these guys have been the best. It’s nice to finally find a team that we can work with.
06Stack
What tends to be running beside it
The four things we nearly always find in the same repository. Each has its own page, if the real question turns out to be there.
07Questions
What owners of ageing PHP systems ask first
Answered the way we would answer them on the call. If yours is not here, it makes a good first message.
No, and we would rather say that than win the build. It works, but you would be choosing a shrinking community, a smaller package ecosystem and a harder hiring position for the whole life of the system. For a new PHP system the answer is Laravel. The one exception is an organisation already running several Yii2 applications with the in-house knowledge to keep them.
You can, and on Yii2 the scarce thing really is people who know the framework. What you do not get is engineers handed over with the outcome unowned. An architect outside the delivery team reviews the design, and the work goes through the same QA and test automation practice as our own products. Team extension is managed teams; handing over the result is software maintenance and support.
Yes, with a condition that matters more than the framework. Yii 2 still gets maintenance releases, and its built-in protections against SQL injection, cross-site scripting and request forgery are sound when you use them. Your real exposure is nearly always the PHP version underneath, the extensions nobody has updated, and the server configuration. That is what we look at first, and what a quality audit is measuring.
Only when the framework is genuinely blocking something, and unfashionable is not blocking. We say yes when you cannot keep anyone who will work on it, when an extension you depend on is dead with no replacement, or when the roadmap ahead is big enough that the migration pays for itself. We say no when the application works and changes rarely. Where the answer is yes, we stage it, and the sequence is on our PHP page.
Repository and deployment access, if it still exists, and that is genuinely all. Half the useful information about an older system is in how it is deployed rather than how it is written. The call itself is with an engineer, and what comes back is a written recommendation you can circulate internally. It is as likely to say leave it alone as to propose work. Most engagements start within two to four weeks.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work that is still moving. Fixed price is outcome based, and we only offer it once the first read is done, because a fixed number on a system nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer.
Deciding how much longer to run it?
Send us the repository and tell us what worries you. You get an engineer's read on whether to stay, refactor or plan a move, and what each one would cost you.