Drupal 6 made its debut in February 2008. For eight years, it was supported, upgraded and patched. In February 2016, support for that version of the Drupal content management system finally lapsed. Drupal 6.38 was the last version released.
The Drupal development community encouraged admins and site owners to upgrade from Drupal 6. Without code support, any new security vulnerabilities would go unaddressed. Drupal 6 sites would miss out on cool new features, new modules and new themes (including responsive themes).
If you didn’t upgrade your site from Drupal 6, you’ve been missing the boat.
I got serious about working with Drupal in the days of Drupal 4.7 (ca. 2006), and built a lot of sites in Drupal 5 and Drupal 6. In that era, Drupal saw a big rise in its popularity. Much of its adoption came in the 2007-2010 era, when people came to Drupal for its capacity to do powerful things. For some, that’s where the development process stopped. Their Drupal 6 install did everything, so they didn’t need to do anything other than just let it hum along.
How to plan for an upgrade
Each Drupal 6 migration I do starts with an assessment: where are you now? I ask for an admin login and password; and then take a peek at how your Drupal 6 site has been put together. Things I look for:
- Current list of modules. Each module helps the site perform a specific function.
- How the theme is built. The look and feel of the site is controlled with the theme.
- The data. Do you have 5 pages or 5 million?
- Special add-ons. Some developers include custom code that serves a business role.
A simple website could be little more than an editable brochure site, with several pages to talk about the business, its staff, and its location and contact info. A more complex website may be an online shop or a membership site: something that requires real horsepower and lots of programming code.
To migrate your site away from Drupal 6, all of the code, the look, and the data have to be accounted for and maintained. After migration, that same functionality, the design goals and the content still have be present.
Here’s the tricky part, though: Drupal 6 did some cool stuff through feature rich modules that extended Drupal’s capabilities. Drupal 7 didn’t see all of that coolness carry through as some Drupal 6 modules didn’t get rebuilt for Drupal 7. Drupal 8 saw another drop-off in functionality. The reason for this? As new versions of Drupal come out, older modules don’t work with the new code. In some cases, the developer community will build a new module that will inherit the same role or function. In other cases, though, the functionality is just gone.
For this reason, the assessment phase amounts to going from module to module to see if there is a new version, and if the new version still satisfies the role. Where there isn’t a fit, I’ll need to do some work to fill the gap.
This assessment step can take anywhere from 1 hour to 8 hours. If it takes as long as 8 hours, it’s because there is lots of custom code in place, and finicky elements to account for.
When it comes to the actual migration, the work varies. A brochure site will be something like 30 to 40 hours of work. A membership list site (eg. like a residents association) could take 40 to 60 hours. A e-commerce website could take between 50 and 100 hours. A site with lots of custom code could take upwards of 500 hours, as that custom code gets re-developed to fill the same role in the next site.
If these numbers scare you, the best first step is to contact me and ask, “what’s involved?” After a quick assessment (the cost of which will depend on the complexity of your site), you can get a sense of whether a migration is going cost $3000, $30,000, or somewhere in between. In my case, I will draft a “portable” assessment. The report can then be used for us to work together, or it may be handed off to a different development house for them to carry out.
How does a migration work?
After the assessment phase, if we make a commitment to work together, there are some key requirements:
- The goal is to move everything and make some small wins along the way (ie. create responsive, mobile-ready designs; and be more search engine friendly).
- If making everything translate over exactly isn’t possible, we’ll come up with a plan that honours the intention of the original site while using the tools available in the new version.
- We’ll look for ways to put the site on a diet. What don’t you like about your current site? If there are annoying elements in your Drupal 6 install, maybe we can change them instead of moving them.
- I always need access to the website (the Drupal login), the web server (the FTP login), and the database (the MySQL login and password). This step can be problematic in some cases. If you did a Drupal website back when Drupal 6 was cool, that could mean you last needed the FTP login in 2008. It’s okay – there are ways to work that out.
- The last decade has seen some big changes on the Internet. Ideally, a migration would accommodate those advents and make your site easy to find via Google.
- I always need development space: a place to put the new version of the website. I will commonly set up development space on one of the web hosts I already use.
- I’ll need a safe place to archive your site. Most web hosts will give you lots more capacity than you need. I will use an out-of-the-way place to put your Drupal 6 website, where it will live on after moving day. Think of it as Jurassic Park for your website.
The migration involves:
- Getting all of the assets (files, code, database)
- Moving copies of these into a working space
- Changing the modules
- Performing the database upgrade
- Replacing the theme.
- Beginning the process of massaging the new website to behave as well or better than the old website
- Giving you a first look at the work when it’s ready
- Massaging it some more to get it just right
- Archiving the old site
- Moving the new incarnation of the old site into the mix
Why Stay With Drupal?
If you’re dumping Drupal 6, maybe this is the time you want to leave Drupal altogether. Here are my thoughts on your other options:
What about Wix?
At the core of Drupal and WordPress there is one core concept: open source. Developers support free, open source software to keep these program strong and feature-rich. Open source applications can be deployed anywhere.
Wix isn’t like that. Wix is a service from one specific company. If you needed to pull your Drupal website from your existing service provider, you could take it somewhere else and host it there instead. But if you have a falling out with Wix, you can copy-paste your website, but you can’t take the whole website with you.
If you liked Wix’s features, but needed to move your site, you’d have to find replacements for them. With Drupal or WordPress, all of the features come along with the website on moving day.
What about Squarespace?
Squarespace, like Wix, is a publishing platform rather than a software program. It has an easier learning curve than Drupal and WordPress,but it also has fewer options than WordPress or Drupal. That presents you with the iPhone dynamic: if more choices gives you less satisfaction, almost no choice should give you lots of satisfaction. Squarespace, with its pared down list of options, gives some people a lot of satisfaction.
Being tied to Squarespace’s services isn’t great. It’s inability to expand in a direction of your choosing could prove to be constricting as your business grows and changes. If someone has been using feature-rich Drupal 6 for several years, they will likely see Squarespace as a big drop in flexibility. For complex things like ecommerce, Squarespace comes up short compared with Drupal and WordPress.
The content you create on your site is yours, and you should have the freedom and tools to do anything you want with it, including moving it elsewhere. Drupal beats Squarespace with its capacity to create flexible, exportable, portable content.
Migrate to WordPress
In 2010, Drupal was about as popular as WordPress. Since then, a lot has changed. WordPress runs something like 16% of the websites on the Internet, and saying “CMS” is now often synonymous with saying “WordPress.”
Why WordPress? It’s easy to install. It’s easy to administer. It’s easy to export. It’s easy to extend with free and for-pay plugins. It’s easy to upgrade. It’s easy to host: if you don’t have a budget, there’s free hosting at WordPress.com.
For some, leaving Drupal is the jumping-off point for getting into WordPress. If you’re interested in this as an option, I can help you decide what’s right for your site. As I have performed many Drupal -> WordPress conversions, I can also help you with every aspect of the migration.
More information on the Drupal -> WordPress process: https://shawndewolfe.com/blog/drupal-to-wordpress.html.
How to get started
If you’re interested in converting your Drupal 6 website, the next step is to reach out. If you like, you can even google “Drupal 6 upgrade” to see what a do-it-yourself process looks like. Since all of this technology hinges on free, open source software, all of the code and process is available for anyone to see and use. But if you’d like it done by an expert, contact me. I’ll be happy to discuss how we can make your Drupal conversion as fast, easy and elegantly simple as possible.
I have done a lot of Drupal 6 upgrades. I am available to take on a Drupal 6 to Drupal 7 migration project. Contact me!
