Legacy system modernization, without interrupting operations
We assess the systems you run today, keep what works, replatform what holds you back, and migrate without stopping the operations that depend on them. You see the plan, the order of the cutover and the rollback before any of it starts.
A written scope and a fixed budget before any work is billed.
A system the business cannot do without, and cannot change
A legacy system usually still works, which is why it is still there. It runs on a version of PHP, .NET or a database that is out of support. It deploys over FTP to one server. The person who understood it has left, and every change takes weeks because nobody can predict what it will break.
Modernization rarely means rewriting everything at once. We start with an assessment that maps what the system does, what depends on it and where the risk is. Then we decide, part by part, what to keep, what to move to a current platform and what to replace, and we migrate in stages, each with a rollback path, so operations continue through the whole project.
The application, its code and its data are what this page covers. Moving infrastructure to the cloud and running it afterwards is cloud and DevOps, and the two are often one engagement.
Sound familiar?
Nobody wants to touch it
The code has no tests and little documentation, so every change is a risk and the backlog of small requests keeps growing.
It runs on software that is out of support
Old PHP, .NET or database versions no longer get security fixes, and an audit or a customer questionnaire has started asking about it.
Deploying means copying files to a server
Releases go out over FTP at night, there is no way to roll back, and one bad deploy takes the whole system down.
New work has to fit around it
Every new product or integration has to be bent around a system that cannot offer an API, so the old system sets the pace for everything else.
Assess, keep, replatform, migrate
Four steps, in this order, on every modernization project.
Assess
We map what the system does, the data it holds, what depends on it and where it is fragile, and write it down before recommending anything.
- Inventory
- Dependencies
- Risk
Keep
Business rules that work and data that is right stay. Some of the oldest code encodes decisions nobody wrote down anywhere else.
- Business rules
- Data
Replatform
The parts that hold you back move to a current stack, often from a single monolith to services with a queue between them.
- Node
- Postgres
- Services
Migrate
Data and traffic move in stages, each with a tested rollback path, so the business keeps running through the cutover.
- Staged cutover
- Rollback
What you keep at the end
Everything below is yours from the first commit, under your own accounts wherever possible. Nothing in it is licensed from us, and nothing can only be maintained by us.
your-company/
- docs/assessment.mdWhat the old system does, what depends on it and where the risk sits.
- docs/migration-plan.mdThe order of the cutover, each stage’s rollback and its success check.
- src/The modernized application, with the test suite the old one never had.
- data/Migration scripts and the checks that prove each record arrived intact.
- docs/runbook.mdHow the new system is deployed, monitored and rolled back.
Four stages, and what
each one hands you
Every stage ends in something you can review and keep, including the stages that come before any code is written.
Discovery and requirements analysis
We map the real problem before any code is written: stakeholders, constraints, existing systems, and what success means in measurable terms.
- requirements.md
- scope + fixed budget
- risk register
Design and architecture
Interface flows and system architecture designed together, so what we specify is what we can build and scale.
- clickable prototype
- system diagram
- data model
Build, with a weekly demo
Short delivery cycles with visible progress. You review working software throughout, not a finished system revealed on launch day.
- staging deploy / cycle
- test suite + CI
- weekly demo
Launch, then operations
We deploy the system, monitor it, and hand over the runbook. We then continue to operate it under a monthly agreement you can end with 30 days’ notice.
- production infra
- runbook + handover docs
- monitoring + alerts
Terms we put in writing
before work begins
The figures we commit to on every engagement. Your project gets its own dated plan on top of them.
- Inquiry
- 1 business dayA reply from someone who has read the brief.
- Discovery
- 1 to 3 weeksEnds in a written scope and a fixed budget.
- Weekly review
- Every weekThe work as it stands, on a link you can open yourself.
- First release
- 8 to 16 weeksTypical time from the end of discovery to production.
- Operations
- 30 days’ noticeMonitoring and iteration under a monthly agreement.
Illustrative. Every project receives its own dated plan before work begins.
What a modernization project costs
The assessment is part of discovery. We read the code and the data before pricing anything, and the fixed figure is set against the written migration plan that comes out of that reading.
- 01The size of the codebase and how much of it is still used
- 02How much data moves, and how clean it is
- 03How many other systems depend on the old one
- 04Whether the cutover can happen in stages or needs one window
- 05Tests and documentation that exist today, if any
- 06Whether we also run the new infrastructure afterwards
Why we migrate in stages
A full rewrite delivered in one cutover is the plan most often proposed for a legacy system. It is also the riskiest one.
One big rewrite
- Months of building before anyone uses the new system.
- The old and new systems drift apart while the rewrite catches up.
- One cutover weekend, and no easy way back if it fails.
- Undocumented rules in the old code are lost in the rewrite.
A staged migration
- Each stage reaches production and is used before the next begins.
- Both run side by side, and traffic moves across part by part.
- Every stage has a rollback path, tested before the switch.
- The assessment writes those rules down before any code is replaced.
What we build it with
Tools with long support horizons and large talent pools, so the system stays maintainable by any capable team, not only ours.
Node.js
A current, long-supported runtime for the services that replace the old monolith.
PostgreSQL
Where migrated data lands, with constraints that keep it clean from then on.
TypeScript
Types that turn the old system’s unwritten rules into checks the compiler enforces.
Vercel
Preview deploys for every change, replacing the night-time FTP release.
Questions buyers ask us
The ones that come up most in first conversations about this service.
Something not covered here?
Email us at hello@kodfabrika.com.
Related services
Built to last.
Started this week.
Tell us what you’re building. You’ll receive a written scope, a defined budget, and a delivery plan. Not a proposal deck.