Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Jan 02 2024
Jan 02

In this article, we focus on tackling the organizational challenges that come with the technical realities of the migration away from Drupal 7 to newer, up-to-date versions of the content management system​​. We outline a strategic blueprint for a successful Drupal 7 migration, centered around three critical audits:

  • Content audit: Evaluating which content should be carried over to the new platform.
  • Design audit: Seizing opportunities to enhance the site’s design during the rebuild.
  • Technical audit: Refining the site architecture and meticulously planning the technical aspects of the migration.

This is the perfect catalyst and opportunity for your organization to assess and not just transition, but to reconstruct your digital presence to meet your future goals and challenges.

As the clock ticks towards January 2025, the End of Life (EOL) for Drupal 7 looms on the horizon. Moving away from Drupal 7 marks a critical juncture. Since Drupal 8 and above are significantly different in architecture from Drupal 7, the move requires a comprehensive migration. The good news is that the upgrade paths from Drupal 8 and above are smoother, so the step up from Drupal 7 represents a unique, one-time effort, which will pay itself off in longer site life cycles and higher ROI on that investment.

The core principle guiding this migration strategy is the alignment of technical implementation and design with the initial content audit. This approach ensures that the rebuild is driven by content needs, rather than forcing content to conform to a predetermined site structure.

Some key organizational challenges issues when navigating this technical shift away from Drupal 7 revolve around governance, starting by understanding the existing content on your website, assigning responsibility for it, and ensuring its relevance and quality throughout the migration process.

This technical inflection point can and should also spark a broader debate about the extent of redesign and transformation needed during the migration. IT and marketing teams should be discussing, in a nutshell, “What do we have? What can be better? What do we need to make that happen?”

Palantir.net is a Drupal Association–Certified Migration Partner. We have the technical expertise, experience, and strategic insight required to help steer you through this vital transition. Whether through our Continuous Delivery Portfolio (CDP) or web modernization services, Palantir is ready to assist you in navigating the complexities of the D7 EOL upgrade.

Content audit: Decluttering the house

At the heart of any successful migration lies a well-executed content audit, a responsibility primarily shouldered by the Marketing team. This vital process streamlines the migration by identifying what content truly needs to be transferred to the new platform and what can be retired.

The essence of a content audit

The key questions to address during the audit are: What content do we need? What can we do without? These decisions should be data-driven, relying on analytics to assess the relevance and usage of the content. Key metrics include page views, content validity, and user engagement.

If you don’t like having a cluttered house, you don’t just decide to build a slightly bigger house, then move all your clutter into it. It would be a better idea to take a look at what’s actually cluttering your house first, then decide what you need to build. In the same way, letting content drive your technical decisions is the better approach.

The complexity of a given migration is often more dependent on the variety of different content types than the volume of content. Once a system for migrating a specific type of content, like blog posts, is developed, it can run autonomously while the technical team focuses on other content types. For this reason, a site with numerous content types requires a more intricate migration plan compared to one with fewer types. A content audit can help reduce the number of content types and with it the resulting effort needed.

Tips for conducting a successful content audit

 The following considerations can help make your content audit a smooth and effective process:

  • Develop a comprehensive content inventory: Start by cataloging every piece of content on your website. This step is crucial as it allows you to see the full scope of your existing content and understand what requires improvement, discarding, or migration. Document key details of each content piece, such as URLs, titles, purpose, format, number of internal links, and other relevant information.
  • Make data-driven decisions: Use tools like Google Analytics and Google Search Console to review content performance, examining metrics like traffic, engagement, bounce rates, time on page, and conversion rates. This quantitative analysis helps inform your content strategy and guides decisions on what content needs updating or removal.
  • Complement data with qualitative decisions: Compare your content against benchmarks that align with your goals and audience needs. Assess the content for user experience, compliance with your style guide, and potential improvements. Decide on actions for each content piece, such as keeping, updating, consolidating, or removing, based on their relevance, quality, and performance.
  • Involve a content strategist: An expert content strategist can help with all the above tasks and aid you in preparing a migration framework. They will help align your content with your marketing and branding goals, as well as UX design and information architecture. If you don’t have an internal content strategist, Palantir can provide one if we help you with your migration. 

