The data model decides year two
Almost every rewrite we are called into has the same origin story. The first version shipped fast, the business changed, and the data model did not change with it. Two years later a table called items holds four different kinds of thing, half the columns are nullable because they only apply to one of them, and every new feature needs a special case.
Names in the code match names in the room
The cheapest correction is the one made before a migration exists. We spend the first days of an engagement writing down what the business actually does - in its own vocabulary - and only then decide what the software should be. If operations call it a consignment, the table is not called shipment2.
Boundaries follow the business, not the framework
Services split where the business splits. That is what makes them independently deployable later, and it is why a well-drawn system can absorb a new product line as configuration rather than as a rewrite.
If you cannot draw the system on one page, nobody on the team shares the same picture of it.