In practice, most first year businesses end up on a small number of widely used options. A site on a mainstream builder or content system. Analytics from the major provider because that is what everything else connects to. An email platform sized to a list you do not have yet. A payment processor that bundles the merchant account. Accounting connected to the bank. None of that is exotic, and the reason is deliberate: established tools have documentation, support communities, existing integrations, and the likelihood of still being there in three years.
The selection criteria matter more than the specific names, because the names change. Can you get your data out in a standard format without asking anybody. Does it connect to the other things you use. Does the pricing still make sense at three times your size. Can you operate it yourself after a walkthrough. And has it existed long enough that a search for a problem returns an answer rather than an empty forum thread.
There are places where a newer or more specialised tool is the right call, and they are identifiable. Something that does a job the established option genuinely cannot, where that capability affects what your customers experience. Those are worth the risk. Infrastructure is not, which is why the recommendation for the foundational layer is almost always the dull, obvious, widely used thing.
If you already use something and it works, that is usually a reason to keep it. Migration costs time and introduces errors, and a tool you know how to operate has value that does not appear in a feature comparison.
Where a genuine recommendation matters is in the foundational layer, and there the advice is consistent: choose the widely used option rather than the interesting one. Documentation exists, problems have been solved publicly, integrations are already built, and the product will probably still exist in three years. Novelty carries real risk in the pieces you cannot easily replace, and almost none in the pieces you can.
Where you already use something that works, that is usually a reason to keep it rather than a starting point for migration. Switching costs time, introduces errors, and discards the familiarity you have built, and a tool you can operate confidently has value that never appears in a feature comparison. The question worth asking is what specifically is failing, and if the answer is nothing, the answer to the migration is also nothing.