Content as opportunity for a redesign

Conducting a content audit does more than just streamline the migration process. It can also unveil opportunities for a redesign of your site’s information and content architecture, aligned with a new content strategy. This process is not just about elimination, but also about discovery — uncovering what content is most valued by users. Not only are you finding out what you don’t need, but you’re hopefully finding out what's really important as well.

Given that moving from Drupal 7 to Drupal 10 essentially entails a complete site rebuild, there lies a golden opportunity to design the site around the content. This approach ensures that the site architecture complements and enhances the content, rather than forcing content to fit into a pre-existing structure.

The insights won here feed into the second crucial stage of a Drupal 7 migration: the design audit.

Design audit: An opportunity for enhancing UX

A design audit is where you and your Marketing team evaluate the current design’s effectiveness and explore the potential for a redesign. It goes hand-in-hand with a content audit.

Design audit objectives

  • Evaluate current design effectiveness: Before deciding on a redesign, critically assess how well your current design serves your content and users. Does it facilitate easy navigation? Is it aesthetically pleasing and functionally efficient?
  • Consider compatibility with Drupal 10: Drupal 10 brings new features and capabilities. The design audit of a Drupal 7 website usually reveals a rigid, template-based layout system, limiting content display versatility. By migrating to Drupal 10 and utilizing its advanced Layout Builder, the redesign can offer dynamic, user-friendly layouts, enhancing user engagement and providing flexibility for content strategy adaptations.

    Note that, while migrating away from Drupal 7, you essentially rebuild your site. Even if you choose to retain the existing design, adapting the look and feel to the newer Drupal version will require some level of reworking as well. If your existing design seems incompatible or would require extensive modifications, it might be more efficient to opt for a new design.

  • Align design with content strategy: The design should complement and enhance the content, not overshadow it. A design audit should involve close coordination with content strategists to ensure that the design facilitates the content’s purpose and enhances user engagement.
  • Explore modern design trends: Technology and design trends evolve rapidly. Use this migration as an opportunity to refresh your website’s look and feel to stay relevant and appealing to your audience.
  • Accessibility enhancement: Focus on improving the overall user experience for everyone. This includes optimizing the site for various devices and improving accessibility, for instance, compliance with A11Y guidelines.

Palantir not only offers technical expertise in migration processes but also provides skilled designers who can seamlessly collaborate with your team. Our designers are adept at working alongside content strategists. They ensure that you end up with a cohesive system that effectively supports and enhances your content strategy, ensuring that every aspect of your site’s design is driven by and aligned with your overall content goals.

Technical audit: Engineering a future-ready framework

Next up, your internal IT team should perform a comprehensive technical audit. If necessary, this stage can overlap with the content audits. However, we recommend that your migration should be primarily driven by the insights gained from your content audit.

The ultimate goal of the technical audit is preparing for a new Drupal environment. This means understanding how the identified technical elements will function in the new system and planning for any necessary adaptations or developments.

Data architecture audit

The technical audit begins with a detailed analysis of how data is structured in the current Drupal 7 site. This involves examining the entity relationships and the architecture of data storage. Understanding how different pieces of content are interlinked and how they reference each other is essential. This step not only overlaps with the content audit but also sets the stage for a smooth technical transition to Drupal 10.

Custom functionality and integration evaluation

A critical aspect of the technical audit is assessing any custom functionalities or third-party integrations present in the current system. This includes custom plug-in modules, single sign-on mechanisms, and other unique features. Each custom element that you migrate over is something you have to maintain, potentially throughout the lifetime of the site. The decision to migrate these elements should be based on their current value and necessity. During the audit, aim to determine which functionalities are essential and how they can be adapted or redeveloped for Drupal 10.

Driving collaborative decision-making

Collaboration between the IT/technical, marketing, content strategy, and design teams is vital in deciding what to keep (and migrate) and what to discard — regarding site content, architecture, code, and functionality. The technical audit, outlining the functionalities and integrations of the current site, guides the planning and decision-making process following the insights you gain from the content and design audits.

