Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie The long and the short of migrating to Drupal
Ähnlich wie The long and the short of migrating to Drupal (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
The long and the short of migrating to Drupal
- 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
- 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
- 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!
Hinweis der Redaktion
- 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.