It's a very expensive move that I don't think people consider when choosing this kind of solution.
It's a very expensive move that I don't think people consider when choosing this kind of solution.
If you're concerned that a service might shut down then you need to architect your application with that in mind, in which case how much of a rewrite is necessary is essentially up to you. Usually there's a tradeoff between going fast and engineering solutions that will work in the long term. Most startups never get to the stage where they need to swap out a service, so closely tying your application to a service is probably OK at the start.
If the service that shuts down is reasonably popular though it's likely there'll be very little code to change. API-compatible competitors will pop up to replace it. It happened when Parse closed.