S.01 / LEGACY
I modernize legacy platforms and applications in phases: I work out what they do, preserve the data, URLs and processes that have value, and replace the rest without switching off what works.
02 / PROBLEM
Modernizing doesn’t mean rewriting everything. It means deciding what deserves to survive.
A legacy system is usually two things at once: where the company’s accumulated value lives (data, content, rankings, integrations) and the reason every change costs three times as much.
A full rewrite promises to clean everything up in one go and almost always underestimates what the old system did without anyone knowing. What works is a phased transition: understand first, then preserve and isolate, and only then migrate and rebuild, verifying at every step.
03 / SIGNALS
One on its own may just be maintenance. Several at once usually mean the system is already holding the company back.
04 / FIT
When the old system holds value and at the same time stops you building what comes next.
05 / WHAT I BUILD
Historical data, URLs, SEO, integrations and processes: each piece with its own transition strategy.
ETL processes on the real production dump into a normalised model, without losing content along the way.
EvidenceRocio.com
Every old URL redirects to its new destination in a single hop, based on each item’s legacy identifier.
EvidenceRocio.com
A structure that matches what users search for today, without giving up the authority the domain already had.
Each external provider sits behind an internal interface: swapping it tomorrow doesn’t mean touching the rest of the system.
EvidenceRocio.com
The new tools are designed around how the team works today, not how the old system forced it to work. At Rocio.com one person approves everything that gets published, and the panel was built to make that sustainable.
EvidenceRocio.com
Tests that check every published route resolves, redirects arrive in one hop and nothing unconfirmed gets published.
06 / ARCHITECTURE
Order matters: you don’t migrate what you haven’t understood or switch off what you haven’t verified.
What the system really does, what data it holds and who depends on it.
What works and has value is protected before anything is touched.
Integrations and dependencies behind internal contracts.
Data into the new model with repeatable processes.
In phases, starting with what blocks the most.
Nothing counts as migrated until it’s been checked.
07 / DATA MIGRATION
Old databases, validation and reconciliation, phased migration. The most underestimated part of any modernization.
An inventory of what’s there: tables, fields that are actually used, fields repurposed for something else and data that only lives in loose files.
Work is done on the real production dump, not a sample copy. The odd data only shows up in the real data.
The migration is a process that can be rerun end to end, not a one-off manual run. It’s rehearsed as many times as needed.
Every record keeps its old identifier, so it can be traced back to its source and its URLs redirected.
Counts and totals are reconciled between source and destination: if they don’t match, it isn’t migrated.
In phases, with the old system in service until the new one is verified. No blackouts on a date fixed blindly.
If the system you’re modernizing issues invoices in Spain, check how it fits with Verifactu: I cover it in Verifactu API: how to integrate Verifactu into your software or ERP.
08 / KEEP / DROP
Half the work of a modernization is this list.
09 / EVIDENCE
An archive going back to 1992, trapped in WordPress, rebuilt as its own system.
Editorial platform
A full migration from a WordPress site around 15 years old without losing content or links.
STACK Nuxt / Vue / MySQL
Case study: Rocio.com10 / DON'T REBUILD
An old system that works and can be maintained isn’t a problem. It’s an asset.
11 / QUESTIONS
Moving information from one system to another: extracting it from the source, transforming it into the new model and loading it into the destination, checking that nothing is lost or altered. When the source is an old database, the hard part is the transformation, not the copy.
They’re two levels of the same job. Database migration changes where and how the data is stored; application migration changes the system that uses it. In a modernization they usually go together, but they’re planned and verified separately.
No. Modernizing means deciding what to keep, what to isolate, what to migrate and what to rebuild. Sometimes replacing one piece and leaving the rest is enough; other times you need a new system, but built on the previous one’s data and URLs.
A system you can’t evolve isn’t yoursThe risk is real and it’s managed: every old URL with traffic or links gets a 301 redirect to its new destination, in a single hop, checked by tests.
With repeatable ETL processes on the real production dump, not an idealised copy. At Rocio.com an archive going back to 1992, with 102 tables and 320,093 rows of metadata, was transformed into a normalised model.
Read the Rocio.com case studyYes: the transition is planned in phases so the old system keeps running while the new one is built and verified. The final switch happens when the checks allow it, not on a date fixed blindly.
12 / SAME SYSTEM
A business problem rarely lives in a single piece. These usually appear in the same project.
Tell me what it does, what data it holds, what depends on it and what can’t be lost. We start by understanding it.