There are many things to consider when you are migrating from one version of Drupal to another. Some of these may affect your Acquia Cloud environment.
The following practices describe the things you should do (or not do) as you migrate your website's Drupal version.
- Share the same load balancers
If you share the same load balancers, no DNS change is needed and therefore no propagation delay. During the cutover, the virtual host(s) needs to be moved from the older Drupal website to the new Drupal website on the Insight Cloud > Domains page. Doing this through the Insight Cloud UI could take up to five minutes per subdomain (1-2 minutes to remove the vhost, 1-2 minutes more to add the vhost). There could be downtime, especially if there are multiple subdomains involved.
- Share the same staging and development servers
In general, there shouldn't be any problems with this.
- Consider your sizing and architecture needs for the new version
If you are doing a complete rebuild/migration (which most Drupal upgrades are), it may be beneficial to load test the existing Drupal website on a clone of the production environment to establish a baseline. Then, test the new installation on the same environment (with as similar a test as possible) to see how they compare from a performance standpoint.
- Consider using separate web and database servers for the new production Drupal website
You should do this instead of having both docroots share the same production instances. Cutting over usually impacts performance; isolating these docroots on their own servers minimizes risks from cold caches building.
- Conduct performance testing
Load testing is a critical part of switching to the new version. This can find potential outage-causing issues before the website is visible to users.
- Don't develop the new Drupal website in the same site group as the old Drupal installation
Doing so adds significant risk to rollback. If you need to roll back, you will need a database restore operation, which could take 30 minutes (or more) depending on its size and the amount of backend traffic hitting Drupal. This can affect development as well as production.
There are several ways that you can move forward, each with some pros and cons:
- Adding another docroot to the current servers
This option allows you to spin up your newer Drupal website and then spin down the old one afterwards.
- Completely isolated environments, files, databases; no accidents with dragging
- No extra costs to client
- Easy DNS rollback in case of issues preventing launch
- Minimal hardware impact as new installation has no traffic
- Proc count for additional setup divided amongst docroots, potentially impairing the older Drupal installation
- Adding an entirely new production hardware copy
This is an entirely new environment, with no carryover of code, ensuring that nothing gets broken in update, but requires other work.
- Very isolated setup, no issues with accidental dragging.
- Rollback is a DNS change.
- Costs to client are at least one week's worth of the production hardware sizing.
- Using a new branch on the old Drupal docroot
Check out a clean version of the website on Dev or Stage. This is essentially a clean version, which can then be upgraded.
- Minimal involvement of Acquia operations staff
- Easy for client to manage
- No extra costs for client
- Rollback is a little more tricky:
- Restore DB
- Revert to old Drupal tag
- Drag files from an environment where they were copied to before new version's launch
- Repo bloat
- High potential for accidental code, database, or file dragging issues