Code audit
Static analysis, a map of dependencies, a security scan and an estimate of technical debt, documented with risks and priorities.
Legacy modernisation · Staged replacement
Replace the old system without stopping the business.
Legacy system modernisation means rebuilding an ageing application in planned stages while the current one keeps running, instead of switching everything off on a single day. We audit the existing code and data, agree the order of replacement in writing, and move each module only after its data has been checked against the old system.
- Old and new systems run side by side
- Data checked before each switch
- A rollback plan for every cut-over
The problem
Old software rarely fails at once. It slows everything down first.
Most legacy systems still do their job. The trouble shows elsewhere: libraries that no longer receive security updates, small changes that take months because nobody is sure what they will break, and fewer developers willing to work on the code at all.
A full rewrite delivered on one launch day looks tidy on paper, but it puts every process at risk together. We prefer to replace the system piece by piece, so each step is small enough to test properly and to reverse if needed.
Our approachKeep the current system running, build the new parts beside it, move data and users module by module, and retire the old code only when nothing depends on it.
- Priorities set by business risk, not by what is easiest to code
- Every stage approved by you before the next begins
- Schedule written into the contract as milestones
What we do
Six parts of a modernisation, scoped to your system.
Not every project needs all six. The audit decides which ones apply, and the written quote lists only those.
Data migration
Transformation rules for every field, clean-up of inconsistent records and automated checks before and after each transfer.
Staged replacement
The strangler fig pattern: new modules take over one function at a time while the old system handles the rest.
API layer
A REST or GraphQL layer in front of the old system, so new applications and partners can connect without touching legacy code.
Cut-over planning
Low-risk modules move first, critical processes later, each with a rollback plan ready on the day.
Documentation
Technical documentation and an API reference for the new system, kept current as it changes.
How it runs
Four stages, each signed off in writing.
Clients abroad follow the work by video call and on a private preview environment, in the same UTC+3 time zone as Riyadh, Kuwait City and Doha.
- Review the current systemSource code, dependencies, performance and the business processes it supports. You receive a technical debt report and a proposed order of work.
- Agree the planTarget architecture, technology choice, a risk matrix and milestones. The order in which modules move is fixed before any code is written.
- Build in parallelNew modules are developed while the old system stays live. Each one passes unit and integration tests, then data checks in a staging environment.
- Switch in stepsModules go live one by one with a rollback plan prepared. The old system is switched off gradually, once nothing relies on it.
Is it time?
Signs a system needs work, and signs it does not.
Modernisation is worth discussing if
- Core libraries or the language version no longer receive security updates
- Simple changes take far longer than they should, or are avoided altogether
- Data lives in spreadsheets or ledgers beside the system because the system cannot hold it
It may not be needed yet if
- The system is stable, supported and changes rarely
- The real issue is one missing report or integration, which a smaller project can solve
Kodem develops your software, hosts it on servers in Türkiye and keeps it up to date. The source code stays with Kodem. Your domain is registered in your name, and your content and data are always yours.
Related work
Systems we have moved from old to new.
A paper ledger replaced by business software, a site migrated without losing an address, and a compromised server rebuilt cleanly.
Cold storage operatorBusiness software · From ledger to system652 end-to-end test checks
From a paper ledger to role-based, auditable business software
Customer accounts, warehouse in and out movements, a cheque portfolio, commissions and the journal in one system, with in-cell editing so the team keeps its spreadsheet habits.
- 3 user roles with server-side permission checks
- Field-level change history: who changed what, and when
- An installable app that can work offline
- 12 end-to-end test suites, automatic daily backups
Industrial consultancyCorporate site · Migration from a hosted platform355/355 old URLs verified
All 355 URLs of the old site, carried over without a single loss
A site that had attracted search traffic for years was moved to a new custom-coded architecture. Every old address was checked one by one, so its standing in search engines was preserved.
- All 355 old URLs verified, 0 errors
- Every image migrated (161/161)
- Lighthouse: mobile 90–100, desktop 100
- WCAG 2.2 AA automated audit: 0 violations
Beekeeping supplies storeCatalogue · Security and SEO recovery12 → 0 critical findings
From a site taken over by malicious code to a clean, fast catalogue
Malicious code had been planted on the old server. 101 products, each with its own original usage text, were moved to a clean infrastructure together with beekeeping calculators and a glossary.
- Critical SEO findings 12 → 0, warnings 389 → 30
- 101 product pages, each with original text
- 413/413 automated tests
- Lighthouse desktop 100 (10/10 pages), mobile 92–98
How it was measured: Findings were measured with a site-wide SEO audit script, pages with an automated test suite, and speed with Lighthouse.
Projects are anonymised: we do not publish client names without written consent. Figures are from handover-day tests; live values may change over time.
How we keep risk down
Small steps, each one reversible.
Full backup first
A complete copy of the source data is taken before any transformation starts.
Automated data checks
Record counts, totals and key fields are compared between old and new, and differences are reported to you.
Staging acceptance
Each module is accepted in a staging environment before it reaches real users.
Rollback ready
Every switch has a written way back, prepared and tested before the day.
Questions
Questions about legacy modernisation
Can the old system keep running during the work?
Yes. The new modules are built in parallel, and users keep working in the current system until each module is ready to take over. Switches are planned for the times that affect your operations least.
How do you handle the risk of losing data?
We take a full backup of the source system, apply transformation rules in stages and run automated integrity checks before anything goes live. A rollback procedure is ready for each switch. We plan to keep risk low; we do not promise that no problem can ever occur.
Do we have to replace everything at once?
No. Using the strangler fig pattern, parts of the system are replaced in a chosen order. High-risk or low-priority parts can be left until last, which keeps both budget and operational risk manageable.
How long does it take?
It depends on the size and condition of the system, so we do not quote a duration before the review. After the review, the plan is split into milestones and written into the contract.
Which technologies do you move systems to?
The target stack is chosen after the review, based on the existing system and what the business needs. Common choices are PHP with Laravel, Node.js, React or Vue on the front end, and PostgreSQL or MySQL for data.
Can the system be in English and Arabic?
Yes. New interfaces can be built bilingual, with the Arabic version laid out right to left rather than simply translated.
Start with a review, not a rewrite.
Tell us what the current system does and where it hurts. After a free video call, we propose what to review and send an itemised quote in writing.