Business and StrategyBusiness and Strategy

Migration: Smoothing the Move

Presented by Mike Ryan and Moshe Weitzman

Mike Ryan

• Drupal developer since 2003• Original author of Pathauto module• Primary author of Migrate module• Certified to Rock score of 8• Senior Technical Consultant at Acquia

Moshe Weitzman

• Drupal developer since 2001 (d.o uid 23)• 2nd most prolific contributor in Drupal history• Certified to Rock score of 11• Creator and/or maintainer of Drush, Devel,

Organic Groups, and several other projects• Director, Research and Development at

Acquia

What is migration?

• “Migration” might mean the regular seasonal journey undertaken by many species of birds.

What is migration?

• “Migration” might mean the regular seasonal journey undertaken by many species of birds.

• “Migration” might mean moving your Drupal site as a whole between servers or hosting platforms.

What is migration?

• “Migration” might mean the regular seasonal journey undertaken by many species of birds.

• “Migration” might mean moving your web site as a whole between servers or hosting platforms.

• “Migration” might mean the transfer of data and content from one platform to another.

What are we talking about?

• The big picture of a data migration project• The importance of communication• The unknowns, and how to deal with them

What aren’t we talking about?

• The Migrate module (technically speaking)

Project model

• Typical migration project – 3 participants:– Client with content to migrate from some other

CMS to Drupal– Site-building team – develops new site

functionality, designs and themes the site–Migration team – develops the processes to move

the content from old site to new site

The process

• Analyze – understand the legacy data• Map – line up the pegs with the holes• Iterate – implement, test, and refine,

repeatedly• Launch!

Analysis

• Design is top-down, working from the front-end

Analysis

• Design is top-down, working from the front-end

• The migrators need to work bottom-up, from the raw data

Analysis

• Design is top-down, working from the front-end

• The migrators need to work bottom-up, from the raw data

• There is always stuff not directly visible on the site that is important

Be thorough

• Get access to the full source data up front

Be thorough

• Get access to the full source data up front• Examine it closely, table-by-table and row-by-

row

Be thorough

• Get access to the full source data up front• Examine it closely, table-by-table and row-by-

row• Act like a 3-year-old – Why?

Be thorough

• Get access to the full source data up front• Examine it closely, table-by-table and row-by-

row• Act like a 3-year-old – Why? Why?

Be thorough

• Get access to the full source data up front• Examine it closely, table-by-table and row-by-

row• Act like a 3-year-old – Why? Why? But why?

Preliminary mappings

• Obvious: Source data subject => Drupal title• Educated guess – 98% of the status values are

“2” – that probably means “published”• Ambiguities – make best guess.• WTH? Annotate with questions.

Mappings, bloody mappings

• Migrator• Technical resource• Stakeholders• Site-builders

Iteration

• Implement the understood mappings• Staging server – let the team see the results• Refine and repeat

Launch

• A day or two before launch, run a full import into the to-be-production site. Sic QA on it.

Launch

• A day or two before launch, run a full import into the to-be-production site. Sic QA on it.

• At the designated time, set the old site read-only.

Launch

• A day or two before launch, run a full import into the to-be-production site. Sic QA on it.

• At the designated time, set the old site read-only.

• Run the final delta migration.

Launch

• A day or two before launch, run a full import into the to-be-production site. Sic QA on it.

• At the designated time, set the old site read-only.

• Run the final delta migration.• Final QA review.

Launch

• A day or two before launch, run a full import into the to-be-production site. Sic QA on it.

• At the designated time, set the old site read-only.

• Run the final delta migration.• Final QA review.• Switchover

Celebrate!

Elements of Success

• Start the migration development, with the analysis stage, as early as possible.

• Get the mapping meetings done as soon as possible after that.

• Communicate! All parties – stakeholders, site-builders, migrators – must be responsive to each other.

A typical question

• We’ve got 1,000,000 articles and 100,000 users – how long will it take us to migrate?

• But, if you think about it…

Estimation

• Which is harder to migrate?– 1,000,000 articles with 3 fields each, or– 1000 blog posts with 5 fields, 500 articles with 10

fields, 3000 forum topics with 7 fields, and 800 recipes with 15 fields (including complex fields like “ingredients” and “directions”)

A formula

• Basic: Number “migrations”, plus 5 X total number of fields, times a magic factor

• Refined: Taxonomy migrations count less, file migrations count more. Complex fields count more.

For the techies

• BOF: Migrate in Drupal 8 – 1pm Thursday in room 210

What did you think?

Locate this session on theDrupalCon Denver website

http://denver2012.drupal.org/program

Click the “Take the Survey” link.

Thank You!