Legacy Modernization
In development. Taking enquiries.
- ·Old sites and codebases moved onto a stack that can be maintained, with the content carried across intact.
- ·The migration path is scripted and repeatable, which is what makes 20 sites viable instead of 2.
| Becomes live when | One migration a stranger can open is published: the site before, the site after, and the script that carried the content across. The programme behind this service runs on client sites that stay private. |
| Built with | WordPress · Next.js · Payload CMS · Puppeteer · Claude API |
| Delivered by | refactor-specialist · · data-engineer |
| Skills used | data-model · spec-it |
What this involves
Legacy modernization is worth doing when the cost of maintaining a system exceeds the cost of moving it, and not before. A system that is old and boring and works is not a modernization candidate; a system that blocks every new feature and cannot be safely deployed is one, and telling them apart is the first hour of the engagement rather than an upsell.
The approach is incremental rather than a rewrite. The current programme at Lift Legal Marketing covers 20+ legacy WordPress and Divi sites, and the reason that number is viable at all is that the migration path is scripted and repeatable. A migration performed by hand does not scale past about two sites; one that is scripted scales to twenty because each additional site costs a run rather than a project.
Content is carried across by AI-powered extraction pipelines rather than manual copy and paste, which is what keeps the content layer intact when the presentation layer changes underneath it.
This site is its own worked example of the hardest part of the discipline, which is deciding what not to save. The 1.0 build here included a 25,800-line 2D game world. It was audited rather than patched: the content was salvaged, the code was not, and the post-mortem is published in the public repo as docs/WORLD-AUDIT.md instead of being quietly deleted.
A migration performed by hand does not scale past about two sites. One that is scripted scales to twenty, because each additional site costs a run rather than a project.
How the work runs
1. Discovery
We agree what the project has to achieve, what it must not break, and how we will both know it worked, before any code is written.
2. Build
The work is built with an AI agent as the working partner and a human reviewing every change before it lands. You get commits you can read rather than a status update.
3. Review
You review running software at each milestone, not a screenshot of it, and the next milestone absorbs what you send back.
4. Launch
We deploy to production with checks in the pipeline and alerting that reaches a human, and you hold the repository and the infrastructure accounts.
Questions people actually ask
Will modernization take my current system offline?
It should not, and a phased approach is how that is achieved: the existing system stays live while new functionality is built alongside it and cut over piece by piece. The risk that actually bites is not downtime during the cutover but a rollback path nobody tested, so the rollback is worth agreeing before the first phase ships.
How is data migration handled safely?
With a verified backup, a validation script that compares source and destination, and a tested rollback, in that order and before anything is written. On One Nadela Ops the schema is managed as versioned migrations rather than hand-applied changes, which is what makes a rollback an operation rather than an improvisation.
How long does modernizing a legacy system take?
It scales with the number of distinct systems rather than with the total line count, which is why a scripted path matters more than raw speed. No range is quoted here because none has been measured across enough engagements to state honestly; a written scope gets a date with its assumptions attached instead.
When is the honest answer that a system should be retired instead of modernized?
When the content is worth keeping and the code is not. That is the call made on this site's own 1.0 game world: 25,800 lines were retired, the content they carried was salvaged into the current build, and the reasoning was published in the repo as docs/WORLD-AUDIT.md so the decision could be argued with rather than just announced.