Drupal 6 to Drupal 7 Migration Worksheet

Transcription

1 Drupal 6 to Drupal 7 Migration Worksheet Rationale for This Document An upgrade of a Drupal 6 website is a complex proposition. As a general rule of thumb, many professional Drupal development teams approach a major Drupal version upgrade as a new site development project, and estimate anywhere from 60-80% of the original development resources (time, money) for the upgrade. For a migration to be successful, you will need functional specifications built by someone internal to your organization. By investing the time in answering the questions in this worksheet, you will increase your chances of a successful project. Goals: Determine the necessity of upgrading or migrating an existing Drupal 6 website Determine the scope, resources, and effort required to migrate a site from Drupal 6 to Drupal 7 Provide a high-level overview of various approaches to migrating or upgrading to Drupal 7 Questions to Answer: What do we have? Complete Audit document (Appendix A) Where does Drupal fit in our stack (re: other web technologies)? How long can we stay in D6? What s the risk beyond end of long term support? Do we wait for D8? August 2013 targeted release date See for how to choose a Drupal version Do we need to go to 7 now? If not now, when? What other advantages does D7 offer? What do we need to upgrade? Do we upgrade, migrate, or rebuild? What does upgrade mean? Core Theme Modules What does migrate mean? Why should we migrate?

2 Cannot build new features in D6 Better performance ( e.g., sites.stanford.edu vs AFS ) Outline of D6-D7 Migration Process Document functionality, features and relationships on the current site + wireframes Upgrade core or install new D7 Develop content types and views for D7 Re-build theme for Drupal 7 (possible candidate for outsourcing) Develop migration tool to migrate content from D6 database to new Drupal 7 database (best candidate for outsourcing) Migrate media object Useful links (?) - Migrating D6 Content Construction Kit (CCK) to D7 Fields Global Issues with Moving to Drupal 7: Data Migration (outsource?) Feeds Migrate Modules Theme Core Fields in core Entities Modules some modules have upgrade tools can cck be moved from d6 to d7 can views be upgraded or export/import via features? Training Redirects When / what / how to move to Stanford Sites Do we need to go to D7? If yes: Option A: Upgrade Definition: Replace D6 code with D7 code; run upgrade scripts on D7 database Good only for really basic sites Most like your old site

3 If not: Option B: Migrate Definition: Install new D7 site from scratch with new database; import content, Views, users, etc. Clean Codebase Old content can be left out Retweak IA Tweak Data Model Con: Content Cleanup takes time Are there migration tools that can be used? Outsource data migration? Option C: Develop new site Definition: Install new D7 site from scratch; no mass import of content, Views, users, etc. New Information Architecture New Data Model New Content Brand new hotness retire wait for Drupal 8 (life cycle) move to something else

4 Appendix A: Drupal 6 to Drupal 7 Audit Worksheet Technical Audit URL of Drupal 6 site: Who developed original site (in-house/external): Number of nodes: Number of users: Number of roles: Number of Views: Number of Content Types: Number of Contributed Modules: Number of vocabularies/terms: Number of nodes tagged with taxonomy terms: Custom Theme (yes/no): Number of custom theme templates (.tpl.php files): Custom modules (yes/no - number): Hacks (yes/no): Custom PHP (yes/no): Custom Blocks: JS Libraries: Feeds: Hosting environment (AFS, sites.stanford.edu, department server, external host): Number of vanity URLs / redirects: Performance modifications (Boost, Varnish, Pressflow, etc.): Search (Solr / Google, internal): Files on disk / DB:

5 Functional Audit Audit of existing content (using analytics, etc.) - what is our critical content? Critical functionality (e.g., data integration, etc.): Content authoring experience (e.g., custom workflows, dashboards, etc.): User Experience (admin and end users): Use of taxonomy: Data integration (importing and/or exporting data [Feeds, Services, etc.]): Permissions matrix (permissions, access control, Views access): Rules and triggers: Hosting environment (resources committed): Layout Architecture (Panels, DS/Context, block.tpl.php, etc.): Navigation Architecture (Book, Taxonomy): Data components (fields, attachments, files, images, etc.): Media Files:

6 Notes