Have you ever had a chance to work on a project so bad that you would rather build it from scratch? I know you did. Like I did. The first thing that comes to your mind is: "Whyyy? "

In Drupal world we tend to leverage contrib modules to quickly build our site structure. This is pretty handy, but it also comes with a great responsibility. It's so easy to take a wrong decision of field type, choose a bad module or go in a wrong direction on early phases. This might lead to custom coding, patching and workarounds that will quickly make the project unmaintainable.

In case you don't have content yet, which is rarely the case, you would just get rid of bad modules, fields and code and replace it with good ones, but in most of the cases you're approaching the deadline, or you're already live with tons of user-created content. How do we keep the content? Here comes Migrate module.

From here you have 2 paths:
- Wait for Revamp project and get a change to rebuild everything from scratch. It might be a new Drupal installation and a migration process.
- Start fixing your stuff now! Building new content type structure and migrating content from one entity to another.

During this session we will discuss both cases.

Migrate module is a framework for doing migrations in Drupal. It's part of Drupal 8 now and Drupal 7 version is very popular and highly used for projects of any scale and complexity.
There is a Migrate Drupal-to-Drupal module that does even more. It provides basic classes for Drupal migrations, knowing how Drupal tables are structured and allows users to easily configure a Drupal migration in minutes.

The best part of Migrate is that it's OOP and you can extend it with your own logic. During this session we will take a look into:
- little of basic Migrate concepts
- practical examples of Drupal-to-Drupal migrations
- migration scripts using MigrationBase
- building your own Migration frameworks and reuse code as much as you can

I will demo a mini framework that facilitates D2D by allowing you to extend your source object with fields from multiple entities, so you don't have to query all the fields in SQL. This allows users to migrate multiple fields from multiple entities into 1 single destination entity without creating a lot of overhead with hundreds of migrations.