Technology · Modernization
Modernisation of existing systems.
An existing system usually holds years of business knowledge. Modernising it is cheaper and less risky than replacing it.
You don't always have to start over.
When clients usually bring us in
- the existing system no longer keeps up
- the work happens in spreadsheets
- data is duplicated across systems
- you need a new application
- you want to modernise an old system
- you're building a new digital product
You don't always have to build from scratch
If the existing system can be properly modernised or connected to others, that's usually faster and cheaper than a new application. We start by looking at what's worth keeping.
What this means for you
- Fewer spreadsheets and manual status updates.
- Less duplicated data across systems.
- One view of the process for management and the team.
- A system that grows with the company.
- Less dependence on the one person who knows how it works.
Problem → solution
Why an old system is not necessarily a bad system
A system that has run for ten years contains rules recorded nowhere else: exceptions, workarounds and agreements that came from real cases. Replace it wholesale and those rules are lost, then rediscovered one at a time, usually in production.
So we first look at what in the system is worth keeping, and only then at what has to be replaced.
- business rules embedded in the code
- data history that cannot be recreated
- integrations that have quietly worked for years
- reports somebody needs every month
Three routes and when each applies
Re-hosting
The system stays the same and moves to a new environment. Fastest and cheapest when the problem is only hardware or hosting.
Gradual replacement
Parts are replaced one at a time, with old and new running side by side for a while. The usual route for systems that cannot stop.
Full rebuild
Only sensible when the old system is so tangled that any change costs more than building new.
Which route is right becomes clear after a technical review - not from a description over the phone.
Running in parallel
In a gradual replacement two systems exist at once for a while. That is the delicate part and has to be planned in advance: which system is the source of truth, how data is kept in sync and when the old one is switched off.
- a defined source of truth for each piece of data
- synchronisation that does not create duplicates
- a clear switch-off date for the old system
- an archive of the old system after switch-off
How we build the system
Architecture
We define the data model, modules and system boundaries before development, so later growth doesn't require a rewrite.
UX/UI
You approve the user journeys and a prototype of the key screens before any feature is written.
Frontend and backend
The interface and the server side are built to one standard: readable code covered by automated tests.
Integrations
Connections to ERP, CRM, document systems and registries, with logging and retries.
Data
Migration, cleanup and data quality rules, so the new system doesn't inherit the old errors.
Security, quality, rollout
Security
Authentication and permissions, encryption in transit and at rest, an audit trail and a review before go-live.
Testing
Automated tests, regression and acceptance testing against your criteria, not ours.
Deployment
Separate environments, phased release and the ability to roll back within minutes.
Handover
Code, access, documentation and team training. The system stays yours.
Maintenance
An agreed response time, monitoring and a monthly allocation for enhancements.
Related work
FAQ
Can you extend our existing system instead of building a new one?
Yes. We first look at what is worth keeping; we propose new development only when modernisation isn't enough.
Who owns the code?
You do. At handover you receive the code, the access and the documentation.
What happens after go-live?
With an agreed response time, monitoring and a monthly allocation for enhancements.
Related reading
Related solutions
Sounds like your project?
Send us the project description, your existing system, the tender documents or the event date.