Executive Summary
With Drupal 7's end-of-life approaching in January 2025, organizations face critical migration decisions. Drawing from my decade of experience as a Technical Account Manager, this article explores practical migration paths based on your site's purpose and complexity. We'll examine community-supported tools, share real migration experiences, and discuss how innovations like Retrofit and the upcoming Drupal CMS can help shape your migration strategy.
Understanding What's at Stake
With Drupal 7's end-of-life approaching on January 5, 2025, organizations face a critical decision point. Before diving into migration options, let's step back and consider a fundamental question: Why did you choose Drupal in the first place?
The Power of Drupal: A Framework Decision
Drupal has always been more than just a CMS—it's a powerful framework that enables complex digital experiences. Modern Drupal (9/10/11) builds upon this foundation, offering even more powerful tools while maintaining the flexibility that made Drupal 7 great. If you chose Drupal for its framework capabilities—custom content types, complex relationships, flexible APIs, extensive customization options—you'll find even more possibilities in modern versions.
Community Support and Resources
It's important to acknowledge the tremendous effort the Drupal community is making to support organizations through this transition. The Drupal Association, along with various companies and community members, has stepped up to provide multiple support paths:
- Migration Modules: The Drupal community maintains a robust set of migration tools in core and contributed modules:
- Migrate Module for APIs and importing content
- Migrate Drupal and Migrate Drupal UI for simplified migration processes
- Migrate Plus and Migrate Tools for extended capabilities
- Migrate Upgrade for automated upgrade assistance
- The Migrate Wizard module, developed by contributors from Spain, offers a user-friendly approach to migration
- Acquia Migrate Accelerate (AM:A) module, created by Acquia that was EOL by them on April 10th, 2024.
- Extended Support Options: Tag1 Consulting and Pantheon have partnered to provide extended security support for organizations needing more time to migrate. HeroDevs offers their "Never-Ending Support" (NES) program for Drupal 7 sites beyond EOL.
- Migration Partner Program: The Drupal Association has established a program connecting site owners with certified migration providers, ensuring organizations have access to experienced help.
Looking ahead, I believe there's potential for collaboration between tools like the Migrate Wizard and AM:A to create something even more powerful for the community. These initiatives demonstrate the Drupal community's commitment to supporting users through this transition.
Different Sites, Different Needs
After seeing these various support options and working as a Technical Account Manager for nearly ten years, I've observed that migration strategies often depend on how organizations use their sites. Here's how I typically categorize sites to help think through migration decisions:
Business-Critical Sites
These directly impact the bottom line. Think e-commerce platforms or subscription services where downtime means lost revenue. From my experience, these sites often make the most extensive use of Drupal's powerful framework capabilities.
Regulatory-Important Sites
While these might not directly generate revenue, they serve crucial compliance functions. I've worked with several organizations where maintaining specific standards and security levels was non-negotiable, even without direct revenue impact.
Brochure Sites
These showcase your company's services, team, and general information. While important for your online presence, they typically don't handle critical operations or complex data flows.
Hobby Sites
Personal projects or community platforms. These often have more flexibility in terms of migration timing and approach.
Migration Tools: The AM:A Experience
Let me share a real story about Acquia Migrate Accelerate (AM:A). While at Acquia, I had the opportunity to work closely with Wim Leers and Angie Byron during the module's development. The tool takes a unique two-part approach:
- Site Creation and Setup
- Part of the tool is developed into the Acquia CLI
- Uses a vetted list of modules maintained in the Drupal AM:A module
- Auto-generates composer.json for your new Drupal 9 application
- Creates the correct structure for your initial project
- Migration Interface
- Provides an intuitive interface showing migration dependencies
- Helps manage prerequisites (like migrating files before media entities)
- Offers detailed error reporting for failed migrations
- Allows rollback and retry capabilities
- Shows clear progress as you run migrations
During the beta phase, we used AM:A to migrate one of my client's largest sites—tens of thousands of pages—from D7 to D9. This experience helped improve the tool itself. For instance, when the composer.json generation broke due to the site's large number of modules, we worked with the team to resolve these issues, helping shape the tool's development.
What impressed me most was accomplishing this massive migration without requiring a dedicated backend developer. The interface made it clear what needed to be migrated first, what had failed, and why—allowing us to clean up data in the D7 site and retry migrations as needed.
Making AM:A More Accessible
Based on this experience, I see several opportunities to make AM:A even more valuable for the community:
- Decoupling Site Creation
- Move the composer.json generation from Acquia CLI into a drush command
- This powerful feature shouldn't be limited to Acquia customers
- Module Maintenance
- Keep the vetted module list current
- While this requires manual effort, it becomes less critical as more sites migrate
- Remove Platform Dependencies
- Make the tool fully platform-agnostic
- We successfully used it with Lando and DDEV, proving it doesn't need Acquia-specific tools
Custom Code Considerations
Through my experience as a TAM for almost 10 years, I've noticed an interesting pattern in custom code. Many organizations may have numerous custom modules, but it's worth asking why they exist.
In my experience, most clients actually don't need custom modules. If you find yourself with many custom modules, you might want to evaluate if you're either:
- Using custom modules for functionality that could be achieved with Drupal Core
- Or genuinely taking advantage of Drupal's framework flexibility
If you developed multiple custom modules because your site truly needed that level of customization, that's actually another reason to stay with Drupal - you're making good use of its power as a framework. After all, if you invested in all these custom modules, your site is likely vital to your company's success, right?
Custom themes are a different story. Your theme is what makes your site uniquely yours, reflecting your brand and user experience requirements. Having a custom theme is more common and often necessary. This is one of the less complicated parts of the migration effort, though it still requires attention.
When planning your migration path, this distinction between custom modules and themes becomes important. While you might need to rethink and potentially simplify your custom module architecture, your theme customization needs will likely remain consistent even in newer Drupal versions.
The Retrofit Option
Matt Glaman's Retrofit is an innovative tool designed to solve a critical migration challenge: running existing Drupal 7 code on Drupal 10. It acts as a compatibility layer, allowing your Drupal 7 custom modules and themes to operate in a Drupal 10 environment without requiring an immediate full rewrite.
This approach offers an interesting complement to migration tools like AM:A. In my view, this opens up practical possibilities:
- Migrate your content using AM:A
- Use Retrofit to maintain existing custom functionality
- Gradually modernize components as resources allow
This approach particularly appeals to me because it lets you control the pace of modernization while maintaining site functionality. Rather than rushing to rewrite all custom code, you can focus first on moving your content and data, then modernize your custom modules and themes as resources and time permit.
Choosing Your Path
Based on your site's role (and resources), here's how I'd approach the decision:
Business-Critical Sites
You have two viable paths:
- Full migration with proper resource investment
- AM:A + Retrofit as a stepping stone to modernization
Both keep you within Drupal's powerful framework while managing risk differently.
Regulatory-Important Sites
Consider AM:A + Retrofit to maintain compliance while managing the transition's pace.
Brochure Sites
Wait for Drupal CMS (formerly Starshot). The upcoming Experience Builder and AI features could make rebuilding simpler than migration.
Hobby Sites
Explore all options, keeping in mind Drupal CMS might offer the simplicity you need with room to grow.
Looking Forward
The Drupal ecosystem continues evolving in exciting ways. Between Retrofit's innovation in backward compatibility and the upcoming Drupal CMS initiative, the future looks promising. Migration isn't just about moving content—it's about preserving and enhancing the functionality that made Drupal the right choice for your needs.
Remember, this is based on my experience helping organizations through migrations. Your specific situation might call for different approaches, but I hope sharing these insights helps you chart your path forward.
Añadir nuevo comentario