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?
- Q1 2014 targeted release date
- See http://drupal.org/documentation/version-info 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?
- 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 (?)
- http://drupal.org/node/1144136 - 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
- 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
If not:
- retire
- wait for Drupal 8 (life cycle)
- move to something else
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: |
|
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: |
|