Legacy software modernisation services
Legacy software modernisation for systems that still run the business but slow it down: take-overs of code other teams wrote, upgrades to current releases and step-by-step replacement of old modules, without a big-bang rewrite. Nine systems have come to us from other teams so far, the oldest written in 2008.
How we modernise a legacy system
A read-only review first
The code, the dependencies, the deployment and the data read end to end before anyone changes a line, with a written list of risks in order of production impact.
Tests around what exists
Characterisation tests that pin down what the system does today, quirks included, so every later change is checked against real behaviour rather than memory.
Framework and runtime upgrades
.NET Framework to current .NET, Java 8 to a current LTS, PHP 5 to PHP 8, Python 2 to 3 and AngularJS to Angular, one step at a time, each step released on its own.
Strangler-fig replacement
New modules built beside the old system behind a routing layer, taking over one feature at a time until the old code can be switched off, with no single day on which everything changes.
Database modernisation
Business logic moved out of stored procedures into tested code, schema changes turned into versioned migrations, and data on unsupported database versions moved with a reconciliation report.
Security debt paid down
Unsupported dependencies replaced, known vulnerabilities fixed, secrets moved out of configuration files into a vault, and dependency scanning in the pipeline so the debt does not return.
Hire engineers for legacy systems
Dedicated engineers for legacy systems
Engineers for legacy systems who join your team full time, work in your tools and process, and report to your lead. You interview them; we carry the Ukrainian contract, payroll, invoicing and leave.
Modernisation projects
A defined piece of modernisation with a scope, a fixed plan and a named lead on our side who owns the result and reports progress in your channels.
Ongoing modernisation
Modernisation as a continuing service: the same people every month, a backlog you prioritise, and hours you can see in our portal and on the invoice.
The dedicated team page explains how specialists join your team, and the outsourcing page covers project delivery, take-overs and how we charge.
Who works on your modernisation
Technical lead
Owns the review, the risk list and the order of the work
.NET, Java and PHP engineers
Upgrades and refactoring in the system’s own language
Cloud and DevOps engineers
Pipelines, infrastructure as code and the move off old servers
QA engineers
Characterisation and regression tests
Modernise in steps, not in one rewrite
A full rewrite stops delivery for months and usually loses behaviour nobody wrote down. We modernise in steps instead: each one small enough to release, tested against what the system did before, and chosen by the risk or the cost it removes, so the business keeps running on the system while it changes.
A take-over starts with a read-only review and a written list of risks before any fix. Sometimes that list shows a module is better rewritten, and then we say so, with the reasons in writing and the rewrite planned behind the same tests.
Other solutions we deliver
MVP development
MVP development services for founders and product teams: scoping, a Figma prototype, a web or mobile build and launch on a stack that carries the next version, by dedicated MVP developers or as a project.
SaaS development
SaaS development services: multi-tenant architecture, subscriptions and billing, enterprise single sign-on, support tooling and releases without downtime, by dedicated SaaS developers or as a project.
Web application development
Web application development services: customer portals, internal tools, dashboards and progressive web apps, with the backend and hosting included, by dedicated web developers or as a project.
API development
API development and integration services: REST and GraphQL APIs, third-party integrations, event-driven messaging and webhooks, monitored on every connection, by dedicated API developers or as a project.
Cloud migration
Cloud migration services: workload assessment, landing zones in Terraform, and database and application moves to Azure, AWS or Google Cloud with a planned cut-over, by dedicated cloud engineers or as a project.
Questions about legacy modernisation
Should we rewrite or modernise?
Usually modernise. A rewrite makes sense for a module whose behaviour is well understood and whose code blocks every change; for the rest, incremental upgrades and strangler-fig replacement deliver value sooner and keep the knowledge built into the old code. The review gives you that decision per module, in writing.
Our original developers have left. Can you still take the system over?
Yes. We work from the code, the database, the deployment and the people who still use the system, and the written risk list tells you what we found before you decide what to change.
Does the old system keep running while it is modernised?
Yes. Fixes and security patches continue on the live system throughout, and each modernisation step is released on its own, so there is never a period when the business waits for the new version.
How quickly can engineers for legacy systems start?
When the right modernisation engineer is available, the start is gated only by your interview and the NDA and IP assignment. Otherwise we run a search, which typically produces candidate profiles within two to three weeks, and nobody starts until you have said yes.
How do we hire engineers for legacy systems through BigTree108?
Tell us the work, the seniority and the hours you need. We propose one or two people with their profiles, you interview them the way you would interview your own hire, and you sign one agreement with BIG TREE 108 LLC and receive one invoice a month.
Who owns the work they produce?
You do. Every specialist has a signed contract with BigTree108 that assigns all work product to the company, and our agreement with you assigns it onward. Code, designs and documents are delivered into your own repositories and tools, not kept where only we can change them.
Running a system nobody wants to touch?
Send the repository or a description of the system. You get an answer within one business day: a plan for the review and the first steps after it.