What is legacy web migration?
Legacy web migration moves a web application off foundations that no longer serve it: an unsupported framework, a monolith that every team must touch, a data layer that resists change or hosting that cannot scale. The result keeps what the business depends on, the rules, the data, the URLs and the integrations, on top of a structure your team can evolve.
The hardest part is rarely the new code. It is everything the old system does that nobody wrote down: the edge case added for one customer years ago, the nightly job that quietly fixes bad data, the partner that still calls a forgotten endpoint. A migration succeeds when those behaviors are found before the switch, not after.
The work belongs to our web development consulting practice. Typical scopes include moving an AngularJS or jQuery frontend to a current framework, splitting a monolith into modules, upgrading a backend that is several major versions behind, or replacing a homegrown platform with a supported one. When servers or data centers move too, our cloud consultants join the plan.
Signs you need a legacy web migration
Legacy is not about age. A five-year-old application can be healthy and a two-year-old one can already be a liability. These signals tell us the cost of staying has overtaken the cost of moving.
The framework or runtime is out of support
Security patches have stopped or will stop soon, and every audit raises the same finding with a growing sense of urgency.
Hiring for the stack has become hard
Few developers want to work on the technology, and the people who know it are close to leaving or already overloaded.
Small features need large changes
Business logic is tangled with the user interface and the database, so a minor change touches dozens of files and needs a full regression test.
Integrations depend on outdated protocols
Partners, payment providers or identity systems are moving on, and the old application cannot follow without major rework.
None of these forces a full rewrite. They do mean the current structure needs a plan, because waiting tends to turn a series of manageable phases into one rushed project with a hard deadline.
What our migration assessment covers
The assessment turns an application that lives in people’s memories into a written map. Dependencies get particular attention, because they decide the order of the phases; our guide on managing application dependencies during a migration explains why blockers cascade when they are found late.
Feature and business rule inventory
Every screen, job, endpoint and rule the old system runs, including the undocumented ones found in logs and code paths.
Dependency and integration map
Databases, partners, internal services and scheduled tasks, with who calls what and how often.
Target stack and structure
The framework, modules and data model the application will move to, chosen against your team skills and roadmap.
Phase plan with rollback per phase
The migration split into releasable slices, each with entry criteria, validation checks and a tested return path.
Data migration and URL strategy
How records move and stay consistent, and how existing links, redirects and search visibility are preserved.
The assessment is useful on its own. Some teams run the migration themselves with the plan in hand; others ask us to lead the first phases and hand over once the pattern is proven on production traffic.
Planning a migration?
A migration assessment takes 2 to 4 weeks and ends with a phase plan, a rollback for each phase and a target structure.
How we migrate: four phases
These four phases describe the whole engagement, from the first inventory to the day the old servers are switched off. Inside the third one, the application itself moves in many smaller slices, each released and validated before the next begins.
PHASE 01
Map
Features, rules, dependencies and data inventoried and verified.
PHASE 02
Plan
Target structure, slices, rollback paths and validation criteria.
PHASE 03
Move
Slices released behind routing or flags, old system still live.
PHASE 04
Retire
Old code, data and infrastructure removed once traffic is gone.
Each slice runs next to the old code before it takes real traffic. A routing layer or feature flags send a small share of users to the new path, results are compared, and traffic grows only when the checks pass. Validating in a parallel environment first is covered in our guide on production and staging parallelization before switching over.
Strangler, extraction or rewrite: which approach?
The migration approach is chosen per part of the application, not once for the whole system. The table compares the options we weigh during the assessment, with the conditions under which each one makes sense.
| Approach | How it works | When it fits | Rollback |
|---|---|---|---|
| Strangler fig | New code takes over routes one by one | Large application that must stay live | Route traffic back to the old path |
| Module extraction | Domains pulled out of the monolith behind interfaces | Monolith with identifiable business domains | Switch the interface back to the old module |
| In-place upgrade | Framework or runtime raised version by version | Structure is sound, only the platform is outdated | Redeploy the previous version |
| Full rewrite | New application built, then switched in one cutover | Small system or no salvageable structure | Hardest: requires parallel running and data sync |
We default to the incremental options because each step is small enough to undo. A full rewrite is recommended only when the old structure has nothing worth keeping, and even then we look for ways to release it in parts. If the backend design itself needs rethinking, our backend development work defines the target before code moves.
Risks and rollback in web migrations
Web migrations fail for a short list of reasons, and all of them can be planned for. Each risk below has an owner, a check and a trigger for rolling back.
Lost business rules
Behaviors nobody documented disappear in the new code. We capture them from logs and code paths, and compare old and new outputs on real requests.
Data drift between old and new systems
Two systems writing the same records diverge quickly. One system owns each record at any time, and reconciliation checks run until the old one is retired.
Broken links and lost search visibility
Changed URLs break bookmarks, partner links and rankings. Every old URL is mapped to its new home with permanent redirects tested before release.
A migration that never finishes
Half-migrated systems double the maintenance load. Each phase has a retirement step, and old code is deleted as soon as traffic leaves it.
The switch for each slice follows a written runbook with go and no-go checks. Our guides on data and application state synchronization at cutover and on preparing a cutover with no service interruption detail what those runbooks contain.
Legacy web migration pricing
Every engagement starts with a diagnosis and ends with a fixed quote. Durations are typical, not promised, and depend heavily on the size of the old system.
| Format | Duration | Price |
|---|---|---|
| Migration assessment | 2 to 4 weeks | Fixed quote after diagnosis |
| Phased migration | 3 to 12 months | Fixed quote after the assessment |
| Post-migration support | Monthly | Monthly fee quoted at handover |
What changes the price: size of the legacy codebase, volume and quality of the data to move, number of integrations and how much of the work your team takes on.
The quote covers senior consultants only, a defined scope and the deliverables of each phase, from the inventory to the retirement of the old code. Hosting for running both systems in parallel, and any new licences, are paid to their providers separately.
Legacy web migration FAQ
Do we have to freeze features during the migration?
No. Phases are small and released alongside normal product work. New features are built on the new structure where it exists, and on the old one only when the area has not moved yet.
Is a full rewrite ever the right choice?
Sometimes, for small systems or code with no reusable structure. For most business applications, an incremental migration delivers value sooner and keeps every step reversible, which a single cutover cannot do.
How do you avoid losing business rules?
By treating the old system as the specification. We inventory rules from code and logs, then compare old and new outputs on real requests before each slice takes full traffic.
Will our search rankings suffer?
Not if URLs are handled properly. Every existing URL is mapped to its new address with a permanent redirect, metadata is carried over, and the redirects are tested before each release.
Can our developers keep working on the old code?
Yes. Your team keeps maintaining the parts that have not moved yet. We agree which areas are frozen for each slice, usually for a few days around its switch, so work does not collide.
What happens to the old system at the end?
It is retired in steps: traffic removed, data archived according to your retention rules, code deleted and infrastructure shut down. Retirement is planned from the start, not left as an optional cleanup.