For 15+ years my co-workers and I have supported a single-tenant system. It was originally designed for on-prem installation, which is why we could only have one client per database. As we moved into offering our software as SaaS, it was exceptionally helpful to have the ability to spin up a new SQL instance as growth required or when we wanted to isolate a high-load customer. We went from dozens of SaaS customers, to hundreds, to thousands during my time here. It was also helpful to be able to restore Acme's data to an earlier point in time without affecting any other customers.
To address schema drift, all of our installation/upgrade scripts had to be written in an idempotent* manner so as to allow customers to upgrade at their own pace. This was great at first, but the complexities involved in making such a script took more and more development time, and caused each upgrade to take longer and longer (current upgrade script is about 40mb). It has recently been taking up to two weeks to fully upgrade all databases.
We've just started a rewrite of the software from the ground up, and we're writing it as multi-tenanted with a deltas-only upgrade process. We chose multi-tenanted primarily for cost savings on SQL licenses and an elimination of the costly switchboard process that the UI has to use to connect to the correct database.
I would enjoy hearing from someone with the reverse story - a long-term single-tenanted system that is being rewritten as multi-tenanted.
[edited for clarity & spelling]
*idempotent = every execution of the same script results in the same outcome. If a new column was added in release 3.5, a second execution of the 3.5 script would see that the column existed and bypass that step in the process (thus bypassing a SQL error). Also, the same script would upgrade any database to 3.5, regardless of whether it started as version 2.3, 2.9, or 3.2.