Every list starts as a convenience. The question is what happens on the day someone needs a second table.
Nobody sets out to build a database in SharePoint. It happens because a list is the fastest way to stop a spreadsheet being emailed around, and stopping that is a genuine win. The list solves the problem in an afternoon and everyone moves on.
The trouble arrives later, and it always arrives the same way: someone needs a second list that refers to the first one.
A lookup column is not a foreign key. Nothing stops a referenced item being deleted. There is no transaction spanning the two lists, so a flow that writes to both can succeed at one and fail at the other, leaving a state no one designed. Permissions were built for documents, so tightening access to a few rows means item-level permissions, which is the point where administration quietly becomes somebody’s part-time job.
My rule is a single question: does anything reference this? One flat list of records that nothing else points at can live in SharePoint indefinitely, and moving it would be waste. The moment a second list needs to reference the first, that is a relational model, and it belongs in Dataverse.
Migrating a mature list is not a data move. It is a data move plus every flow, every form, and every report that touched it — and the reports are the ones you find last. Deciding correctly at list number two costs an hour. Deciding at list number six costs a project.
SharePoint is not the mistake. Ignoring the moment it stopped being the right tool is.
If this matched a problem you're sitting on, or contradicted your experience, that's worth an email either way.