Sound familiar?
- The system runs the business but only one person understands it
- It is stuck on an old PHP version because upgrading breaks it
- The host or IT provider keeps warning about unsupported software
- Simple changes take weeks because nobody dares touch the code
- It does not work on phones, tablets or modern browsers
- It cannot connect to the newer systems you now use, so staff rekey data
Key facts
- We modernise in stages rather than betting everything on one big rewrite
- The strangler fig pattern lets new code replace old screens one at a time
- Characterisation tests record what the old system really does before we change it
- Data is migrated with reconciliation reports, not copied and hoped for
- PHP 7.4 reached end of life on 28 November 2022 and PHP 8.1 on 31 December 2025, according to php.net
- You own the modernised code, documentation and data
- Trading since 2006, so we have worked on plenty of systems that are now legacy
What counts as legacy software
Legacy software is anything the business relies on that has become hard or risky to change. Age is not the test. A ten-year-old Laravel application with tests can be in better shape than a three-year-old one built in a hurry. The common signs are:
- It runs on an unsupported language version, framework or operating system
- Nobody left in the business fully understands it
- There are no automated tests, so every change risks breaking something elsewhere
- It cannot talk to newer systems without manual exports and imports
- Security fixes are no longer available for parts of it
Typical examples we see: PHP 5 or PHP 7 applications, custom shop platforms, Microsoft Access databases shared on a network drive, Excel workbooks full of macros, Classic ASP sites and old desktop apps, including Adobe AIR, which was common for business desktop tools in the early 2010s. We built AIR apps ourselves back then, so we know how they hang together.
Upgrade, refactor, replace or retire
There are four honest options, and the right one often differs by part of the system:
| Option | When it fits |
|---|---|
| Upgrade | The design is sound but the platform is old. Move to a supported PHP version, framework and server. See PHP upgrades. |
| Refactor | The system works but the code is tangled. Add tests, then restructure piece by piece. |
| Replace | The way the business works has moved on. Build new modules, or move a function to off-the-shelf software where that is better. |
| Retire | Nobody uses it. Archive the data and switch it off. |
We set out the options with risks and trade-offs in plain English so you can choose. We do not default to a rebuild because it is the bigger job.
Why we avoid the big-bang rewrite
Rewriting a working system from scratch is tempting and often goes badly. The old system holds years of business rules that nobody wrote down: the customer who always gets a special discount, the VAT edge case, the report finance runs at year end. A full rewrite has to rediscover all of them, while the business waits and the old system keeps changing.
We prefer the strangler fig approach. New code sits alongside the old system, often behind the same login or a routing layer. One screen, report or process at a time moves to the new code, and the old version is switched off once the new one is proven. At every stage you have a working system, and if priorities change you can pause without being left with half of something.
Capturing what the old system really does
Before changing anything, we write characterisation tests: automated tests that record what the system currently does, even where that looks odd. Feed in a known order, check the invoice it produces. Run the month-end report on a copy of last month's data, compare the totals. These tests catch accidental changes in behaviour during the upgrade, and they become the safety net for every future change.
We also read the database as carefully as the code. In older systems the database often holds the real rules, in triggers, stored procedures and columns that have quietly changed meaning over the years.
Moving the data safely
Data migration is where modernisation projects most often go wrong. We write repeatable migration scripts, not one-off manual copies, and run them many times against copies of live data before the real switch. Each run produces a reconciliation report: record counts, totals and spot checks that both sides agree. Cut-over is planned with a rollback route, and old data is archived in a readable form, not just left on a server nobody can log in to. See data migration for more.
How a project starts
Modernisation is also a chance to fix the things that annoyed people about the old system. While we are in the code we add what most legacy systems lack: role-based access instead of shared logins, an audit log of who changed what, screens that work on a phone or tablet, and proper API integrations so data no longer has to be exported to a spreadsheet and imported somewhere else. We agree these with you per phase rather than piling them into one huge scope.
It starts with a free chat, then a code audit or discovery stage where we look at the code, database, hosting and the people who use it. You get a written assessment and a staged roadmap, and then a fixed-price quote for the first phase. Each later phase is quoted the same way, so you are never committed to more than you can see. Get in touch to talk it through.
What we deliver
- A modernisation assessment with options: upgrade, refactor, replace or retire
- A staged roadmap with each phase delivering something usable
- Automated tests that capture current behaviour before changes
- Upgraded runtime, framework and dependencies on supported versions
- New modules or screens built alongside the old system and switched over gradually
- Data migration scripts with reconciliation and rollback
- Documentation of the system as it now stands
How it works and what it costs
Every project gets a fixed-price quote after a free initial chat and a short scoping stage. You own the code and the data.
Free chat
Tell us the problem in plain English: what you do now, what goes wrong and what "better" looks like. No charge, no obligation.
Scoping
We map the processes, systems and data involved, agree what is in and out, and write it down so there are no surprises.
Fixed-price quote
You get a fixed price for the agreed scope, or a phased plan for bigger builds, so you can start small and prove it works.
Build and test
We build in short stages you can see and try, test against real data, then go live carefully with a rollback plan.
Hand over and look after
You own the code and the data. We can host it, support it and keep improving it, or hand it to your own team.
Frequently asked questions
Should we rewrite our old system from scratch?
Usually not all at once. A full rewrite has to rediscover years of undocumented business rules while the business waits. dijitul developments prefers staged modernisation: upgrade what is sound, refactor what is tangled, and replace parts one at a time so you always have a working system.
Can you modernise software you did not build?
Yes, that is most of our modernisation work. dijitul developments starts with a code audit to understand the code, database and hosting, writes tests that capture current behaviour, then plans the changes. Missing documentation is normal; we create it as we go.
Will we have downtime during modernisation?
We plan to keep it to a minimum. New modules run alongside the old system and switch over one at a time, and data migrations are rehearsed on copies of live data. Where a short outage is unavoidable, such as a final data cut-over, we schedule it for a quiet time agreed with you.
Can you replace a Microsoft Access database or Excel system?
Yes. We move the data into a proper database such as MySQL, MariaDB or PostgreSQL and build a web application around it with logins, permissions and audit logs. The existing forms and reports guide the design, so staff recognise their workflow, and the data is migrated with reconciliation checks.
How long does legacy modernisation take?
It depends on the size of the system and the approach chosen, so dijitul developments sets out a staged roadmap after an audit or discovery. Each phase delivers something usable and has its own fixed-price quote, so you can see and control progress.
How is modernisation priced?
Every phase is a fixed-price quote for a defined scope, agreed after a free chat and an initial assessment. You can stop after any phase with working software and documentation, and you own the code and data throughout.
Related
Tell us what you need to build
Free chat, clear scope, fixed-price quote. You own everything we build.