Can you work with old technologies?

Yes. We regularly read and wrap older .NET Framework, Java, PHP and database-heavy systems, including 1C / BAS-based back offices, before replacing parts of them.

How do you avoid downtime?

By never switching everything at once: routing layers, parallel runs and per-capability cut-overs with rollback.

Service · Legacy modernization

Modernise the legacy system — without betting the business on a rewrite.

Big-bang rewrites are famous for running late, missing hidden business rules and ending up with two systems to maintain. We modernise incrementally: capture what the old system really does, wrap it, replace it piece by piece and switch traffic over only when each piece is proven.

Understand

Map · characterisation tests

Wrap

Routing layer · APIs

1.5

Replace piece by piece

One capability at a time

Migrate data

Reconcile · rollback plan

Retire legacy

Switch off with confidence

059 stages

Rewrite, refactor, re-platform or replace?

Option	When it fits	Risk
Re-host / re-platform	Infrastructure is the problem (end-of-life servers, data centre exit)	Low — behaviour stays the same
Refactor in place	Code is maintainable enough; specific modules hurt	Low to medium
Incremental replacement (strangler fig)	Architecture blocks the business, but the system must keep running	Medium — controlled step by step
Replace with off-the-shelf	The capability isn’t a differentiator (e.g. generic HR, accounting)	Medium — migration and process change
Big-bang rewrite	Rarely justified: small systems with well-understood behaviour	High

Our approach

1
Map what exists
Modules, integrations, data flows, batch jobs, reports — and the undocumented business rules hiding in stored procedures and spreadsheets.
2
Pin down behaviour
Characterisation tests capture current outputs for real inputs, so the new implementation can be proven equivalent (or deliberately different).
3
Introduce a seam
An API or routing layer in front of the legacy system lets new components take over capabilities one at a time.
4
Replace and shadow
New components can run in parallel, compared against the legacy output, before traffic switches over.
5
Migrate data carefully
Incremental migration with reconciliation reports and a rollback plan for each step.

Frequently asked questions

ServiceProject rescueVendor gone, deadline slipping, code nobody understands? We take over troubled software and AI projects: fast audit, stabilisation, a plan you can trust.ServiceCloud & DevOpsCloud & DevOps in your own Azure or AWS account: infrastructure as code, CI/CD, observability, security and cost control — documented for your team.GuideSwitching vendors without a rewriteHow to change development vendors safely: secure assets, plan the handover, transfer knowledge and keep shipping — with a complete handover checklist.GuideAI integration with BAS / 1CConnecting AI to BAS and 1C-based ERPs: integration options, document recognition, reconciliation help, natural-language reports and safe write-back.

Want a second opinion on your project?

Tell us what you’re building and where you’re stuck. We’ll reply within one business day with the most practical next step — even if that step isn’t us.

Start a project