Modernise your existing software without starting from scratch
The system holding your business together is old, slow and difficult to change. It is also working, paid for, and full of business rules nobody has written down anywhere else. A rewrite is not the only option, and it is rarely the best one.
Does this sound familiar?
You are probably here because of one of these
Every change takes longer than it should, and nobody can confidently say what else it might break.
The application has become slow as your data has grown, and it is getting worse.
The developer who built it has left, and what remains is difficult for anyone else to work on.
You have been quoted for a full rewrite and the number, and the timeline, are alarming.
You are running an old PHP or Laravel version and are starting to worry about security and support.
Deployments are manual, nerve-racking, and done outside business hours.
What this covers
The work itself
Not a capability list — these are the specific things an engagement in this area actually involves.
Technical assessment
An honest read of what you have: architecture, code quality, security exposure, performance characteristics and the real risks. Delivered as findings you can make a decision from, including the option of doing nothing if that is genuinely the right answer.
Incremental migration
Moving a system to a modern architecture module by module, behind stable interfaces, while it stays in production. This is how a decade-old PHP platform was migrated to Slim without a big-bang cutover.
Performance recovery
Finding and fixing the queries, schema decisions and architectural choices that have made the system slow. Often the fastest path to a system that feels new, at a fraction of the cost of building one.
Framework and version upgrades
Bringing PHP and Laravel versions up to date, including the dependency and breaking-change work that makes teams put it off until it becomes urgent.
Architecture and refactoring
Introducing genuine boundaries into code that has grown without them, so the parts you change most often stop being the parts you dread.
Database modernisation
Schema redesign, migration and multi-tenant restructuring, done in stages against a live system with data intact.
Typically involves
- PHP
- Laravel
- Slim
- PostgreSQL
- MySQL
- Docker
- AWS
- CI/CD
How the work runs
The approach
Consistent across engagements, because the order these things happen in is usually what determines whether a project goes well.
- 01
Assess honestly
Understand what is actually there and what is actually wrong. Sometimes the answer is that the system is fine and one specific thing is broken. That is a good outcome and worth finding out cheaply.
- 02
Separate the urgent from the structural
Performance problems and maintainability problems have different causes and different fixes. Treating them separately means you can get faster this month without waiting for an architectural programme to finish.
- 03
Migrate incrementally, in production
Move one module at a time behind stable interfaces, preserving backward compatibility, with the product live throughout. Value arrives continuously instead of at the end, and the risk at any moment stays small.
- 04
Leave it maintainable
Clear boundaries, coding standards and review, so the modernised parts do not become the next legacy system in five years.
Evidence
Where this has been done
Real projects involving this work, with the reasoning and the results.
Questions
What people usually ask
- Should we rewrite or modernise?
- Modernise, in most cases. A working system contains years of accumulated business rules that exist nowhere else, and a rewrite means rediscovering all of them while shipping nothing. Rewrites are occasionally right — but the case has to be made, not assumed. That assessment is the first thing worth paying for.
- Can this happen while the system stays live?
- Yes, and it should. A ten-year-old platform serving paying customers was migrated module by module while remaining in production, with backward compatibility maintained throughout. Incremental work is lower risk than a cutover, not higher.
- How much improvement is realistic?
- It depends entirely on what is wrong, which is why the assessment comes first. As one real data point: query and architecture optimisation on a legacy platform produced up to 80% improvement on many API endpoints. Any number offered before looking at your system would be a guess.
- What if our documentation is non-existent?
- That is the normal case, not the exception. Understanding an undocumented system that someone else wrote is a core part of this work.
Have a software problem, project or idea?
Tell me what you are trying to achieve and where it is currently going wrong. You will get an honest read on it from someone who has built this kind of thing before — including if the answer is that you do not need what you were about to buy.
Prefer not to call? Send me a message
Working with businesses across Australia — Melbourne, Sydney, Brisbane, Adelaide, Perth, Canberra and regional Australia.