Esta página está en inglés. Aún no hay traducción; la URL canónica es la inglesa. Abrir la página en inglés
Legacy modernization
How to modernize a live content platform without switching it off
The migrations that survive are boring: they keep the public URL green, they keep editors publishing, and they move risk into a pipeline you can measure. The migrations that become folklore are the Friday cut-overs. I have worked the first kind — Sitecore to XM Cloud with a headless Next.js front, Umbraco and Magento toward Contentful and Vercel. This is the method, not a vendor pitch.
Inventory truths, not templates
Start with what must remain true on day one of any public switch: URL map, metadata, canonicals, previews, authentication to private content, and the integrations that fire on publish. Templates are the least important artefact. They will be redrawn. URLs and content relationships are the expensive ones.
Count content types by how they are reused, not by how the old tree was nested. A 1:1 clone of a twelve-year CMS folder structure is how you pay for a new stack and keep the old problems.
Design the destination model before you write the importer
Editors will live in the new model for years. If the importer is easier when every field becomes rich text, the importer is lying. Name an owner for each content type. Unowned fields become dump zones.
Preview and localization are part of the model, not a phase-two surprise. Headless stacks fail in production when preview is 'we will figure it out'.
Automate the move, then measure loss
A one-off script that 'mostly worked on staging' is not a migration. You want a pipeline you can re-run, with a report: items in, items out, fields dropped, references broken. Re-running is how you absorb the fact that editors will keep publishing in the old system until the last day.
Integrity is a product requirement. I have spent assignments on nothing more glamorous than making sure the data that arrives in the new CMS is the data the business thinks it published.
Strangle, do not flip
Put the new front on a subset of paths or traffic. Keep the old system answering everything you have not proven. Redirects are a first-class artefact, not a spreadsheet someone will 'add later'.
Rollback should be a routing change. If rollback is 'restore the database and pray the CDN cache expires', you do not have a plan.
Do not schedule a full cut-over because a programme plan has a red milestone. Schedule it because the mismatch report is empty enough that the remaining issues are editorial, not structural.
When not to modernize
If the constraint is delivery process, missing tests, or an absent product owner, a new CMS is a very expensive way to keep those constraints. Stay, contain, and fix the actual bottleneck. Stack age is a feeling. Lead time and incident rate are not.
Takeaways
- Migrate URLs, relationships, and editor workflow before you migrate chrome.
- Re-runnable pipelines with loss reports beat heroic one-off scripts.
- Shadow the new front; keep rollback as routing.
- Do not clone the old tree into the new CMS out of fear.
- Refuse a rewrite when the stack is not the constraint.