Conclusion: Charting the course of a Drupal migration

As we’ve seen, the journey away from Drupal 7 involves three main audits:

  • the content audit, which acts as a decluttering exercise;
  • the design audit, seizing opportunities to enhance user experience;
  • and the technical audit, engineering a future-ready framework. 

The content audit is the central pillar, and content strategy should drive the technical implementation and design decisions. This approach ensures a migration process where content seamlessly integrates into an efficient, updated site structure, rather than being confined by it.

Palantir is here to help and guide you through a successful migration from Drupal 7 to the future of your online digital presence. We are a Drupal Association–certified migration partner, with years of experience with intricate processes. Our expertise in content strategy, design innovation, and technical proficiency makes us an ideal full-service partner for navigating the complexities of a D7 end-of-life upgrade.

If you’re considering this critical step in your digital strategy, we invite you to explore how Palantir’s Continuous Delivery Portfolio (CDP) and web modernization services can transform your digital presence.

Nov 14 2023
Nov 14

Drupal’s code is itself an expression of the community’s open source values. The code is there for anyone to use, free of charge, and is always evolving as a result of community contributions. That’s substantially different from proprietary software and demonstrates a commitment to collaboration and transparency.

Similarly, Drupal’s evolution is not solely about refining its API or enhancing user interface design – it’s intrinsically linked to shared experiences and mutual learning within the community. DrupalCon allows developers and users from various backgrounds to come together not only to share knowledge about the platform but also to shape the future direction of the software based on collective feedback and diverse needs.

This all means that the story of how Drupal has changed isn’t just about software. It’s also about how we, the community of people who make Drupal possible, understand ourselves.

In this article, we’ll take a look back at the history of Drupal, focusing on the narratives that have shaped the community. In doing so, we hope to provide an insight into the forces that have powered Drupal’s growth and resilience. Furthermore, analyzing the ongoing evolution of these narratives helps illuminate what future shifts may be on the horizon for the Drupal ecosystem.

Looking to the future, we’ll also consider how the community will continue to develop, and why the Open Web Manifesto encapsulates the aspirations this community has expressed for over 20 years. While Drupal itself has kept evolving, what has remained constant is our shared commitment to an open, inclusive, and equitable web.

Sailing on the ship of Theseus

Palantir began using and contributing to Drupal in 2006. Since then, I’ve also served on the Board of Directors of the Drupal Association and helped organize several camps and events. This long perspective has given me some fascinating insights into how Drupal — and its community — have evolved.

When we talk about Drupal, it’s tempting to think about it as the product – as the code itself. But the code that was written in 2001 is not what is running today.

Drupal is like the Ship of Theseus, the subject of a famous thought experiment first written about by ancient Greek philosopher and historian Plutarch. The Athenians wanted to preserve Theseus’s ship, so over many years, they replaced its parts as they wore out, plank by plank. 

The question is: Once all the planks have been replaced, is it still the Ship of Theseus? If it’s not, at what point does it stop being the original ship, and become a replacement? After one plank? After twenty? Or is there a sense of identity the ship possesses that is independent of its parts, related instead to the way people talk about and use it?

For many people, the idea that identity isn’t just about constituent parts helps clarify the paradox. And it also helps shed some light on Drupal. Even if none of the original Drupal code is being used today, a Drupal identity has persisted. This identity doesn’t just stem from one person (not even from Dries!). Rather, Drupal’s special factor has always been its community – all the people who build Drupal and make it work.

It’s the culture -- the values, the assumptions and the beliefs-- of the people sailing on the Ship of Theseus that determine why it’s still the same ship, for all the changes it’s seen.

Drupal is an ecosystem, built by contributors of code and of non-code, backed by an infrastructure hosted by the Drupal Association, supported by businesses, and used by people and organizations to power more than 2% of the top million sites on the web. All of these people coming together make up different parts of the Drupal community – and it’s all of us who really determine what Drupal is, not any specific line of code.

The stories we tell ourselves

