Software Modernisation
Old software is usually old because it works. It carries rules that nobody wrote down: the rounding on a tax line, the customer who is always invoiced in a different currency. A rewrite from a blank page throws those rules away and rediscovers them, one angry phone call at a time.
We modernise in slices. The old system stays in service while new parts take over one function after another. Staff see small changes. The business never has a weekend where everything must work at once.
How to tell a system is due
Age alone is not a reason. These are.
The runtime is out of support
PHP 5 or 7, Python 2, .NET Framework on an old Windows Server, AngularJS. Security fixes have stopped and hosting providers are dropping them.
Releases are rare and frightening
Deployment is a manual checklist carried out late at night. Each change breaks something unrelated.
Logic lives in the database
Hundreds of stored procedures and triggers hold the business rules, with no tests and no version history.
Nobody can be hired for it
The language or framework has fallen out of use and the one person who knows it is planning to retire.
It cannot talk to anything
No API. Other systems read its tables directly or exchange files by FTP on a timer.
It runs on one machine
A single server in a cupboard, or a desktop database shared over the office network.
What the assessment hands you
The assessment is the first purchase, priced by the hour at the published rates. You can take its output to any supplier. It is useful even if you decide to leave the system alone for another year.
- An inventory of modules, scheduled jobs and integrations
- A map of which tables each module reads and writes
- Known security exposures, ranked
- Dependencies that are out of support
- The options: keep and patch, upgrade in place, or replace in slices, with a recommendation
- A proposed order of slices with reasons
- Data quality findings
- A cost range for the first slice, with the assumptions written down
- Risks we could not assess and why
Illustrative example — not client work
An assessment decision example
This fictional job-management application shows job status and creates invoices from a shared database. It has no documented API. The sample demonstrates a proposed first slice and the evidence needed before redirecting users.
Assumptions to investigate
- Candidate slice
- A read-only job-status screen.
- Dependencies to trace
- Sign-in, customer access rules and status updates from scheduled jobs.
- Unknowns
- Undocumented status meanings, query load and direct database writes.
Decision: separate a read path first
Propose a new status screen while the existing application continues to create jobs and invoices. Hold the switch until access rules, data freshness and a route back are demonstrated. Leave billing untouched in this slice.
Read the switch decision and rollback excerpt
Evidence before a switch
- Compare agreed sample jobs, including cancelled and partially completed work, against the old screen.
- Check that each user sees only the customers they are allowed to access.
- Measure the new reads against an agreed load and freshness limit.
- Rehearse restoring the old route and name who can authorise the switch.
The limit of this rollback
Routing back can restore the old screen because the proposed slice writes no business data. That assumption must be checked. A later slice that changes jobs or sends invoices needs its own reconciliation and recovery plan; this example does not establish one.
Replacing a system while it runs
The name comes from a fig that grows around a tree until it stands on its own. In software it works like this.
Put a routing layer in front
A reverse proxy or gateway receives every request. At first it passes all of them to the old application unchanged.
Pin down current behaviour
Before touching a function we record what it does today with characterisation tests: given this input, the old code returns that output, oddities included.
Pick a thin first slice
Something with clear edges and low risk, such as a report or a read-only screen. It proves the route, the deployment and the sign-in hand-off.
Build the slice and redirect
The new code goes live behind the router for that one path. If it misbehaves, the route is pointed back within minutes.
Keep the data in step
While both sides are alive they must agree. We choose per slice between a shared database, change-data capture, or writing to both.
Repeat, then retire
Slice by slice the old application handles less. When its traffic reaches zero it is archived and the server is switched off.
Watch a system being replaced while it runs
Scroll: six functions move from the old application to the new one, one at a time, behind the same gateway. Users never change address.
Old system retired. Every function now runs in the new one.
- A gateway goes in front. At first every request still reaches the old application.
- Reports move first: read-only, low risk, proves the route and the sign-in hand-off.
- Sign-in moves. Both sides now trust the same session.
- Orders move, with tests that pin down the old behaviour, oddities included.
- Invoices and stock move; the two databases are kept in step until the last slice.
- Customers move. The old application takes no traffic, is archived read-only and switched off.
Moving the data
Code can be redeployed. Data that was converted badly is much harder to repair, so this part gets its own plan.
Profile
Row counts, empty fields, duplicates, dates stored as text, character encoding. We report what is there before designing anything.
Map
A field-by-field document: source, target, transformation and the rule for records that do not fit.
Rehearse
Full runs against a copy of production, at least twice, timed from start to finish.
Reconcile
Totals, counts and sampled records compared between old and new. Your staff check the accounts they know best.
Cut over
A planned window, a written checklist and a named decision point at which we either proceed or roll back.
Keep the archive
The old database is kept read-only for the period your accountant or regulator requires.
What can be undone, and what cannot
A way back exists at every step, but it is not the same at every step. We write down the limits for your system before the first switch, not after.
A slice that misbehaves
The route is pointed back at the old code within minutes. Nothing else changes.
A release that fails
The previous build is redeployed. Releases are kept so this is one command.
Data written after a switch
Records the new slice created or changed must be carried back into the old system. We plan that path per slice, and for some it means a longer rehearsal rather than a quicker switch.
Messages already sent
Emails, invoices and notifications to customers or partner systems cannot be recalled. Slices that send them get an extra rehearsal and a staged start.
Integrations already repointed
A partner that has moved to your new API works to its own change calendar. Repointing it back takes their notice period, not ours.
The final cut-over
Has a written decision point, and the old database stays read-only afterwards, so the question is never whether a way back exists, only how long it takes.
What modernisation work costs
Our rates are published. Pick the role and move the sliders for an indicative budget.
Rate card
| Role | Hourly | Monthly* |
|---|---|---|
| Frontend / WordPress | $30 | $4,800 |
| Backend / API | $32 | $5,120 |
| Full-stack | $35 | $5,600 |
| Mobile (React Native / Flutter) | $35 | $5,600 |
| DevOps / Cloud | $40 | $6,400 |
| AI / Automation engineer | $45 | $7,200 |
| QA / Test engineer | $25 | $4,000 |
| UI / UX design | $28 | $4,480 |
*160 hrs/month full-time. Rates are indicative for planning, in USD (other currencies are converted at an indicative rate), and depend on seniority, contract length and timezone overlap. Longer engagements and multi-role teams are discounted — ask.
Modernise, rewrite or leave alone?
Incremental modernisation suits
- Systems the business depends on every working day.
- Code that has gathered undocumented rules over a long life.
- Organisations that cannot stop trading for a migration weekend.
- Budgets released in stages rather than as one sum.
Another route is better when
- The application is small enough to rebuild in a few weeks.
- A commercial product now does the same job. Migrate to it instead.
- The system is stable, isolated from the internet and due for retirement anyway.
- The source code is lost. That is reverse engineering, a different and costlier job.
Common concerns
How long will the whole thing take?
We will not give a date for the whole programme before the assessment, and after it we give ranges per slice. The point of the method is that value arrives with each slice, not only at the end.
Will users need retraining?
A little at a time. Screens change one area at a time, and we write short notes for each release.
Can you work without documentation?
Yes, that is the usual situation. We read the code, query the database and interview the people who use it.
What does it cost?
Work is charged at the published hourly rates for the roles involved. The assessment gives a cost range for the first slices so you can decide with numbers in front of you.
Will there be downtime?
Individual slices are switched at the router, normally without interruption. The final data cut-over may need a short planned window, agreed with you in advance.
Describe what the system does and what it runs on
Language, database, rough age and what worries you most. If you do not know the technical details, say so and we will find out together. You will hear from us within one business day.