I had a similar situation migrating to a new version of a dashboard -- it was highly unstable for a little while, but the UI was so improved that most users still preferred to use it, although both versions needed to be available. From a data standpoint, @JanVladimirMostert is absolutely correct about versioning your API (starting with a /v1/ route right from the get-go is a great practice), but sometimes you need to maintain, or at least serve, two radically different front-ends after a redesign, which is what I think you may be talking about. I used two Git repos, one for the legacy version and one for the new version. I use Codeship, but with most CLI tools you can have it pull from these repos during build automatically, so it really doesn't add any overhead to the deploy. Then in the new version, I had a banner up at the top for a few weeks that let the user switch back to the legacy version. Two repos might seem heavy-handed, but there's really no drawback, and if you're talking about radically different codebases (in my case it was a simple bootstrap-ajax front-end versus a whole EmberJS SPA) it really makes sense.