The stories we tell ourselves have been a major driver of Drupal’s ability to achieve ongoing success and remain resilient as a decentralized, global and volunteer-based open-source project. They are narratives that tie together the hundreds of thousands of contributors over Drupal’s history.

These shared stories reflect Drupal’s culture. And what they show is that our culture has been substantially shaped by non-code contributions from businesses and individuals — more so than by the code itself.

Let’s consider three key narratives that have shifted over time to gain an insight into the forces that have powered Drupal’s growth and resilience.

Eat your own dog food? No, get off the Drupal island!

“Dogfooding” is a term used for the practice in which tech workers use their own product consistently to see how well it works and where improvements can be made.

In the early days of Drupal, there was a strong ethos of “eating your own dog food” — building tools for the community’s needs using Drupal itself. With Drupal as their hammer, contributors approached many tasks as nails that could be driven home by extending Drupal.

Much of this was born of necessity in the absence of alternatives. Drupal provided the Groups module for community interaction before social media existed. The Project module enabled collaboration before Git. Local Drupal camps relied on homegrown event management systems like COD. The Drupal Association itself was formed partly to provide infrastructure after early infrastructure failures.

Over time, however, the Drupal community embraced integrating with external tools better suited for certain tasks. Infrastructure moved to Git and Slack. Camps adopted specialized event registration systems. Core adopted the Symfony framework.

While retaining its innovative spirit, Drupal evolved to focus on its strengths, looking to other technologies to inspire and augment its capabilities. The narrative shifted from an insular “eat your own dogfood” to a more outward-looking “get off Drupal island.” The big tent expanded to include complementary tools, acknowledging that Drupal need not solve every problem alone.

This evolution demonstrates the community’s pragmatism and maturity. By recognizing external solutions, contributors avoid reinventing the wheel. The new narrative reflects a holistic understanding of how Drupal fits into the broader technology landscape.

Talk is silver, code is gold? No! Come for the code, stay for the community.

In the early days of Drupal, the dominant narrative was “talk is silver, code is gold” — only contributions to the codebase mattered. However, over time the community realized the interplay between community-focused activities and code contributions provided mutual benefit. Research shows community participation expands social ties, shapes strategy, and focuses innovation, even without directly affecting code productivity.

Drupal’s evolution reflects the growing appreciation of community-oriented work. Adoption of a Code of Conduct for events marked increased investment in healthy interactions. The creation of the Community Working Group demonstrated the importance of conflict resolution. Rewriting the Code of Conduct in plain language and forming a Community Health Team required tremendous time and emotional labor — but is strong evidence of the value now placed on community. Local Drupal communities now actively collaborate. Shared playbooks spread knowledge and regions like Europe brought back DrupalCon.

The narrative has now shifted from “talk is silver, code is gold” to “come for the code, stay for the community”. This underlines how vital non-coding work is in enabling Drupal’s success.

Scratch your own itch? No, if you want to go far, go together!

Early Drupal embodied the “scratch your own itch” ethos — solve your own problems and build what you need. Drupal was likened to a box of Legos: you could find many disparate pieces, and sometimes there were instructions on how to build with them. But if you couldn’t find what you wanted, you’d have to come up with your own design.

This attitude combined with what we might call a “benevolent dictator for life” model, whereby community members felt they needed permission from Dries before undertaking anything major. Indeed, many sought intervention from Dries across code, governance, and conflict resolution, developing unhealthy hierarchical expectations. Disagreements often devolved into “epic bikeshedding”, resulting in exhausting debates where the most stubborn prevailed unless a particular argument caught Dries’s attention.

As the community grew, this proved unsustainable. While some called for more hierarchy, Drupal resisted a full leadership structure. Code may have correct answers, but people and social issues are messy. Extending hierarchical expectations to non-code contributions risked grinding everything to a halt, replicating the “bikeshedding” debates.

Instead, Drupal evolved from “scratch your own itch” individualism towards “if you want to go far, go together” collaboration. This new era saw greater coordination through strategic initiatives and working groups. These collective efforts enabled tackling challenges at scale rather than relying solely on individual contributors. Work could be distributed across many hands to achieve impact not possible alone.

