Drupal 6 site owners are facing a difficult question: What to do with a web technology that is no longer going to be supported? As an organization that specializes in Drupal support and migrations, we have been talking with diverse organizations about their options, their budgets and, frankly, how their websites fits into their operations. We lay out technical alternatives, business case studies and the decision factors for Drupal 6 site owners.
With the release of Drupal 8, Drupal 6 will eventually no longer receive security updates. The viable alternatives are not only dictated by the technology, but also by:
- Business Use of the Website
How integral is the site to the main business? If the site is hacked, is downtime or data loss acceptable?
- Brochure or E-Commerce
Decisions get much more complicated when money is involved.
Some client audiences effectively dictate that a site is secure, e.g. college students who might want to hack their school’s website.
- Value of the Website to the Client
To some, the website is the business. To others, it is a necessary touchstone, but not critical.
- Original Development Cost
Although this is a sunk cost, if the cost of an upgrade exceeds the original development cost, the project could be a non-starter.
At Monarch Digital, we are most successful when we learn the success factors of our customers’ businesses, making the best technology recommendations for each situation. This entire article came from our matchmaking efforts with current customers resulting in the diverse solution sets for our client community.
This is not necessarily an exclusive list. I have culled this list from real discussions I’ve had with my clients.
- Yes, we literally mean not make any changes or upgrades.
If we would have developed a website with a home-grown CMS, we would not have had the luxury of the Drupal Security Team issuing regular security updates taken from submissions from a worldwide community.
Now that you have a Drupal site, however, it is relatively easy to determine if your site is Drupal and it’s version. You must assume that you would be able to search for any Drupal 6 hacks on the internet and then search for a site that is vulnerable. So, you are probably even more vulnerable than a privately-developed CMS.
Small sites especially believe in security-through-obscurity. With so many bigger, high value sites, who would attack my site? This is not really any security at all.
If we have a client who wants to take this approach, we (obviously) stop applying security updates after February 2016 and we do regular, automated off-site backups. We must be prepared to restore and patch their hacked site.
How long will a vendor like Monarch continue to be on call for this relatively dirty job? It depends. Monarch “supports” Drupal 4 and 5 sites this way. However, with sites that old, they really aren’t Drupal anymore; they are just php sites.
There has been talk in the Drupal community about having a Drupal 6 LTS (Long Term Support) version. To date, this seems more like a dream than a real proposal.
Try to Support Drupal 6
- Support that will not be guided by core Drupal.
The next step up in providing more proactive support for a D6 site is to have your Drupal vendor actively participate in Drupal 6 support forums and social media along with scan the web for potential exposures and patch them on your site.
Even using Drupal experts, this attempt at supporting Drupal 6 could prevent some security intrusions, but it is only slightly better than waiting for the site to be hacked.
At Monarch, we would ask for a monthly retainer to finance the research in potential Drupal 6 exposures. General client reaction is that they would prefer to apply these funds to a migration off Drupal 6.
Redevelop in a New Technology
- There are other CMS solutions out there.
As any move away from Drupal 6 is more of a redevelopment effort than a push-a-button-and-you’re-good migration, this is a good time to consider all alternatives. These could include:
A CMS due to its simplicity and popularity with designers.
A fork of Drupal, providing long-term Drupal 7 functionality.
Squarespace, Wix, Weebly.
Proprietary (licensed) solutions
My personal experience is that once a client becomes used to open source, they find it difficult to again pay software licensing fees.
Moving away from the Drupal platform is easier for brochure sites. There are potentially fewer unique functions and extensions that the client would have to reproduce. However, sites with more unique functionality, e-commerce or interfaces to external systems are more difficult to move out of the Drupal world.
Many Drupal site owners and content manager don’t want to learn a new technology and new interface. The Drupal interface is not perfect, but non-technical users have gotten used to it and don’t want to start a learning curve from scratch.
Migrate to Drupal 8 Now
- Realizing there is no "upgrade" button.
At this writing (1Q 2016), Drupal 8 is still brand new. Drupal 8 talent across the world does not yet have extensive experience with it yet. Even more importantly, the contributed module ecosystem is lagging behind. Although you can build more site with only Drupal 8 and no contributed modules, most Drupal 6 sites have come to rely on functionality provided exclusively by contributed modules.
Using modules like Drupal Upgrade Status module, anyone can quickly see if, or more accurately how much, functionality would be missing in a Drupal 8 site. Using this inventory, the first question is whether the functionality in the contributed module is still required. If so, your Drupal vendor has several options:
Convert the contributed module to Drupal 8. “Convert” is probably the wrong word here. To achieve all of the technical advantages of Drupal 8, a developer essentially has to re-develop the contributed module to perform similar functionality. Not an inexpensive endeavor.
Besides the cost, the Drupal developer could essentially become the maintainer of this module. Although an honor, the long-term work involved in addressing issues reported by the community can be a big commitment.
Write a custom module to perform just the required functionality. This option could be somewhat less expensive, but you will not receive any further updates from the community.
In any case, the client is having to pay a high price in terms of developer time to recreate functionality that they already have. Some organizations have bought into contributing back to an open source project, but many must pay very close attention to the bottom line and simply can’t be that magnanimous.
Keep D6 Until D8 Modules Are Ready
- Not all popular contributed modules are production ready.
I am personally assuming that the Drupal 8 contributed module ecosystem will become much more robust over time. We experienced the same delay when Drupal 7 was released. If I had to guess, I might say that the essential contributed modules would be available 4Q 2016 or 1Q 2017.
The obvious problem with this plan is that your site is exposed to potential hacks for the better part of 2016. This should be unacceptable for e-commerce and many other sites.
Migrate to Drupal 7 Now
- Most of the contributed modules you'll need are production ready for Drupal 7 now.
The path from Drupal 6 to Drupal 7 is a known commodity. Although it is still a “migration” and not a “conversion” per se, this would be a safer and less expensive alternative.
I assume that the total cost of a Drupal 7 conversion plus a latter Drupal 8 conversion would probably be less than a full Drupal 8 conversion now. I could be wrong.
Although they may not be able to be used without modification, there is also the opportunity to reuse the migration scripts for the two migrations.
For those smaller and cash-strapped organizations, these two migrations are truly two redevelopment efforts.
Single Deveoper Approach
- Reduce project management costs by not using the whole team.
For large projects like this, clients incur project management and testing overhead that an independent contractor would avoid. When multiple developers are involved, the project will be completed more quickly, but the burn rate of the project is much faster.
Organizations like ours have been trying to dedicate a single developer to these projects to eliminate the project management overhead. We sequentially work on the project in 40 to 80 hour time boxes with very well defined deliverables. At the end of each deliverable, we work with the client to identify the next step and how much client personnel might be able to perform.
For example, instead of writing a migration script for a contained content type, the client might opt to manually bring that content over. Some clients have opted to avoid the cost of converting their existing theme in favor of a free or purchased theme.
In addition to decreasing the total cost of the project, this approach also spreads the cost of the migration over time. The flip side of that coin is that these single-developer projects take more time to complete, leaving the client’s Drupal 6 site without security updates for a longer period of time.
To come up with the best solution, I have found that I must lay out all of the technical options above and try on the options with the organization’s unique needs and limitations. Here are some business scenarios I have encountered. I’m hoping that one of these case studies might mirror your situation.
"Cash-strapped Brochure Website"
I have worked with several small businesses and nonprofits that are not flush with money. Their web site is important, but if it was down for a day, they could live with the outage. They would love to have more functionality added and have the theme refreshed, but the site is worked adequately today.
There is only one real alternative for these sites: provide backups and restore/remediation service as needed. Most of these sites are small without huge visibility. As their Drupal support provider, we need to spell out the risks, but, if they accept the risks, we point an availability checker at their site and assure that we continue to have up to date backups.
"Non-mission-critical Brochure Website"
We have some small businesses that use their brochure web site as part of their sales process, but it is definitely not critical to closing a new sale. In addition, the decision-makers of these organizations are often not very technically oriented. It would be difficult to convince them to make an investment without material functionality improvements. Because they don’t especially like technology, the less money they spend on technology, the better.
I have found that these organizations will opt for one of three alternatives:
Like the first scenario, these organizations could just assume the risk and have their vendor regularly back up the site and be prepared to restore and plug the latest security hole.
Alternatively, some businesses in this category prefer to be more proactive and have a Drupal vendor seek out and apply updates in advance of being hacked. We, as the Drupal support vendor must clearly communicate that this program is just slightly better than nothing.
If the site is simple enough and a specific visual look is not required, the site could be recreated in an all-in-one technology solution, like Squarespace. This alternative is less expensive than a Drupal conversion.
"Medium/Large Brochure Website"
Next, we’ll jump to a medium-to-larger brochure site. Just due to the size and importance of the site to the organization, staying on Drupal 6 in any form is not acceptable. Also, these organizations are usually better capitalized than the small organizations; they have been budgeting for a larger migration.
Even larger brochure sites are good candidates for a true D6-to-D8 conversion early in the Drupal 8 life cycle. The number of contributed modules needed is limited. The number of custom modules is relatively small. (If one of these sites use many Drupal 6 contributed modules, migrating only to Drupal 7 might be the best choice for now.)
The wild card is the theme. Clients see this migration as an opportunity to refresh the theme while the budget purse strings are open.
"Medium/Large E-Commerce Website"
The addition of e-commerce again eliminates Drupal 6 from consideration. The site owners will have to assume liability for any credit card fraud.
At least in most of 2016, migrating to Drupal 8 will not be feasible. Early on, only the base Ubercart module had a Drupal 8 version. Virtually none of the Ubercart add on modules were available in D8. Drupal Commerce had no Drupal 8 version.
These organizations usually choose a traditional D6-to-D7 migration. They prefer to get the project completed as quickly after Drupal 6 end-of-life as possible.
"Small E-Commerce Website"
A small e-commerce site evaluates their migration options similarly to a larger e-commerce website. Staying on D6 is not an option. Moving to Drupal 8 is too costly now. The biggest difference is that cost is much more of an issue.
For that reason, these site owners prefer the single developer approach outlined above. These organizations are not as time sensitive. Lopping off 20%+ for project overhead is a huge selling point. Spreading out the cost of the migration helps limited cash flow.
"Small Brochure Website"
The only category left is just a small brochure site where the organization has some budget and the site is important to them. Drupal 6 to Drupal 8 is probably too expensive for the near term (2016).
A migration to Drupal 7 using our single developer approach is a good option.
Redeveloping the site in an alternative technology, like Wordpress or Squarespace, is also an option. Often, content managers don’t want to re-learn a new technology. Although a Drupal 7 migration is effectively redevelopment, the site owner often feels better at migrating their content as opposed to starting all over again in a new technology.
Obviously, the cost of doing nothing and staying on D6 is least expensive.
Migrating to Drupal 7 is next. Even going through a Drupal 8 conversion later promises to be less expensive that a D6-to-D8 conversion.
Drupal 6 to Drupal 8 is the high end of the cost curve.
As Drupal 8 was released most recently, it will last the longest. D8 will not be deprecated until Drupal 10 (!) is released.
Drupal 7 will continue to have security updates until Drupal 9 is released. Say 3 to 5 years.
Drupal 6 is already just a php and mySQL custom CMS website.
Drupal 6 can be hacked freely in March 2016.
Drupal 7 and Drupal 8 are relatively safe outside of silly custom code or configurations.
Although getting the migration completed by the Drupal 6 end of life is a consideration, most Drupal site owners are more concerned about the risk and overall cost.
Knowing your customer is paramount, not just for this Drupal 6 conversion, but providing any kind of appropriate Drupal support.
Clearly communicate the risks, costs and alternatives. Non-technical site owners are extremely intimidated by their site being deprecated. (They don’t like the word “deprecated” either!)
Covering all the options provides the decision maker with perspective and comfort with making a decision.
Don’t use the word “upgrade”. This has the perception of being turnkey. Use “migration” or, if you are really brave, “redevelopment”. Some of these options won’t be cheap; using the correct terminology prepares them for the sticker shock.
If you don’t want to support Drupal 6, you’d better say so right up front. Shameless plug: If you don’t want to, call us!