Service · Migration and modernization
Legacy system migration and modernization, without losing data
We migrate, rewrite and stabilize systems that are already in production while the business keeps running on them. In our largest migration, a platform serving over half a million requests a day moved to the client's own cloud with under three hours of cutover and zero data loss.
Proof · 2 h 54 min cutover · zero data lost · 24 of 25 integrations untouched
Nobody wants to touch the system everything depends on
The system works, more or less. It takes seconds to respond, goes down at peak times, runs on a server nobody knows how it was set up, and it's used by customers or partners who can't be left without service. Rewriting it is scary, and rightly so: most migrations that go wrong don't fail because of the new code, but on cutover day.
That's why a migration is planned as an operation: a layer that keeps existing consumers compatible, a comparator that checks record by record that the new system answers exactly like the old one, an incremental data copy rehearsed before cutover, and a step-by-step rollback procedure.
What we do
- 01
Technical audit
Code, database, infrastructure, integrations and security, reviewed with read-only access. Deliverable: risks, dependencies and work order, with security and quality findings documented.
- 02
Infrastructure migration
From your own servers or someone else's account to infrastructure owned by your company (AWS, Azure, Google Cloud or dedicated servers), defined as code and at the right cost.
- 03
Rewrites that don't break integrations
From unsupported frameworks (for example, old Ruby on Rails or unmaintained PHP) to a current TypeScript base, with a compatibility layer. In our largest migration, 24 of 25 third-party integrations kept working without their owners changing anything.
- 04
Verified data migration
Incremental copy from the legacy system, equivalence checks between the old and new systems, and a cutover rehearsal before the real day.
- 05
Performance and stability
Slow queries, indexes, caching, queues for heavy work and containers, with load tests and response times measured before and after.
We work on what already runs, whether PHP, .NET, Java, Python, Node, Ruby, Go or Delphi, and we understand it before touching it.
Risks we control
- Losing data along the way
- A rehearsed incremental copy and a comparator that checks, record by record, that the new system answers like the old one.
- Breaking whoever connects to it
- A compatibility layer: partners and integrations change nothing on cutover day.
- A cutover that drags on
- A written procedure, rehearsed before the real day, with a short window and a rollback plan.
- Inheriting security problems
- A read-only audit before touching anything; whatever we find is fixed by design in the new system.
What we build it with
We've started from Ruby on Rails, MySQL and PHP and landed on TypeScript (NestJS), PostgreSQL, Redis and AWS (ECS, RDS, S3 and infrastructure as code), with load tests in k6. If your system runs on something else, we understand it before we touch it.
How we migrate without stopping operations
01
Audit
Read-only
We review code, data, infrastructure and integrations, and document risks, dependencies and the order in which to move. We sign an NDA first.
02
Migration plan
Fixed proposal
Phases, measurable success criteria, a cutover window and a rollback plan, with price and dates.
03
Phased migration
Without stopping the operation
Each phase is rehearsed, verified against the previous system and can be undone. The final cutover follows a written procedure; nothing is improvised.
Is it right for your company?
It's for you if…
- Your system is slow, goes down at peak times or runs on unsupported technology.
- Customers, partners or other systems depend on it and can't be left without service.
- Nobody on your team dares to touch the code or the infrastructure.
It may not be for you if…
- The system will be replaced by an off-the-shelf product within a few months: invest in that transition, not in a rescue.
- You want 24/7 support or a help desk: we don't offer that service.
Frequently asked questions
Do you need to switch the system off to migrate it?
No. The operation keeps running on the current system while the new one is built and verified. Cutover happens in a short, planned window, with a procedure to roll back if something fails. In our largest migration, cutover took under three hours and no data was lost.
Is it better to rewrite from scratch?
Almost never as a first step. Rewriting is expensive and slow, and meanwhile the current system keeps failing. First we stabilize what runs; if the numbers show that replacing a part costs less than maintaining it, we propose it in phases.
What happens to the systems connected to the current one?
They keep working. We build a compatibility layer that answers exactly like the previous system, so customers, partners and integrations don't have to change anything on cutover day.
Can you lower what I pay for servers or cloud?
Often, yes, as a consequence of fixing the cause: efficient queries and right-sized resources need less machine. We also review idle resources and price commitments on AWS, Azure or Google Cloud. We don't promise a figure without seeing your account.
Do you need write access to my systems?
Not for the audit: we work with read-only permissions. For the migration we agree with you on the permissions needed, phase by phase, and we sign an NDA before the first technical meeting.
Go deeper
Tell us which system worries you
In 30 minutes we review the case and tell you where we'd start: stabilize, migrate or rewrite in phases.