You don’t have nearly as much time as you may think to migrate from Drupal 7 or Drupal 8 to Drupal 9 and unless you act now, your organization’s Drupal installation may end up in a very precarious state.
Not only is time running out quickly… agencies (the truly competent ones) are rapidly filling their schedules. Any large-scale D7 migrations not already underway are pushing the envelope. Really.
The clock is ticking...
Drupal 7 to Drupal 8 (or Drupal 9) migrations seem to be front-and-center when it comes to talking about Drupal web applications/websites, lately. Of course, there is a very good reason why that topic is prominent in the thoughts of any Drupal site owner or manager these days… Drupal 7 end-of-life (EOL) is right around the corner. If you think that’s hyperbole - think again. While much depends upon the size and/or complexity of your Drupal installation, even a relatively modest Drupal 7 site no longer has the luxury of time. All the best, most experienced agencies will have full schedules very soon - if they are not already full. If you end up with an inexperienced agency handling your migration, even a year won’t be enough time for them to get the job done properly - if they can get it done at all.
Aside from the (rather obvious) factor of sheer size of a given Drupal 7 instance, other factors weigh in to the migration process. How familiar are you with your organization’s application? Is there any custom code (you know of)? How much? Even if you’re certain there is no custom code, do you have an agency which truly specializes in Drupal keeping your application up-to-date? Are you certain? It could make a considerable difference. Did the same specialized agency perform all the development work/maintenance on your application from the beginning - or has it been through two or more agencies? We ask because it matters. Read on.
We’ve had several clients of late come to us with rather similar stories. They asked their then-present agencies to give them estimates (timelines and budgets) to migrate their Drupal 7 applications to Drupal 8. Initially, they were given verbal estimates. However, when it came time to put solid estimates on paper, the agencies began back-pedaling and/or stone-walling their clients. Timelines and budgets crept ever upwards. Every time the clients requested estimates, the responses either indicated lengthening timelines and increasing budgets or were so ambiguous as to ultimately prove useless. Finally, with the agencies pressed to commit to a written quote, they admitted they had not performed many (in some cases, any) migrations… and they just weren’t confident enough to provide accurate timelines or budgets for their clients. Requiring definitive answers (in many cases, in order to produce quarterly budget forecasts), the clients sought out agencies which could provide accurate timelines and budgets… agencies which had significant experience with Drupal 7 migrations. Ultimately, they ended up at Thinkbean’s doorstep.
Why do we need an agency... let alone, a Drupal specialist?
While it is true there are some Drupal sites which are rather small and may be able to get away with using a freelancer or a less-experienced Drupal agency to perform their migrations, such is not the case for the majority of Drupal sites. Drupal was built with large, enterprise-level and government organizations in-mind - organizations which required a content management framework which was flexible, scaleable, customizable and secure. Consequently, it was widely adopted by just such organizations. Even a relatively modest Drupal migration would challenge a single developer or small team to properly complete in the time remaining before Drupal 7 EOL. However, an expert agency is what is required to properly complete any significantly-sized Drupal instance (and certainly any large-scale and/or complex instance).
As we’ve mentioned in many articles, Thinkbean is a Drupal-only agency. That means we work with Drupal applications, oniy. That’s all we do - all day, every day. We don’t do WordPress (WP). We don’t do Joomla. We don’t do ASP.NET. We do Drupal…only. There are plenty of agencies which claim to specialize in Drupal… but if they work on anything other than Drupal then they’re simply not Drupal specialists. Why? Well... very simply, over a decade of experience has shown us(time and again)the best Drupal development agencies are those which work only with Drupal. They’re out there. There aren’t many agencies which can truly claim to be Drupal specialists - but there are some… and it makes all the difference in the world. Especially, when time is of the essence and the job must be done right the first time… times such as the present.
So, why all this talk of Drupal specialists? Because agencies which don’t have their full and foremost attention focused intently on everything Drupal can dangerously mislead and/or mis-inform your organization. Not purposely, mind you. They simply don’t know what they don’t know… and for any organization whose Drupal application is integral to its operations, working with an agency which knows the most expedient and efficient migration paths to take and which utilizes best practices while doing so is what makes the difference between success and failure - on multiple levels. As example, support for Drupal 7 doesn't officially end until November of next year (2022)... but don't let your agency tell you there is "plenty of time" to go through the migration process. There isn’t. You might be surprised at what may be required to migrate your Drupal 7 instance(s)… and “surprised” is the last thing you want to be when it comes to your organization’s required timeline and budget for its Drupal 7 migration. The prudent planner would be very wise, indeed, to consider one or more of the following factors…
- How large is your site?
- How much custom functionality is employed?
- How many integrations are there?
- Has your site been updated every week (as-needed)?
- Is there any gated content?
- Are there any user groups with particular restrictions?
- What types of content exist (audio, video, documents, images, etc.)? (Yes. Such items can add wrinkles to a migration.)
- Are you utilizing revisions? (If so, how many do you need to retain?)
- Is your organization responsive (how quickly are tasks turned around (e.g. budget authorization, QA reviews, etc.))?
...and this is just a partial list. There are many other factors which could hinder the progress of a migration - and such hindrances are exponentially more time-consuming as the scale of the migration increases. Especially, when the migration is being performed by an agency with minimal migration experience.
Drupal 10 - June 2022
So, it should be quite evident by now large-scale Drupal installations (just by virtue of their size) will require sufficient time in order to ensure a smooth transition from Drupal 7 to either Drupal 8 or Drupal 9 (actually, you'd migrate into D9 at this point unless you've already begun migrating to Drupal 8, as Drupal 8 is EOL in November of this year). The Drupal 8 to Drupal 9 upgrade was the easiest upgrade between major Drupal versions in over a decade... and believe it or not, D10 is already slated to be released this coming June! If you're still on Drupal 7, you'll be three major versions behind by June of next year. Think about that. Chances are, you wouldn't let your operating system on your computer fall three major versions behind... and it's likely your OS isn't as important to your organization as your web application. On the upside, though, you've got many exciting new features to look forward to when your application is finally migrated.
Of course, one of the most important items to consider about your migration will be which agency you choose as a service provider. As with many things in life, the best, most capable agencies will be in highest demand. No agency has limitless human resources. Even if your organization had all the necessary funding already authorized and allocated, once an agency has filled its schedule with migrations (and other work) – that's that. Latecomers will have to either wait their turn or look elsewhere for migration assistance. To end up in that kind of situation would be the bane of anyone responsible for a Drupal 7 installation. In such a situation, there are two options – neither of which is appealing. Either utilize an agency which is not your first choice and hope everything works out okay (very risky)… or wait until your preferred agency can get to your project and hope no vulnerabilities are exploited in the interim (also risky).
So, how big IS large-scale?
As this article's title indicates a focus on large-scale Drupal 7 migrations, let's take a moment to think about what constitutes a large-scale Drupal 7 migration. Many clients come to us with significant concerns about finding an agency which can handle migrating a large Drupal installation. Perhaps, your organization has a large-scale Drupal 7 installation. Perhaps, not. Many of our conversations with new clients begin with something like, "We have a really big Drupal site we need to migrate…". Some clients really did have big Drupal 7 installations... and they knew they did. Good for them. Others didn't realize the overall size of their Drupal 7 instances until we called a number of items to their attention via site audits. Certainly, those clients came away from our conversations much relieved about the fact they chose to migrate sooner, as opposed to later. Other clients came away from a site audit significantly less concerned -and with much different perspectives on the sizes of their Drupal installations. Regardless, all of them were much more confident in the fact their migrations were being handled by competent professionals. A Drupal 7 instance with hundreds of nodes is a significant size… but large-scale? Well, maybe.
In our experience, "large-scale" can have multiple meanings. We're not trying to be coy - and we will talk numbers in the next paragraph. We just wanted to be sure readers of this article understand it's a fact that circumstances other than sheer size can lead to a migration being labeled "large-scale". We've migrated applications with only hundreds of nodes and a few thousand revisions - but they had a substantial amount of custom functionality which was created over time by several different agencies. Combing through many different custom modules written from scratch made for very time-consuming and labour-intensive work. As a result, those migrations took significant time to complete (and time is money). Such migrations should be considered large-scale. Then, of course, there are the whales...
Our "whales" have been some real behemoths. In these cases, we're not talking about thousands of nodes with tens of thousands of revisions and custom functionality. We're talking about hundreds of thousands of nodes – with millions of revisions and a dozen or more custom modules. Yes. You read that correctly. The Drupal experts at Thinkbean have, indeed, performed migrations of such magnitude. Now, at first blush that may seem like braggadocio - but it's the truth... and we thought sharing that information with readers of this article would serve to help put things into perspective. This article is meant to do for the reader what conversations (such as mentioned in the first paragraph of this section) have done for our clients… lessen your anxiety over the pending migration and help to explain what "large-scale" really means. Additionally, for those who are experiencing certain issues with your current agencies, we wanted you to know there is, at least, one agency out there which can handle your Drupal 7 migration – no matter how big or how complex. You just need to keep in-mind the window to get it done before Drupal 7 EOL is closing - quickly.
Let's talk for a minute about how applications can grow so large.It's not as difficult as it may at first appear for those responsible for a large organization's Drupal instance(s) to be taken aback somewhat by the size of their applications until either they've taken a bit of time to focus on the overall functionality of their application(s) or they've asked an agency like Thinkbean to perform a site audit/migration evaluation. Nodes and revisions can really add up quickly when you have multiple admins and/or other users creating and editing content. Additionally, legacy features can be forgotten if not utilized regularly enough... but they may still be required in the migrated instance, for one reason or another. Particularly when there has been more than one agency/service provider working on an application over the years, different sections and/or layers of the application may have been structured inconsistently. As one small example, if a previous agency was utilizing Features (which has now been taken over by Config) to manage certain elements of a Drupal 7 application and that isn't taken into account during your migration, your migrated instance could be seriously broken... and that's just one little item to consider. Such "items" (especially if there are more than a few) can add considerable complexity to a migration.
Being a Drupal-only agency, Thinkbean has seen more than its share of rescue projects over the years – projects in all manner of disrepair. It's only natural. A shoulder surgeon sees more than a few badly-damaged shoulder joints over the years, too. Just as a patient would see a shoulder specialist for a complicated shoulder issue, a Drupal project needs a specialist when there is a significant Drupal issue to tackle... and a Drupal 7 migration is a "significant issue", now there's no more time left to hope a migration goes smoothly...because if it doesn't, your organization will find itself in a dire predicament - in very short order. Even we have been surprised at the number of clients who have ended up at Thinkbean's doorstep because their former agencies hadn't performed even a single Drupal 7 to Drupal 8 migration. Do yourself (and your organization) a favor...if your Drupal application is integral to your organization then have the migration performed by an agency which specializes in Drupal. It doesn't have to be Thinkbean. For your own sake, just make certain it's an agency that really knows Drupal - inside and out. It's too late in the game to risk getting it wrong.
Long-term support (LTS) for Drupal 7
Everything is working fine. So, can't we just remain on Drupal 7? Certainly! Remaining on Drupal 7 is an option. It's not a great option (really, it's not even a good option)… but it's still an option. Why is it not even a good option? Consider the following, for starters... remaining on Drupal 7 will make obtaining feature enhancements and/or new functionality for your application very difficult (not to mention, very costly and s-l-o-w). All of the new features and functionality are being created for Drupal 8/Drupal 9 and above. New features/functionality for Drupal 7 applications will have to be developed from scratch.
Consider, also, the limited number of "authorized" LTS providers. While you may still find many developers able to work on your application, there is but a small handful of agencies which offer long-term support (i.e. security updates)… and they are far from inexpensive. While there is a definite cost associated with migrating from Drupal 7 to Drupal 8 or Drupal 9, it is (for all intents and purposes) a one-time cost. LTS, on the other hand, is a significant, ongoing cost center. Not only that but it's a cost-center from which you'll have more and more difficulty getting out from under. Imagine if you had a D6 application and you wanted some new functionality. It would be extremely difficult to find an agency capable of doing the work. Very few agencies have worked with D6 to any significant degree over the past few years. You'd have to accept the limitations of your application because the cost and time associated with making improvements would be a substantial fiscal barrier.
Additionally, once the Drupal Security Team (DST) stops monitoring core and contrib for Drupal 7, the potential for reactive security updates (as opposed to proactive updates) skyrockets. Even with LTS from an "authorized" provider, the day the DST stops enforcing active monitoring of Drupal 7 core and contrib for security vulnerabilities, thousands of "good guys" stop looking a Drupal 7 and thousands of "bad guys" start looking at it - hard. Even if the number of "authorized" LTS providers doubled overnight, there would be no comparison between the security of Drupal 8/Drupal 9 versus Drupal 7. Your application would become much more susceptible to security vulnerabilities. Speaking plainly, it would be a sitting duck.
I have a Drupal 8 site. Do I need to migrate to Drupal 9?
No! A Drupal 8 to Drupal 9 move is an upgrade, not a migration. It's a much-less-involved process. We're not telling you to discount it. It is a major upgrade - and any upgrade is a process of some significance. It's just not the major deal a Drupal 7 to Drupal 8/Drupal 9 migration is... and it was designed that way. After your organization's migration from Drupal 7 to Drupal 8/Drupal 9, life becomes significantly easier - and we mean that in more than just one way. Drupal has always been a flexible, scalable, secure, customizable content management framework. However, the reason migrating from Drupal 7 to Drupal 8/Drupal 9 is such a big deal is due to the fact Drupal 8 is (and subsequent versions, therefore, are) a completely different animal. The very foundations of Drupal experienced a revolutionary transformation. Drupal went from being a formidable, robust framework for enterprise-level organizations and government to being THE framework of choice for enterprise-level organizations and government.
Why the massive upheaval of Drupal's foundations? Well, Drupal 7 core developers, maintainers, module creators and agencies realized they had a bit of an image problem. Anyone already on the platform loved the fact they were utilizing a framework which could take them anywhere their organizations needed to go. However, many organizations were somewhat hesitant to choose Drupal for their web application needs due to its reputation as being something of a behemoth... not all that user friendly and somewhat unwieldy. Everyone who really knew Drupal realized only a monumental change in how Drupal functioned at its core levels would allow them to diverge from the path they were on to a path which would allow Drupal to become, quite literally, almost anything. It was a BIG, bold step - and the right one to take.
Sure. It meant Drupal agencies had to commit -really commit, to Drupal... and Drupal, only. It meant agencies which had years of experience in Drupal would have to completely re-learn Drupal from the ground up (no mean feat) - and there was a substantial amount of push-back from the agencies and developers themselves... but it was the only way an agency would be able to provide truly expert Drupal services to a client. Between the legacy versions of Drupal (Drupal 7 and below) and the latest versions of Drupal (Drupal 8 and above), there was sooo much to know and sooo many new things to learn, it would be impossible for any agency to be an expert in Drupal in all its guises and still offer WP, .NET, etc. Many agencies were unable make the transition effectively. They still offer Drupal services (and even bill theirselves as Drupal experts)... but they are the agencies from which Thinkbean inherits so much of its rescue work.
Drupal 8 is great! (...and so is Drupal 9)
Drupal's core technology shift made client's lives infinitely easier - and it has given Drupal agencies more capabilities than ever! Drupal was always a powerful platform, capable of handling the most demanding needs of any organization - public or private... but now, it offers the combined benefits of many more efficient and effective tools for developers while providing the clients' users a vastly superior experience both for administrators managing content and for visitors experiencing revolutionary new ways to interact with that content.
Ready to Get Started?
Are you ready to start reaping the benefits of Drupal 9? Connect with our experienced Drupal strategists to ensure that your migration experience, whether you are coming from Drupal 7 or Drupal 8, is a smooth one.