Legacy systems
We read your old system so you don't have to start from scratch. Most modernisation projects fail because teams skip the mapping step and go straight to rewriting. We start by understanding what the system actually does before we touch a single line.
What is it
Legacy modernisation is the process of mapping, documenting and incrementally replacing software that works but that no one fully understands anymore. Instead of a risky big-bang rewrite, we identify what the system actually does, separate the logic worth keeping from the parts worth replacing, and build a migration path that keeps the business running throughout.
What we do
We read the codebase and document what it actually does: data flows, business rules, edge cases. Delivered as a structured reference your team can act on immediately, whether you migrate next month or next year.
Critical business logic buried in Excel, Access databases or email chains. We extract it, document it, and prepare it for migration.
We replace one part of the system at a time, keeping everything running. Each stage is tested in production before the next begins. No big-bang rewrites, no periods where the business cannot operate.
When a developer leaves or a vendor relationship ends, we step in and make the system understandable for whoever comes next. We document the architecture, the business rules, and the known quirks, so the next person is not starting from zero.
How we do it
We start with the code, the data, and the people who use it daily. The goal is a complete picture of what the system does, not what the documentation says it does.
Most legacy problems are discovered here: undocumented rules, data inconsistencies, hidden dependencies. Finding them early prevents expensive surprises during migration.
Everything we find gets documented: business rules, data models, integration points, known workarounds. This document exists regardless of what happens next.
Even if you decide not to migrate, you end up with something your team didn't have before: a clear picture of what you're running.
Migration happens in stages. Each stage delivers something working: a replaced module, a migrated data store, an automated process that used to be manual.
The old system stays running until the new one is proven. We watch the first production runs together and fix anything unexpected before the cutover.
Why Hemlex
We run several software products ourselves. We have dealt with undocumented logic, missing context, and code written by people who are no longer available. The work we do for clients is the same work we do on our own systems.
Everything we build and document is yours. We use standard technology (TypeScript, PostgreSQL, REST APIs) because any developer can maintain it after we leave. Full codebase and documentation handover is included.
Legacy work is inherently uncertain. We find things as we go. We handle this with staged fixed quotes: each phase is scoped and priced before it starts. No open-ended retainers, no surprise invoices.
We work with TypeScript, PostgreSQL, REST and GraphQL APIs, and standard cloud infrastructure. We can also work with your existing stack (PHP, Python, .NET, or older JavaScript frameworks) to ensure migration is gradual and reversible.
Frequently asked questions
Rough range: two to four weeks for a codebase of typical small-business size. Larger systems with multiple integrations take longer. We give you a realistic estimate after an initial conversation. We will not start the clock until the scope is agreed.
That is the most common situation. We read the code directly, interview the people who use the system, and trace the data. Missing documentation is a problem we solve, not a prerequisite we need.
No. We have worked with PHP 5, classic ASP, Access databases, and Excel-based processes. The technology age matters less than understanding what the system does. That is what we focus on first.
Documentation only is a perfectly valid outcome. Some clients commission a mapping project to understand what they have, then decide internally what to do next. Others use it as the basis for a migration. Either way, the deliverable is yours.
We never touch a production system without a tested rollback plan. Migration is staged: we run old and new in parallel until the new one is proven. The business keeps running throughout.
You receive the full documentation, the migrated codebase, and a handover session with your team. We are available for follow-up questions for 30 days after delivery. After that, the system is yours. No ongoing dependency on us.
Start a project
Email us a description of the system. We reply within one business day. No discovery call, no gate.
