-
1.
The long and the short of
migrating to Drupal
By Jeremy French
-
2.
Introduction
• Part I
– 10,000 ft view of migrations
– Pretty pictures
• Part II
– Detail about migrate module
– Code
– No pretty pictures
-
3.
Typical Migration Progress
-
4.
by toastforbrekkie
I'll give you my proprietary CMS when
you pry it from my cold, dead hands
-
5.
Features
Two types of features:
1. Pointless features that users insist upon
2. Critical Features that users forget to mention.
-
6.
Migration Vs New build
Photo by echiner1 Photo by Alex Pepperhill
Replacing existing system is inherently more
complicated than building new system
-
7.
Functionality, go with the grain
Photo by Marc Arsenault
Don’t melt your Drupal
-
8.
Launch
• Big bang is only an
option
• Can migrate pages
and keep editing on
old system
• Can migrate traffic
gradually
Photo by Trey Ratcliff
-
9.
Shakedown
• Define a time after launch to address critical
bugs as they are discovered
-
10.
Part II
Detailed look at migration module, no more
pictures, but some code.
-
11.
Part II Look at migration
• Take Stack Exchange dump files and import
into Drupal site.
• Code available on github
https://github.com/jeremyfrench/se_migrate
-
12.
Migrate / Migrate Extras
• Provide a framework for migrating content
• Migrate contains the framework and
migration code for core types
• Migrate extras helps migrate data for popular
modules
– Flag
– Voting API
– Media …
-
13.
Migrate UI
• Like views_ui it dosen’t add any functionality
• Shows a list of active migrations and allows
you to run them.
• Also shows fields that are unmapped from
source and destination
-
14.
Mapping??
• Central concept is that of a mapping
• A migration class will map some data to an
entity/content type
• In a simple case ‘fields’ will be mapped to
fields in the content type
-
15.
Migrate Module Architecture
-
16.
MigrateSource
• Source can be anything built in classes are
– MigrateSourceCSV
– MigrateSourceList
– MigrateSourceMSSQL
– MigrateSourceMultiItems
– MigrateSourceOracle
– MigrateSourceSQL
– MigrateSourceXML
You can roll your own (for example from a
custom api).
-
17.
MigrateDestination
• Entity types Users, Nodes, Terms.
• Migrate Extras has things like files.
-
18.
MigrateMap
• Contains a mapping from an id in the source
system
• Used for keeping track of migrations and for
references.
-
19.
MigrateFieldMapping
• In simple case it maps a field in the source to
that in the destination.
• Useful in cases where there is a 1-1 mapping.
Often other tricks are needed…
-
20.
Lets look at some code.
-
21.
Summary
• Migrate starts quickly but functionality is more
difficult to migrate than content
• Cultural Change takes time, hand holding
helps.
• Migrate module is awesome.
-
22.
Questions Now (or later)
@JFrenchTweet
jeremy@jeremyfrench.co.uk
Thanks to everyone for making DrupalCamp
London!
Hi I’m jeremy. I’m here to speak to you today about migrating to Drupal. 30/70 What to expect when migratingLook into migration in general
This is pretty typically how a migration seems to go. Getting most of the content in is easy. Can be done in hours.Applying a theme and branding is pretty straight forward , in most cases. At this point everyone is happyMonths later, people are wondering why it is taking so long. Two reasons, Functionality which is much harder to migrate than content and and Details, the little outliers in the content which cause lots of headaches. Towards the end you are often working much harder, but the progress is much more difficult to see.
Not every user will want to move to the new system. Change is not liked very much in a copererate environment. I could fill this whole time slot talking about how people react to change, if you are lucky some people will be very on board but others will be disinterested and critical once things are live.
So migrating content is relatively easy, and will take the second part of this talk, but migrating features is hard.
Building a new system is easier in many cases than migrating one. Office kitchen analogy: Office kitchen was re fitted, was nice but I missed the old coffee machine. New one was probably just as good, but it
Drupal and it’s modules expect to work in certain ways, Drupal is pretty flexible. But you will have a tention between the expectaton from the exsisting systems users, and the Drupal defauls, some times these are pertty harmless, but be wary of hacking too much just to keep things the same. Imagine drupal is lego, very flexable and interoperable. But if you start melting bits to get it to work in a particular way you loose a lot of that interoperablity.
Often with a migration you don’t get to do a soft launch. There are ways to mitigate this. Beta to subset of users, read onlyMigrate front end while back end is still on old system (gradual traffic move from one site to the next with load balancer)
After you have launched, you can declare it a shakedown period. This gives you a bit of political legroom, many users will not have tested the new system will not have read emails about what is going to happen and will not be happy. If you can quickly address issues it will go a long way to giving them confidence and making them happy. Picture is of HMS astute which ran agground of the isle of Sky, but it was ok as it was in a shakedown period.