11 Review & continuity
Software modernisation & maintenance
Taking over and maintaining software you already run — framework, dependency and database upgrades done step by step, while the system stays in use.
Outcome: The software you already rely on, safe to change again.
Modernisation is work on legacy software your business still runs on: taking it over, bringing its framework, runtime and database up to supported versions, and keeping it maintained afterwards. The system stays in use while the work goes on — each change ships on its own, small enough to review, test and release, and any planned downtime is agreed in advance.
It fits when replacing the system would cost more than repairing it: the workflow is right, but the code is outdated, nobody left knows it well, or every update feels risky. If the first question is whether the system is worth keeping at all, a technical audit comes first.
Typical needs
- A business-critical application on versions nobody dares to upgrade
- Dependencies with known vulnerabilities, or a framework past its end of support
- The developer or agency who built it has moved on
What you receive
- Tests and documentation around the parts that matter, before the upgrades begin
- Upgrades and migrations in small, tested releases — no big-bang rewrite
- Ongoing maintenance: dependency and security updates, fixes and improvements
Approach
How the work runs.
- 01
Take over and reproduce
Access to the code, environments and deployment setup is handed over and documented. The application is then built and run from the repository alone, so nothing depends on one person’s machine.
- 02
Checks before changes
Automated checks go in before any upgrade: lint, type checks, a build and tests for the flows the business depends on. From then on, every change runs them.
- 03
Upgrade in small steps
Framework, runtime, dependency and database upgrades are ordered so that each release stays small. Migrations are versioned, and where a part is replaced, old and new run side by side until the switch is safe.
- 04
Keep it maintained
Dependencies are updated and security patches applied on an agreed schedule, alongside fixes and improvements. Every change is recorded, so the next engineer can pick up where the work left off.
Technologies
- TypeScript
- React & Next.js
- Node.js
- PostgreSQL
- GitHub Actions
The engineer who does this work is the founder, Filip Volf — you work with him directly.
Questions
About this service.
How is modernisation different from technical audit & architecture consulting?
A technical audit ends with a written review — findings, priorities and trade-offs — for you to decide on. Modernisation is the work itself: the upgrades, migrations and maintenance. An audit is a good first step when you are unsure what is worth keeping; when the direction is already clear, the work can start without one.
Do you rewrite the software from scratch?
Not as a whole. Working software holds years of business rules that a rewrite would have to rediscover. Instead, it is upgraded and replaced piece by piece while it stays in use; a part is rebuilt only when that costs less than repairing it.
Can you take over software someone else built?
Yes — taking over is where this work starts. It fits best with TypeScript, React or Next.js front ends and Node.js or PostgreSQL behind them. The first step is getting the code, environments and deployments under control; scope and terms are agreed in writing before work begins.
Related services
- 08
Cloud infrastructure & integrations
Outcome: Routine releases and observable integrations.
- 10
Technical audit & architecture consulting
Outcome: What to fix first, what can wait — and why.
- 12
Remote engineering partnership (B2B)
Outcome: More engineering capacity, with clear ownership and a clear contract.
Next step
Let’s talk about what you’re building.
Describe what you need built or fixed, how the work runs today and the constraints. You get clarifying questions or a first outline of the approach — by email, in English or Serbian.