When an organisation decides to intervene in its technology asset, a fear appears before any other. It is not always verbalised. Sometimes it disguises itself as a technical objection, as concern about deadlines, as an argument about cost. But beneath all of that there is a question someone is asking in silence: what are they going to destroy?
It is a legitimate fear. And it deserves an honest answer, not reassurance.
Yes: transforming implies demolishing. There are things that must disappear. Denying that would be condescending. The problem is not the fear of demolition. The problem is demolition without judgement.
What happens when there is no map
Organisations that transform their technology without a prior reading do not avoid demolition. They do it blind. They demolish what was wrong, yes, but also what was working. They lose domain knowledge that took years to embed in the system. They break dependencies that nobody had documented. And when the new system is running, they discover there are behaviours of the old system that nobody could explain but the business needed.
Transformation without a prior reading is not braver than transformation with judgement. It is more expensive, slower and more destructive. Not because the intention is bad, but because it acts on an image of the system that is not the real system.
Starting from scratch is not a real option
There is a recurring fantasy in technology transformation processes: the blank slate. Throw everything out and start from scratch, without the weight of previous decisions, without accumulated debt, without inherited constraints.
It is a fantasy because it ignores what a production system contains besides code: years of domain knowledge embedded in its logic, edge cases resolved that were never documented, business rules that live in the system because nobody found another place to put them. A new system on day one has none of that.
Starting from scratch is almost never the right decision. Not out of sentimental respect for past work, but out of rigorous technical economy. The criterion is not to preserve what is old: it is to identify what of the old has real value and how it is transferred, reused or re-engineered into the new.
Demolishing with judgement
What Rugaro calls demolishing with judgement is a process of rigorous discrimination: component by component, dependency by dependency, the state of each part of the system is evaluated and the treatment it deserves is determined.
Some components are preserved without intervention because they work and the cost of replacing them is not justified. Others are re-engineered: the logic they contain has value, but the container does not. Others are migrated: the knowledge is transferred to a new system with better architecture. Others are retired: they have served their purpose, they accumulate more risk than value, and their disappearance is an act of governance, not destruction.
And some are kept alongside the new during a transition period, because abrupt replacement would destroy more than it resolves. Hybrid systems, transition roles, the temporary coexistence of old and new are not symptoms of indecision: they are part of the craft of those who know how to transform without demolishing what still serves.
The fear is right. The blindness is not.
The fear that an external intervention will destroy something of value is a reasonable fear. It is grounded in real experience: consultancies that came in with a generic model, readings that did not read the real system, transformations that left a trail of lost knowledge and demoralised teams.
Rugaro does not come in to deny that fear. It comes in to resolve it in the only way that makes sense: reading before intervening, distinguishing before recommending, proposing a sequence that preserves what has value while transforming what must change.
Transforming is demolishing. But demolishing with a map in hand is not the same as demolishing blind. The difference between the two is exactly what the ASSAY produces.