Migrating a Large SaaS to Drupal 8: A Web Service Approach
Note to reviewer: Below is an outline of the presentation details. Each point will be accompanied by a corresponding slide that expands on the material presented.
* Migrating a SaaS product to Drupal 8 is extremely challenging. Mainly due to the fact that we can't take the "site offline" while the entire site is ported over. The site still needs to provide service to clients, and new features and bug fixes still need to be added, and in our case, the migration *must* start because Drupal 6 is end of life (even though 3rd party security support is still being provided). Knowing this, some sort of "migration" strategy must be devised in order facilitate the transition.
* We have developed a migration strategy that hopefully will serve useful. While it is not the *only* solution to migrate, we feel it is a strong one, and might provide inspiration for those who find themselves in a similar position.
* By leveraging web services (specifically REST), functionality can be ported over in a piecemeal fashion. The process is as follows:
1) create a REST webservice on the legacy site that fulfills the functionality being ported.
2) create the new "front-end" on Drupal 8 that consumes the REST service and provides the new interface for the functionality being ported.
3) After ensuring the functionality works as intended, recreate the REST service (that currently lives on legacy), on Drupal 8 and change the "front-end" to point to the new service location.
In a nutshell: create web service on old site, then consume service on new site, then recreate service on new site.
* Some benefits of this approach:
- Isolated pieces of functionality can be ported over one at a time. By leveraging the web services paradigm, the legacy site becomes a temporary "service provider" of the new site. This allows for the recreation of a new front-end and still have the old legacy site in operation while the web services are being created.
- Exposing your functionality as services to end users. Clients can now consume web services just as you are, and provide new a unique ways of interacting with your product.
* As with most good solutions, there are definitely challenges. A few that we've identified so far:
- Migrating themes. Our SaaS services many clients, each with their own custom theme, and each theme containing custom logic. We cannot start providing UI functionality via Drupal 8 until we've migrated all the themes over to Drupal 8.
- Providing a uniform URL for accessing your site. Due to the fact that two different frameworks are powering your site, some considerations will have to be taken into account when routing incoming requests. We are using Nginx for routing based on top level paths. For example: www.my-site.com/6/my-page gets routed to the Drupal 6 box, while www.my-site.com/8/my-page gets routed to the Drupal 8 box. Additionally, URL link generation must be modified to conform with any standards set in place.
- User provisioning. Eventually, functionality will be ported that requires interaction with users. Having competing frameworks dealing with user data can be complicated. A choice must be made in choosing what location is the "authoritative" user information source, and ensure that all new functionality uses that. Thankfully, in Drupal 8, it's easy to swap in new service definitions that deal with user data to make this transition a little easier. Ultimately, all user data will be transitioned to Drupal 8 once the migration is complete.
* By embracing the web services paradigm, it's possible to setup a scenario where a large scale migration of functionality is possible without the need to turn off the existing product or halt new development. The additional benefits of providing functionality via web services also makes this solution a very compelling one. We hope that at the very least, our approach will serve as inspiration to what we consider a very challenging but rewarding technical hurdle.