Most legacy systems are not broken. They are just quietly falling behind.
The order platform still takes orders. The CRM still holds the customers. Nothing has fallen over, so nobody has touched it in years, and that is exactly the problem. The PHP version went out of support two releases ago, a dependency has an open advisory against it, and the whole thing runs on one server nobody wants to reboot.
The reflex, when a system feels old, is to replace it. Start clean, do it properly this time. In practice a full rewrite is the most expensive and riskiest option on the table: you rebuild everything the old system already did correctly just to get back to where you started, and you carry the business on the old code until the day you dare to switch. There is almost always a cheaper path that does not involve stopping.
When it is holding the business back
In business operations software the symptoms are operational, not cosmetic. A report that takes a fortnight. A process only one person understands. An integration that breaks every time a supplier changes their API. The software is not failing, but it is slowing everyone around it down.
When it is quietly a liability
An unpatched framework, an out-of-support runtime, credentials sitting in a config file, backups nobody has tested. None of it shows on a good day. All of it shows on the day someone finds the gap. Modernisation deals with that before it becomes an incident.
01Assessment and honest options
We audit the codebase, the hosting and the dependencies, and check how ready each part is to move. You get the three routes laid out against your own system: upgrade it where it stands, replatform it onto AWS, or rebuild the parts that warrant it - with a plan tied to your budget and timeline, not a preference of ours.
02Upgrading in place
Often the first and cheapest win is to bring the application onto a supported runtime and swap unmaintained libraries for actively maintained ones, closing the known advisories in the process. We are Yii specialists, and moving a Yii 1 application to Yii 2 is well-trodden ground for us - we have written up the challenges and opportunities of that jump. We also take on PHP in Laravel, Symfony, CodeIgniter and CakePHP, as well as bespoke applications with no framework at all.
03Moving to AWS
Replatforming onto Elastic Beanstalk or containers gives you an environment that scales with demand and patches itself, with S3 taking the media and files off the application server. We move in stages and run the old and new side by side, so there is no big-bang cutover and no weekend everyone dreads.
04Refactoring the parts that pay off
Not everything needs rewriting, but some things earn it. A document generator or a heavy export is often the bottleneck in a monolith. Broken out into its own serverless function, it scales on its own and stops dragging the rest of the application down with it. We measure first and change only what the numbers justify.
05Data and cutover
The riskiest part of any migration is the data. We plan the move, keep the old system authoritative until the new one has proven itself, and switch over only when it has. Where a legacy process lives in spreadsheets and macros rather than an application, we reverse-engineer it faithfully rather than guessing at what it was meant to do.
Platforms we brought forward without starting again.
The stack is usually PHP in Yii, Laravel or Symfony, moved onto Elastic Beanstalk or containers where the application wants to stay much as it is, with Lambda and API Gateway for the parts worth making serverless and CloudFront and RDS around them. We are an AWS Select Tier Services Partner and we run a Well-Architected review on every engagement, so the trade-offs between cost, resilience and effort are on the table before we start rather than discovered in month four.
Si Novi have been amazing. We were blown away by their responsiveness and the quality of their work. The journey is just beginning and we couldn't have found a better partner to help us on our way.
We modernise what earns its keep and replace only what has to go.
- 01
Assess
We read what you have and tell you the truth about it: which parts are solid, which are risky, and which are quietly costing you. You get an honest map before anyone commits to a plan - what can move as it stands, what needs upgrading first, and what is genuinely better off rebuilt.
- 02
Modernise
The safe order is usually to bring the application onto a supported runtime and current dependencies where it stands, then move it onto AWS, then refactor the parts that pay for it - pulling a slow report or a document generator out into its own service. Small steps, each one shippable, so you are never carrying a six-month rewrite you cannot release.
- 03
Run
We stay. Someone has to keep the runtime patched, the dependencies current and the infrastructure watched once the migration is done. In most of our engagements that is still us, years after the work that started it.
The things buyers ask us first.
Do we have to rebuild everything?
Almost never. Most of what you have works, which is why it is still running your business. We keep that and modernise around it, and a full rewrite is the last resort rather than the default. It is usually the slowest and most expensive way to end up roughly where you started.
Can you work with our old codebase, even if it's a mess?
Yes. Taking on unfamiliar legacy code is a large part of what we do. We audit it, learn its conventions and set up a reliable way to work on it safely before we change anything. Spacesuit Media is a good example: a platform someone else built, over years, that we now develop as if it were our own.
Will the business have to stop while you do it?
No. We move in small, releasable steps and run the old and new systems side by side through any cutover. There is no frozen period where nothing ships and no risky weekend switch that has to go perfectly first time.
Will we be locked in?
No. It all runs in your own AWS account and you hold a copy of everything, including the infrastructure definitions and the deployment pipeline. You can take it elsewhere whenever you want, and an engagement that only survives because leaving is painful is not one we want.