Service / Legacy systems
Take over and improve a working legacy system without throwing it away.
Old technology alone is not a reason to rewrite a system. I first understand the request, the parts that already work and the actual risk. A small need gets a focused change; a long-term need gets a controlled modernisation plan.
Signs you need help
Does one of these problems sound familiar?
The need for a takeover usually comes from losing a safe way to maintain the business, rather than from the age of the technology itself.
- You can no longer reach the person or company that built the software.
- Even a simple feature or integration takes weeks to deliver.
- Every change goes straight into production because there is no test environment.
- The system makes money, but nobody knows which parts are safe to change.
Real example
A Classic ASP B2B sales system running since 2007
The system I took over was written in Classic ASP with MySQL. It had processed sales since 2007, ran reports built up over the years and exchanged data with Netsis ERP. The technology was old, but the company’s daily operation depended on it.
The request was clear: import supplier inventory through JSON. Classic ASP with VBScript has no built-in JSON support, so the work needed an external parser or a COM/.NET component. An integration that would be straightforward in a current stack took longer here.
That did not make a full rewrite the right answer. Rebuilding and testing the existing reports, Netsis connection and years of working processes would have cost far more and introduced much more risk.
Business result
The company could offer supplier inventory alongside stock held in its own warehouse. It began taking orders for products before tying up cash in purchasing them, while the existing system and Netsis integration kept running.
Approach
First I clarify the work, then I go only as deep as it requires.
I do not rebuild the entire environment for one integration. I also do not ignore testing and backups when development will continue for months. The preparation should match the work.
-
01
We agree on the result first
We start with what needs to be different when the work is finished. That lets me inspect the relevant code, data and workflow without disturbing unrelated areas.
-
02
I check the risk around the change
If the work affects data or a live integration, I verify the backup, logs, scheduled jobs and the route back to the previous working state.
-
03
For ongoing development, I build a safe working setup
I do not spend weeks preparing an environment for a small correction. For regular development, I set up testing, version tracking and a repeatable release process.
-
04
Keep the current system or replace it in stages?
I compare the time and risk of staying on the current system with the migration and testing load of modernisation. We make the decision from that total.
Decision model
When should a legacy system be modernised?
Modernisation can make sense when the same work repeatedly takes longer in the legacy system and the total cost of a safe move is justified by that difference. The calculation includes data migration and testing, not only coding.
1 week
Illustrative delivery time for the module in a current stack
1 month
Illustrative delivery time in the legacy stack
2 weeks
Illustrative time to reproduce and move the system
The figures only illustrate the decision. Reproducing a system used for years in two weeks is rarely realistic. Even if the code is written quickly, data checks, user testing and the production cutover may take months.
Deliverables
What will you have at the end of the work?
Depending on the need, the work produces one or more of these results.
- The requested feature or integration is working in production.
- A safe test and release environment is set up for ongoing development.
- Backups, monitoring or the server setup are improved where needed.
- You receive a roadmap showing which parts should change and when.
- Where necessary, the website, portal or internal system is replaced in stages.
How does the service work?
The first call is free. You explain what you need; I set out the work, priorities and an approximate time requirement.
Once we start, review, planning, development, testing and release all come out of the monthly hours you choose. You do not wait for a separate quote at every step.
The contract runs for twelve months. Larger work is spread across the monthly capacity instead of being forced into the opening months. This reduces both the payment burden and the risk of changing a live system.
Good fit
- — Companies with regular software work but no need for a full-time engineer
- — Businesses that want to improve existing systems over time
- — Teams that do not want a separate per-user licence for every internal process
Poor fit
- — One-off jobs that will need no continuing support
- — Projects that need near full-time development capacity immediately
Questions
What companies ask before a takeover
Does a legacy system always need rewriting?
No. Age and technology are not enough on their own. If the existing system can meet the need at reasonable cost and risk, continuing to improve it may be the better decision.
Can you work without a test environment?
Yes. This is common in older systems. Small and clearly bounded changes can be made in production with suitable precautions. For sustained development, creating a test environment will usually become a priority.
Is the initial technical review charged separately?
The one-hour introductory call is free. After we agree to work together, technical review, planning and delivery come out of the monthly hours you choose.
Can we hire you for one integration only?
The service is built around a twelve-month relationship rather than one-off project work. An integration fits when it is part of the system’s continuing development and improvement.
What do you check before touching production?
It depends on the impact of the request. I at least understand the relevant data flow and rollback path; for riskier work I also verify backups, scheduled jobs, logs, the server and integration dependencies.