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.
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.
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.
Documents the assessment produces
You can take these to any supplier. They are 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
- A proposed order of slices with reasons
- Data quality findings
- A cost range for the first three slices
- Risks we could not assess and why
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.