An inherited system rarely consists only of the thing visible on screen.
There is the architecture somebody meant to build, and there is the second architecture that accumulated through use: spreadsheets beside the database, naming conventions nobody documented, manual checks, old integrations, workarounds, remembered exceptions and one person who knows why a particular step cannot simply be removed.
That second architecture is easy to mistake for mess. Sometimes it is mess. Sometimes it is the only surviving record of what the system actually has to do.
Migration is not moving files
London Drawing provides a straightforward example.
The original problem involved a growing archive of recorded online drawing classes. Moving the video files from Zoom into Vimeo sounded like a migration problem.
But the files themselves were not the valuable unit.
A recording belonged to an event. It needed a title, date, model or subject, description and a place in the website. It also sat inside a future workflow: new classes would continue to happen after the historical archive had been moved.
A successful migration therefore had to preserve relationships between the event, recording, metadata, Vimeo and website.
The eventual structured WordPress/Pods system came from understanding those relationships rather than treating the job as bulk file transfer.
The same applies to websites
The old Niche Clever site went through exactly this kind of treatment during this rebuild.
It contained dozens of pages organised around Support, Publishing, Web and Marketing. Reproducing that menu in a newer theme would have been an easy migration.
It would also have preserved the wrong information architecture.
The useful work was to audit the material as a corpus: identify language worth preserving, project fragments worth verifying, outdated chronology that should not migrate, test artefacts that should disappear, and ideas that now belong inside a different structure.
The old site was a source, not a blueprint for its successor.
The dangerous convenience of a blank slate
A new build can feel liberating because you no longer have to understand the old mess.
But “start again” can also be a way of avoiding the difficult part.
Questions worth answering first include:
- What data or content is unique to the current system?
- Which workflow exists only because people have adapted around the software?
- What external services depend on it?
- Who owns the accounts and credentials?
- Which URLs, analytics history or user expectations have continuity value?
- What permissions are implicit today?
- Which odd behaviour is a bug and which is supporting a real exception?
- What does the client need to be able to do independently after the migration?
Those questions change the rebuild.
Sometimes they change the decision to rebuild at all.
Continuity is a design requirement
Passport Systems is a useful example from 2020.
The move into WordPress was not merely a redesign. The migration had to preserve content, gated workflows, analytics continuity, domain arrangements and the client’s ability to operate the new environment.
Training and handover were therefore part of the technical solution, not an afterthought once the build was finished.
A migration is not complete simply because the new site renders correctly on launch day. The people who inherit it need enough understanding and ownership to continue.
Version history is evidence
Long-running products create another archaeology problem: the current version can make earlier decisions hard to see.
Trigger SMARTS has gone through three successive working versions, each shaped by real deployment and configuration experience rather than a single planned build. The current version is more explicit about shared entities and hotel-scoped structure partly because earlier operational use exposed what needed to be modelled more carefully.
That history is valuable. A redesign should learn from it without pretending every behaviour of the predecessor deserves to survive.
The task is to distinguish accumulated knowledge from accumulated accident.
AI makes this both easier and more dangerous
Current AI and coding tools are extremely good at accelerating this kind of discovery.
They can inspect repositories, compare files, summarise documentation, trace names across code, extract candidate structures and help reconstruct a system much faster than manual reading alone.
They can also produce a persuasive explanation before the evidence is complete.
So the same rule applies: generated reconstruction is a proposal until it has been checked against the underlying system and artefacts. Fast understanding is useful. False closure is not.
Before the specification
This is why I increasingly treat a current-state model as a legitimate deliverable in its own right, not just a preliminary step to be rushed through.
Before deciding what to build, it may be worth producing:
- a system inventory;
- a dependency map;
- a content model;
- an account/ownership register;
- a workflow map;
- migration requirements;
- a list of unresolved questions;
- a bounded prototype of the proposed successor.
That work can feel slower than immediately designing the new interface.
In practice it often removes rework later, because the new system is being built from what exists rather than from what everybody vaguely remembers exists.
Rebuilding should follow understanding, not substitute for it.
Related
London Drawing and Trigger SMARTS both went through this kind of discovery before anything was rebuilt. Method sets out where this stage sits in the wider sequence of work.