Move from legacy stacks to React, Next.js & modern microservices.
When a codebase has become painful to work with — features take too long to build, bugs keep coming back, developers dread touching certain parts — the instinct is often to rewrite everything from scratch. The old code is the problem, and new code will fix it. This reasoning is appealing and usually wrong. Joel Spolsky called it the single worst strategic mistake a software company can make, and the reason is that the existing codebase, however painful to work with, contains a huge amount of accumulated knowledge — about edge cases, about customer behavior, about the business rules that aren't documented anywhere — that gets lost in a rewrite.
More concretely: rewrites take far longer than estimated, they don't get the full attention of the business because the old system is still running and still needs maintenance, and when the rewrite finally ships it often introduces regressions — bugs that were fixed years ago, edge cases that were handled quietly — because the new system doesn't have the scar tissue the old one accumulated. The new system is fresh and clean and has a different set of problems that will take years to fully understand.
Incremental modernization is almost always the better approach. It keeps the product running throughout, it delivers improvements continuously rather than in one big risky release, and it maintains the institutional knowledge embedded in the existing system while progressively replacing its most problematic parts.
The first step is mapping the existing system thoroughly — not just the documented parts but the undocumented behavior that users depend on. This is the most important and most often skipped step in modernization projects. Code that looks like dead code often isn't. Functions that look like they could be simplified often have edge cases that aren't obvious from reading the code. Before changing anything, we need to understand what it actually does.
We also map the dependencies: what calls what, what's coupled to what, where the natural seams in the system are. These seams are where the incremental work happens — replacing one module at a time, where each module has well-defined inputs and outputs and can be replaced independently without affecting the rest of the system.
The strangler fig pattern is the standard approach for incrementally replacing legacy systems. Named after a tree that grows around a host tree and eventually replaces it, the pattern involves standing up a new system alongside the old one, gradually routing functionality to the new system, and eventually decommissioning the old system when the new one handles everything.
In practice, this looks like: route a specific feature or section of the application to the new implementation while everything else continues to run on the old system. Test the new implementation thoroughly. Expand the new implementation to cover more functionality. Continue until the old system handles nothing and can be removed. This approach means you're never betting the whole product on an untested system — real users are using the new implementation at every stage, giving you feedback that purely internal testing can't provide.
PHP monoliths to Next.js are one of the most common migrations we handle. PHP applications built in the 2010s often have all the classic monolith problems: business logic mixed with presentation logic, global state everywhere, a test suite that's either nonexistent or too brittle to trust, and a deployment process that involves FTP or SSH and a lot of hope. Migrating these incrementally means starting with the highest-traffic or highest-value parts of the application and gradually moving the whole thing over.
Monolith to service-based architectures is a different kind of migration that's often oversold. Breaking a monolith into microservices is appropriate when the monolith has real scaling problems (different parts of the system need to scale independently), when different parts of the system have genuinely different deployment requirements, or when the teams working on different parts of the system are large enough that the coordination overhead of a single codebase is a real problem. For most products, these conditions don't exist, and the microservices migration creates distributed systems complexity without proportionate benefit.
Data migration is the most dangerous part of any system modernization. Schema changes, format changes, and moves between database systems all carry the risk of data loss or corruption if they go wrong. We treat every data migration as a high-risk operation with explicit safeguards: full backup before any migration runs, migration scripts that are idempotent (safe to run multiple times without producing incorrect results), validation queries that verify the migrated data matches the expected state, and the ability to roll back if validation fails.
Large data migrations are staged: run the migration on a sample, validate the results, then run on the full dataset. For live systems, migrations are designed to run without locking the database and without downtime — using techniques like adding new columns without removing old ones, backfilling data in batches, and making the application work with both old and new schemas during the transition period.
Running two systems simultaneously during migration has a performance cost. The strangler fig routing layer adds latency. Running old and new code paths in parallel for testing adds CPU cost. Dual-writes to old and new systems add database load. We plan for this explicitly: monitor performance throughout the migration, have a clear picture of the performance baseline before migration starts, and set thresholds at which we pause migration work to investigate performance degradation.
One of the goals of modernization is that the new system should be more understandable than the old one — not just to the people who built it, but to anyone who needs to work on it in the future. We document the new architecture, write ADRs (Architecture Decision Records) for significant decisions so the reasoning is preserved, and leave the codebase in a state where a new developer can understand the system without needing extensive briefing.
How do you decide what to migrate first? By the combination of pain and safety. The parts of the system causing the most development pain are the most important to address. The parts with the best test coverage and clearest boundaries are the safest to migrate first. Usually we start with a component that's both painful and relatively well-isolated.
How long does a migration take? It depends heavily on the size and complexity of the system. A focused migration of a specific component might take four to eight weeks. A full modernization of a large legacy system is typically measured in months, done as a phased project alongside ongoing feature development.
Do we have to stop feature development during migration? No. Incremental migration is designed to happen alongside normal product development. The migration work and the feature work may touch different parts of the system, or the team may be structured so that migration is a distinct workstream. Either way, the product continues to evolve during the migration.
Start by describing what's most painful about the current system — where developers slow down, what's fragile, what's preventing you from moving as fast as you want. That's where migration work should start.
Ready to get started?
Tell us about your project — we'll come back with a clear plan, not a sales pitch.
No fluff — just a real conversation about your project.