Another major non-code innovation was the contribution credit system. Traditional open source celebrated individual contributors and their achievements. But Drupal needed to accommodate organizations like governments wanting collective credit.

Rather than giving organizations direct commit access, Drupal pioneered contributors claiming credit for their organizations. This preserved individual recognition while tracking organizational impact. Crucially, the system included non-code work from the start.

Though imperfect, contribution credits surface essential non-coding activities like documentation, mentoring, and event organizing. Granting visibility makes the work more valued. It says all contributions, not just code, are worthy of recognition.

Businesses have also collaborated to provide infrastructure, funding, and other resources for collective benefit. 

Future projections: Networked, regenerative, listening

As Drupal continues to evolve, three potential paths forward emerge from these past narratives. These point to a future in which Drupal will become more networked, more regenerative, and will invite even more community listening.

  • Networked
    Past centralized coordination efforts brought much-needed structure but also new complexities. Consensus and decision-making become challenging at scale.

    In the future, a compromise solution will exist in the form of networking — decentralized creative partnerships and empowered teams tailored to specific needs. Breaking down work into smaller scopes makes problems more tractable, shifting the mindset from scarcity and exclusivity to abundance and inclusion. Creative partnerships facilitated through the Drupal Association can promote consent-based and “safe to fail” decision-making, while flexible contribution models will allow individuals and businesses to smooth resource constraints.
     

  • Regenerative
    Drupal creates tremendous value but cannot fully capture or distribute it equitably. Anti-patterns of exploitation and burnout persist, disproportionately affecting core contributors.

    To sustain success, Drupal must encourage, enable, and recognize pro-community actions. It must also differentiate which parts of the ecosystem are public goods that anyone should be able to use for free, and which are more akin to commons — that is, to areas that require a degree of care and input from those using them. Not all of Drupal’s major cost centers are public goods.

    Strengthening organizational protocols, growing leadership pipelines, planning for transitions, and sharing knowledge will make the ecosystem more sustainable and resilient without being exclusive. Regenerative practices that distribute effort and reward more equitably will reduce burnout. The result is a system built to thrive through ongoing renewal of its most vital asset — engaged contributors.
     

  • Listening
    Getting off the island helped make us aware of the bigger picture. We need to think globally before we act locally.

    This means tending to the Drupal ecosystem by structuring for flexibility. Accommodating different contributor types enables pioneers, maintainers, and coordinators to play their roles. The Drupal Association ought to act as a kind of town planner.

    At the same time, we must also shape the external landscape by collaborating with other open source communities. Providing feedback on policies like the EU Cyber Resilience Act makes the terrain more hospitable for open source as a whole. Listening through participation in the open web movement will help contextualize Drupal’s place and influence. It allows acting both locally and globally — solving immediate needs while advancing the broader open technology ecosystem.

The Open Web Manifesto

Like any living system, Drupal must continuously adapt while remaining true to its core values. The Open Web Manifesto articulates Drupal’s commitment to an open, decentralized, inclusive web built on freedom and participation.

The manifesto declares the Open Web a cause driven by principles, not just technology. It must be permissionless, letting anyone contribute. No single entity controls it. The Open Web welcomes all as users, creators, architects, and innovators regardless of identity or status. Sustaining it requires deliberate, collaborative effort.

Drupal sustains the Open Web through its creativity, diversity, and integrity. Its global community puts open source collaboration into practice, introducing participatory digital experiences. This empowers Drupal's partners, contributors, and users alike.

By remaining true to its ethos while adapting to a changing world, Drupal can keep shaping an equitable digital landscape. The narratives that brought Drupal this far — from independence to interdependence, visibility to value, and co-opetition — point towards an even more vibrant, resilient and regenerative future. 

If Drupal continues listening to its community’s needs while engaging with the global ecosystem, it can flourish for decades to come as a thriving open source leader empowering people to build a better web.

Cropped version of Drupalcon 2009 - Paris - 17 by Chris Heuer licensed under CC BY-NC-SA 2.0 DEED.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web