 Hi everybody. So today as you mentioned, we are talking about migration to the public. So first we will introduce ourselves. So I am Mohamad Jhansi, I am from Hyderabad and I have been associated with Drupal from version 4. We are working with projects for 5, 7 and now it is Drupal. And I am currently working for a new solution and I am from master and I am also a technical master. And I am an active member of Drupal. I am mostly known as Rasi from the community. So it is a very important question. Yes, and I also made Drupal a very important thing. Hi guys, this is Thakrapani, I am from Hyderabad. I work as a Drupal architect as a solutions. I have been working with Drupal since 2009, that is Drupal since 2009. And then I got the Drupal code as well as the activities. I lead a Drupal manual community. It is actually a contribution track in Drupal and Asia as well. Other than Drupal, I have been working with Goalang and Elixir. Anybody who is going on Goalang or Elixir would like to catch up with you. A brief overview of what we will be covering today. So we will basically be discussing of why migrate to Drupal 8 is required actually. We will talk about the reasons for migrations and what are the points that are required if you consider different migrations to Drupal 8. Then secondly, you may be hearing in Drupal mostly about updates, upgrades and then you are telling of migrations. So what are the differences between each of these? Why different technologies are being used? There are different models that we have support in Drupal 8 currently. We will talk about those. There are the contributed models that is going to help us in migrating to Drupal 8. What are the main contributed models we will talk about in that? And we will basically give you an overview of those. Then the planning. Basically, whenever we say about migration, the most important thing is planning a migration project. Since that we will go into planning a migration project, we will discuss on that. Then we will say how we could do the migration. Using this simple user interface, how we could do the migration. We will take you through that. Just go back now. Oh, sorry. And then we will also discuss about the rush command line tool for Drupal. Using rush, how we could do the migration. We will also talk about that. Then we will also take you through some of the known issues that we are encounter while doing the migrations. We will talk about that. Before we go further, we would like to know who we are talking to. How many of you are site builders? That's a lot. How many of you are modular developers? How many of you worked with migration in Drupal 7? That came down a bit. How many of you are already familiar with Drupal 8? Far less. I think we have a mix of audience over here. We will be covering the entire process of migration. What are the modules involved and how it can migrate your site from D6 and D7 to D8? The first topic is why migrate to Drupal 8. There are quite a few reasons. How many of you know that Drupal 6 is reaching its end of life? That's a good thing to know. Basically, in the community, whenever a Drupal version is released, currently whenever you say Drupal, it refers to the current version. The current version in the community is 8. Drupal always supports the current version and 1-1 version, which means the Drupal 4 support will only be available to the Drupal 8 and Drupal 7. So the support like security fixes, bugs, updates, anything to Drupal 6 is actually being stopped or officially it is going to stop in one week from now. So that means that all the sites which are running on Drupal 6 does not get any more security updates, which means they are vulnerable to security threats. You will not be getting any bug fixes. If there is any fix that you wanted, which you had found in your Drupal code, you would not be getting much help from the community. That's basically no more support for D6. Now, once again, here basically there are two things. There are some people who would be running Drupal 6 sites and there also people who are running Drupal 7 sites. Now, migration to Drupal 8 is very much recommended for Drupal 6 sites because of the so I will mention reasons. Now, for the Drupal 6 sites, there are still three options that you have. One of them is basically like if you notice there are few companies, third party companies which will be providing you support for Drupal 6. It's a paid support. It's like since there is no support from the community, there are companies who are doing the business by providing you the support to Drupal 6 code. So from there you could still be taking the support because you don't see a viable option currently in upgrading or migrating to Drupal 8. So you could still go for the option one. Then the second option is to upgrade to Drupal 7. Because from 6 to 7 is like very much already available everything, you could always go with that option. Which anyway, again, if you look at Drupal 7 support, you have available till 2019 which is three years from now. So that is one option you have. Then the third option is migrate directly to Drupal 8. Our recommended option we say, recommend to migrate to Drupal 8. Drupal 8 is mainly because of the so-called features that are available, one. And secondly, the support to Drupal 8 is long, longer. At least for 6 to 8 years, your site could be secured and there is no requirement of maintenance cost that you have to enter again and again. So that is one of the good options. And when you talk about new features of Drupal 8, I think many of you are aware about the in-place edits, the responsive mobile-first design, and then the restful services that has been currently supported in core. So there are quite a good features in Drupal 8 that is going to be there. And also here one thing I would like to mention is, the effort to migrate to Drupal 7, upgrade to Drupal 7 or migrate to Drupal 8 is not the same. But if it 10 to 20% of additional effort, if you could spare now, you could directly migrate to Drupal 8 instead of Drupal 7 and can take all the features of Drupal 8 as well as keep the site secured. So that is very important. If you go for Drupal 7, you will have to upgrade again when support ends for Drupal 7, when 9 comes. But if you spend another 10-20% of effort, that is not because of the migration difficulties. The migration is much easier, the core migration. The additional effort would be to migrate over customer and contributor modules. Because the Drupal 8 module, you might not find all the contributor modules ready in Drupal 8, but it is worth it. So your site will be secured for next 8 to 10 years. Coming to these terminologies, and basically update, when we do the updates, in Drupal again we have in versions like we have major version and then a minor version, like 6.x they say, the x refers to the minor version, whereas 6 refers to the major version. So whenever a security fix has been released or whenever there are updates to the core, a minor version gets incremented. And for updating you think, you basically run an update.php in your Drupal site. That is basically known as an update. Whereas upgrade basically between major versions, 7 to 8 or 6 to 8, it solves an upgrade. Because the upgrade basically do it whenever there is a change in major version. And Drupal only changes the major version when there is a change to the core. Architecturally if there are changes made to the core, then only the major version gets changed. When you say upgrade, basically it is like in place code upgrade. Basically what you do is, you have a database of your D6 site, you place the Drupal code on top of it and then run the upgrade upgrade. Migration is not about the code, it is more about the configurations and the contents that you are actually migrating. So basically it means that there is nothing like you could migrate only from 7 to 8 or 6 to 8. You could run from any version, migrate to Drupal 8. Because it is only the contents and configurations that are being imported. And in create, the only supported method is migration. You do not have an upgrade. From this end to create, what you could do only is migration. So with respect to Drupal 8, if we say upgrade or migration, both are interchangeably used. It means migration. There is no in place upgrade support for Drupal 8. Look at the kind of modules or the support that we have in core of Drupal 8. If you are looking at Drupal 6 to Drupal 8, what you have is the core. Obviously the core can be upgraded. Along with that the CCK. Now many of you who has worked with Drupal 6 might know that CCK is a contributed model or was a contributed module at that time, which has been got into core in Drupal 7. So if there are sites running Drupal 6, then you need a support to migrate that CCK modules to Drupal 8. And the support that is already available is CCK, link, email, phone, image cache. All these are directly available with the core migration. So Drupal 8 core if you use it and then run the migration, all these can be directly migrated to Drupal 8. And if you are looking at Drupal 7 to Drupal 8 migrations, then basically you could migrate the content, the users, taxonomies, logs, manos and all this can be actually migrated. When you say these core migrations about, basically it means that in the core itself all these features for migration is available. Now what if you have to migrate some other things which are not part of the core? Then that's when comes the, let's start upon first the core migration modules which we are talking about. Migrate, if you had worked with Drupal 7 if you had done the migration, you had actually a contributed module which is currently moved to migrate, moved to D8 as a core module. It actually provides a framework and an API to migrate the content and configurations. Migrate Drupal. Yeah, migrate Drupal. This is actually in Drupal to Drupal migration module. If you have seen a Drupal to Drupal migration module in D7 which actually helps you to upgrade or migrate from one Drupal site to another. This also has been moved to the core. They call it as migrate Drupal and it again supports to migrate content and configurations. Both of these are migration frameworks which are moved into Drupal 8 core wherein migrate provides the core migration API to migrate Drupal as well as non-Drupal sites to Drupal 8. And the migrate Drupal is something which is built on top of the migrate for Drupal to Drupal migration. Also look at the contributed modules of Drupal 8 which is going to help us in migration. So first the Drupal upgrade. Yeah, it basically provides you all the tools that is required for you to do and migrate. So if you just install this module and run slash upgrade you could do the migration process. The interface. From the interface basically you could do the migration. Just say slash upgrade and you could see the options what all the migration that you are going to do. And it also supports to Drupal. Then the second is the migrate tools. Basically this is also another contributed module and this actually provides you a few additional commands which you could once you install this in the UI you could see more options for the migration as well as using the Drupal you could do many other options like you have a status you could check the status of the migrate or you wanted to import only a specific migration from Dsum to DA. You could specify that migration thing. All those new commands the commands is going to help you. Without migrate tools you would not be able to do it. You could just directly migrate without any options. Then migrate plus this is another contributed module. Basically this is more required if you have to write your own custom plugins or migration plugins because not everything is available for migration. So that is one thing. So this actually extends the core migration framework. The migrate module that we have in the core you could use that to you could use this module to extend the migrate framework. Migrate module. It provides you API also for grouping the migration. So when you are running the migrations you wanted to group few migration and then run them. Then this is the module that is going to help. And during the migration since you have been migrating anywhere to a new site you wanted to make few changes before you could migrate. You could manipulate the incoming source data as well. It gives you examples on how you could do it. You could have a look at it. Then one more module is basically a migrate manifest. It gives you a rush command. It's basically like you could create a migration template and then using the rush you could run this. So let's have a look at what the migration workflow will be. So initially you need to prepare for migrating your site Drupal 6 or Drupal 7 site to Drupal 8. So there will be a list of steps that's what you need to do or the planning. So once that is done you will be running your migration with UA as well as Drush. You can choose which method you would want to proceed. So once you choose that and run your migrations so the migration will be run and you will review whether if all the migrations are successfully run or not so based on the migration messages you can decide what is the next step is. If everything is fine you can just it's done and you can just uninstall all the migration related modules. If it is not and if you are happy I mean if there are still migrations which are missing and it's not complete you can rerun the migrations and if you're not happy with the migration process you can actually roll back your migrations. So we'll see how each of these will be done. So as I mentioned you'll have two available options. One of them is going with the user interface where you don't need to worry about the command line or Drush what we are talking about. You can just use the user interface and which will be very easy and simple but it will take a lot of time to run the migrations whereas the Drush option is robust and much faster. And also allows selective migrations with Drush that's one important thing to know. And as you know Drush also requires additional modules by default for the running the migrations with user interface. You just need core migrate, core migrate Drupal modules and migrate upgrade module which is also called as Drupal upgrade module. For Drush you need additional modules like tools and migrate plus or migrate managers. We'll get in detail. Here actually when they said about selective migrations basically when you are able to roll back you had migrated but then there are few issues that you had faced. So we had rolled back a few things. Though using Drush you could select only the specific migration that you wanted to run and then you could run that. That will be very helpful when you have been migrating and then you are facing issues. Again you don't need to do the entire migration. It would take a lot of time because you have to import the content and content is going to be in thousands and sometimes in millions. So executing an upgrade with UI so you need to install migrate upgrade module which is one UI at the path slash upgrade. It also provides one Drush command as well. So for doing an upgrade with UI you need to install the migrate upgrade module and go to slash upgrade page where it will ask you for credentials of your legacy database. So if you are planning to migrate your Drupal 6 site you need to give access to your Drupal 6 site which can be accessed from your Drupal 8 site and if you are planning to migrate your Drupal 7 similarly you need to give access to the same database. You don't need to have a complete instance of your legacy site. You can actually keep your just the database which is accessible to your Drupal 8 instance and you can still run the migrations. And in this particular page in the slash upgrade it will initial once you give the database credentials of your legacy DB so it will check all the available options and configurations and give a summary of missing upgrade paths. So we have seen in the earlier screen what are the support which are provided by the code migrate module. So it will list down all the missing upgrade paths and it will also list down the summary of available upgrade paths which means it will just tell you that these are the migrate paths which I will be running and there are lot of them which are missing. So if you are having lot of contributed modules in your Drupal 6 or Drupal 7 site and if you are not having any same modules in Drupal 8 which provide the migration plugins, they won't be there. So it will tell you that these migrations are missing but these are the available options which I will go ahead with. So this is the screen of the credentials where it will ask you for the database details as well as it is similar to the installation where you give credentials of your database. Here you just give the migration site from where you wanted to be basically migrated that is 6 or D7 site credentials. So this is the screen where it will tell you missing upgrade paths if you can see. So all these plugins are missing. These are the available upgrade paths. So that's with you. There is not much to do there. All you have to do is just go to slash upgrade and give the credentials of your source database and files and it will just run the upgrade. It will take a lot of time if you have a lot of content in your D6 site and once it is done you can just finish in the same page and if it is not complete you might need to re-run the upgrades again. So there is not much to do here as we are talking about. That's exactly why there are a lot of contributed modules. Actually if you look at this upgrade the way you could have a look at this maybe you are not planning for migration right now but you could still have a simple create instance and run this give the your D6 or D7 site credentials and have an overview of what exactly are missing so that you could see how much effort it would be required for you to plan and migration. That would give you an idea. So many paths are still missing. So we have to wait or we have to keep track of if you could do the upgrades or if you can contribute the Drupal 8 by porting these modules. That is going to help a lot. Okay. So if you are planning to execute your migration with Drush you need to install the latest Drush. Maybe you can use Composite to get the latest version of Drush and you need to install the migrate-upgrade module at least. So this is a contributed module and also migrate tools if you are planning to run your migration more than once. Yeah. So there is a in Drush we still have a couple of methods one is a simple method so where we will use migrate-upgrade. So this is generally used for migrations with Drupal templates and with a configured source site. So this executes all created migrations and imports content and configurations at once. And if you are don't want to run the migrations together so what you can do is you can initially run use the hyphen-configure only option where it will just create the migrate configurations but it won't import any content or sites configuration. So you can just create migration configurations which will give you an overview of what all migrations or what all content and configurations will be imported into Drupal site. So with migrate-upgrade this is the command you can use to migrate all your content from your legacy db. So drush-upgrade-legacy-db where you need to give username and password of the legacy database and the database name. And legacy root is something if you have a site up which is accessible from your Drupal 8 instance you can give the URL of the site. So this will be used to pull the files from the public files. So as I said if you are using hyphen-configure only to create migrate configurations and not importing all the data at once so you can have a look at what are all the migration files that are available by using drush-migrate status. So it will give you a list of all possible migrations you can review and then run migration selectively. So if you have used the configure only option so that will initially create your migrate configurations and then you can choose which migrations to run with the help of command-migrate-import. So if you want to run all the migrations you can use the option hyphen-hyphen-all drush-migrate-import hyphen-hyphen-all this will import all content and configurations at once. If you want to run selectively you can just give the migration name there. So drush-migrate-import migration name. So if you want to migrate only blocks you can do so with migrate-upgrade. So there is a complex method as I said which will involve creating manifest files. So you need to install a module called migrate-manifest so again the manifest file this will look like this. See it is almost similar to migrate-upgrade so what you need to do here is you need to list down all the migrations available in a yaml file which is called a manifest file. So this is useful if you want to run migrations in groups as I told. In the earlier option you can just run migrations with the available migrate options. So you need to create a manifest file so you can list only the migrations that you want to run at this point in time. So you don't need to list all of them and you don't need to worry about the order. So even if you are listing nodes in front of the and then giving user migrations later on so the migration will sort in the order of dependencies. If you want to import nodes it needs user references so it has to import users first. So the migrate is smart enough to sort the migrations and run in the dependency order itself. So D6 modules for listed migrations are must. So here in this case unlike earlier options we are listing the migration paths in a manifest file. So if you are listing a migration and there is no equivalent D6 module which is enabled in your Drupal site the migration will fail. So make sure if you are listing a migration the equivalent module in your system is available. Dush won't skip the migrations and tries to run everything because you have already specified that you need to run these migrations in the yaml file. So this is the dush command to run the migration migrate manifest option. dush migrate manifest legacy dv and the manifest.yaml file. So let's have a look at all the migrate dush commands and all the different options available. So we have been talking about migrate upgrade and option. So what are all the different options available with dush? So our migrate upgrade this is provided by Drupal upgrade module. And you can use it to upgrade from D7 and D6 to Drupal 8. And this generates migrate configurations from source site content and configuration with the hyphen hyphen config only option proper order. So by default if you run just migrate upgrade it will generate the migration configurations as well as run them and you can also choose to just generate the configurations first and then import the content and configuration. So the options are legacy dv url so which is the url of your legacy database and dv prefix. So if you are having any table prefixes you can specify that with legacy dv prefix option and the legacy root is the url of your drupal 6 site. And config only we have seen to generate just the migration configurations. And this also provides a command called migrate status so this will tell you the status of all the migrations. We have seen the ml file so those are the migrations that will be available. Let's say if you have already run a migration with the migrate upgrade and you want to see what is the current status of it. So it will tell you what are the migrations which are in ideal state, what are the migrations that are currently importing and you can have a look at that. And it will also as you have seen migrate import is another command that is provided. I think we have seen all this already. So the import options are all group limit feedback, idealist, update and force. So with the migrate upgrade you can choose to run all the migrations at once and you can choose to run the migration in groups and you can limit the number of migrations that you want to run at once and you can set the frequency as well and you can put a list of migration IDs. Rush to you that we have very good control over the migrations. You could decide on what exactly you wanted to run and what you could skip it for now during the migration. So using the rush is more recommended if you are basically comfortable with the migration itself and things then rush is the better way to do the migrations. It's the migration tools actually provides you all these commands. No. I think what I mean is let us say if we are running the migrations for blocks you need to make sure that your Drupal 6 site has blocks module enabled. It's the modules I am talking about. Yes. In D6 site you need to have the modules. If you need to run the simulated migration you need to have your block module enabled in D6. In D8 the block module is split into two different modules. Actually you are using a block module and you are migrating. So you need to actually have the required modules in Drupal 8. That's another option we will look at where when we are using Drupal manifest you need to have both the modules enabled in Drupal 8. If you have a block module let's say you are importing blocks for example. In Drupal 6 block is single module. In Drupal 8 there are two different modules. You need to enable both the modules. So which I think there is a custom block and another one module for the blocks. So in Drupal 6 there is only one block module. So it may not be one to one mapping when it comes to the modules. For example if you consider CCK there is a module in Drupal 6 and in Drupal 8 you don't need a CCK module. But if you are migrating fields you need to have CCK module enabled in Drupal 6. If you disable the CCK module you won't be able to import fields to Drupal 8. So that's what I mean when I say you need to enable the required modules. See by default you will already have your module enabled in your Drupal 6 site. Just make sure that you don't disable those modules when you are actually running the migration. Who doesn't tell me that you should enable it? See when you are running with Dresch you will get a lot of errors. So these are the precautions which will help you to not go to the error log and then see which failed and where it failed. It's obviously it will tell you why it failed. So you have to go back and then enable the module. Basically the migrate messages use you the list. So when you are running a migration on a site there will be huge number of messages. So you need to go through all the messages to find which of them actually succeeded and where it failed. And also the slash upgrade is going to give you the information at the beginning itself that what are the missing things and what are the things available. When it says missing it means that the migration is actually not mapping. So you can make sure that the particular module is enabled or not. So if you are running a migration and let's say it's stuck or something that Dresch has a command for you you can use migrate stop to stop that particular migration and the migrate reset status resets the status of your current running migration that will resets it to idle. So if you are running a migration and you are stuck and it's not proceeding you can just use Dresch migrate reset status for that particular migration and it will reset the status and you will be able to redo the migration. Migrate messages is something which will help you debug your migration status. So the known issues while running a migration from Drupal 6 to Drupal 8 so there is a story content type in Drupal 6 so in Drupal 8 it's named as article but it won't import the stories to article it's treated as a different content type and it will create a new content type called story in Drupal 8 so the article is not fetched. There is one more thing that we need to understand was when we have been migrating or upgrading from Drupal 6 to Drupal 7 what we used to do was we used to actually configure the required configurations in the Drupal 7 and then you run the upgrades but here you would not be doing anything you just have to have a fresh V8 installation site and then run the migrate so it means it is going to create the required content types, the fields the cck configurations whatever you had done everything will be done during the migration that is why it is migrating the content as well as the configurations into the new Drupal 8 site. If we had done anything on the Drupal 8 site before and then if you run the migrations it is going to overriding so whatever migration you might have done it all will get lost and it will get overrided. So the page content type will be migrated to the basic page and if you see your fields missing just visit the edit form of your content type and they might be just disabled so they will definitely be migrated to Drupal 8 you just need to enable them in the form display of your content type. The other thing is the image nodes and file fields are not migrated properly when you are running a migration from Drupal 6 to Drupal 8 so the files are migrated but the files are not mapped to Drupal 8 properly so that is an issue which is still in progress and with URL aliases all the URL aliases work perfectly right but there is one case where if there is a language which is there in your Drupal 6 site and the language is not enabled in your Drupal 8 site all the URL aliases won't work unless you enable that particular same language in your Drupal 8 site once you enable that all the URL aliases will start working and another thing is in Drupal 6 there is an option called menu primary source and secondary source they are no longer available in Drupal 8 so they are not migrated to those variables and profile categories if you are using profile categories in Drupal 6 they are not grouped in Drupal 8 when you migrate by default and in the profile field a load values in Drupal 8 will be the sum of allowed values and current selected values in Drupal 6 it won't be just the allowed values and date formats so if you have any custom date formats in Drupal 6 they won't be migrating so the only available formats in Drupal 8 are default, short, medium and long if you are using any other formats it will fall back to the default format and text and input formats so if you are migrating all the different text and input formats which were there in your Drupal 6 side and you don't have the format available in Drupal 8 side your content will not be visible so your content is properly migrated to Drupal 8 but you won't see the content in the front end because of the input format so what you need to do is either enable the contributed module or custom module which gives you the filter format for Drupal 8 or just go to that particular content and edit and set one of the available input formats that will solve the issue a few more issues there is a daily savings time issue in Drupal 6 the methodology which it used to calculate the daily savings has changed in Drupal 7 and Drupal 8 so when you are running migrations you might face an issue with daily savings so it might not be migrated properly you just need to check that and there is no support for views yet and it's work in progress your views are not migrated and there is one more issue we have faced and it's mentioned in the known issues documentation as well so after your migration if your homepage loads and you see that your theme is still broken all you need to do is just go to slash user and then come back so that's one Drupalism I'm not sure yet why yes but that works so when you are migrating from Drupal 7 to 8 there are few known issues so the block dipes are not migrated and similar to Drupal 6 the menu options the primary source and secondary source variables are not migrated to Drupal 8 and views as usual and same is the issue with filters and most importantly the PHP filter model so it's not there in Drupal 8 so if you have any PHP filters in your legacy database so they will not work so it's strongly recommended not to use the PHP filter again in Drupal 8 so if you still need you need to install the PHP filter model so after the migration if you are happy with the migration you need to uninstall all the migration modules and if you are not you must re-roll otherwise you can actually re-run which will I mean if your migration has stopped in between and you need to process so generally if you are doing the migration with UI so you need to actually re-run the migration couple of times so here are the documentation I think the Drupal.org has a very good documentation on how you can actually go ahead with your migrations questions yes there is a missing path on the block so does that mean that blocks in the D7 won't be imported to the yes yes so if you see any migration path missing in your UI screen that means those migrations won't be done for sure but even if I think block is in Drupal core I guess yes so you won't get that problem yes so if you won't get that problem generally I am just taking that as an example so that you know there is a block which is one module in Drupal 6 and there are two modules in Drupal 6 yes okay yeah it will work yes yes it will work by default I mean that is my issue was with the attachments that you use if you are using those then the files are going to be migrated but then the association between the node and the file is missing currently if I use views itself don't get migrated yet but image cache, image files are migrated hello sorry site is migrated d7 to d8 it will meet all security aspects of the government of India like validations cross script yes I think mostly yes because in the d8 validations and encryption modules are not available in d7 it is available which modules are talking about if it is a contributed module they might take some time to have a d8 version before we run this migration basically if you had like 10 modules migrated to Drupal 8 you need to have those 10 modules available in Drupal 8 as well some of them might have been moved to code and it would be available directly some of them you had to actually port it or if it is available already in d8 you had to install them and then do the migration so if d7 has having 10 modules which is meeting the government policies then obviously the equivalent d8 modules will do the same because the functionality will not be changing any yes by default it will work no issues if you have a profile module as I said there are few issues with the profiling but otherwise all the users will be migrated only with the users will not be having any problem but if there are users and then there is a profile module configured with the users then they have to refer to that no issues section few things that is still there and what is happening so is it a good idea to move first to the Drupal 6 side to Drupal 7 then migrate it to Drupal 8 we strongly recommend to directly migrate it to Drupal 8 as we mentioned earlier so one of the important thing is that Drupal 8 has a lot of new features so if you are migrating it to Drupal 7 you will have to again migrate it to Drupal 8 or wait until Drupal 9 comes that one and the effort is almost same the only additional effort you will see while moving to Drupal 8 is because of the lack of contributed module so you have specified about migrate underscore upgrade so that is a command as well and it is a module as well it is a module which provides UI as well as the brush command and obviously you have to do a analysis before you decide on whether you wanted to go with the EA because if your site is using a lot of contributed modules then one of the solution is to go with Drupal 7 because not all the modules has been ported to Drupal 8 but if there is not many contributed modules then the recommendation is to put in the effort to migrate to Drupal 8 directly then doing it to Drupal 7 Is there any kind of support available for migrating custom modules Symphony has been accepted as the codebase for Drupal 8 Sorry I was saying support for custom module migration Does this process has to be done manually or like Yes, what you need to do is you need to create custom migration plugins So if you see some contributed modules you will see there will be migration plugins within the module directory So you will need to write a similar plugin for your custom modules as well Contributed module I think Drupal 14 some contributed module was there which is actually going to help you to migrate your module or upgrade your module from Drupal 7 Yes Sir, but the list of the migrating Drupal 6 to Drupal 8 As known issue is too high but if I migrate to Drupal 7 first and the content will be migration will be easier only the block content, the views will be available if I migrate to Drupal 7 will be available in Drupal 8 So in that case most of the configuration will be saved manual work will be saved later on It's not what it means So when I say the support for migrating views is not available your views are not directly migrated to Drupal 8 So there is a lot of work which is happening to provide support for views So we should wait for Maybe you can wait for couple of months but getting views into Drupal 8 I don't think it will take a lot of time It's just that it's not done with a click So you can still get it done But the thing is there is no full support It's still not complete Maybe the D6 to D8 the issue list looking to be quite vague but if you actually go through those points they are very minor ones And only any Drupal developers could spend few times they could actually solve that and can give it as a patch So definitely that's where we are mentioning there will be a little more effort when you are actually migrating to Drupal 8 But if you compare it in the long run and the benefits that you will get with Drupal 8 it's definitely recommended to migrate to Drupal 8 So what about the features model that we built to from local to server So we use the features to import and import the configuration to server So what about that? So you will be happy to know that you don't need features anymore with Drupal 8 because Drupal 8 has its own configuration management which is handled in core itself So you are seeing Yes See when you actually choose between UA and Drush there is a recommendation you can actually go with Drush Yeah So if you know that you need to run your migration selectively then I would suggest go with a manifest where you can actually choose your migrations and just run one by one So just run the migrations of users first and maybe blocks and then you know validate them properly So if you want to run everything at once you can directly go ahead with a migrating port Okay Okay So that's exactly what I am talking about If you know what you are doing then you can actually try migrate manifest Because in migrate manifest you are telling migration API to run these migrations So you are telling that these are the migrations I want to run but in the migrate import option it will tell you what are the options available you are just picking what I want to run That's the difference So with migrate manifest you need to have more control over your migrations but that is a suggestion only if you know what you are doing Yes Okay See if you are actually added fields with custom modules you need to write custom plugins to migrate data of custom fields from day 6 to day 8 So generally if it is with the UI you have added and not with the custom modules they will get migrated Issue The core migration supports fields so it might not be a problem If it has not migrated there may be some other issue Yeah We had actually with migrate Yeah it works Of course Yeah So my question is if I am using the front end migration I am using that deployer In that case is it progressive or it is a complete one time migration That is assume I have millions of content or thousands of content See if you have a lot of content we strongly recommend to use Drush Drush also whether it will be progressive Yes it will be progressive That is where we have where we have these commands to stop or then look at the migrate messages You do not need to worry that it might break down in the middle So the migration API is smart enough So even the best part is you can do a migrate upgrade I mean meaning let us say I am running migration right now and let us say my site is in production and there will be a lot of content that is getting added to my Drupal 6 production site I will take one month to configure my Drupal 8 and run all the migration There will be some content which is added to your Drupal 6 site right So with Drush option you can just rerun your migration It will check what is the new content that is being added What is the old content that is already migrated And it will only migrate the new content Not only that it will also identify the content that is updated So not just the old and new content it will also identify the updated content So if you have updated any of the content in your Drupal 6 site from the previous migration to this migration it will identify and update that content as well So it is safe to say that it is a progressive migrate That is pretty cool The next thing is as you mentioned that you have already migrated a couple sites in 6 to 8 So if I am asking if I have a site with 1000 of content only then how much time it will take to migrate on an average basis See 1000 is actually hardly nothing with the OI it could take with 1000 it will be very big it will be very big and not more than 1 hour Because if I need to provide some estimate to my customer on an average time if there is no failure what will be the time See the thing here you have to understand was it is not about the content that is here to migrate but it is more about the customization that you had done in your D6 site which also required to be ported over to the D8 If they are just content and with the normal available modules which already you have in D8 then it is very simple migration there will hardly any effort that will be involved You could either run with Rush it will be completed in a day or two with testing you could plan it But if there are more customization that has been done then you need to plan an effort of how much it would require for us to write and custom migration plugins in order for it to get it into the D8 That is something depends on the kind of customizations we had done So for 1000 or 50,000 rows it will actually the estimate won't change your effort won't change and time may be 1 hour for Rush to run that's it Basically my question why I ask this question we have a running site where the single content I have approximately 150 fields and the number of data is more than 4 lakhs and in normal insert and edit we are taking taking too much time 1 minute per 1 content So if I am going to migrate then what should I take care and how when I convince my customer that Again it will still be the same but the only thing is how much time the migration will run your work will be same otherwise it could be just that it might take half a day maybe to run the migration if everything else is done correctly So the important thing is do you have all the modules configured correctly how the migration parts for all your contributed and custom modules So that's where the estimation has to be based on the customizations and not based on the amount of content that you have irrespective of 4 lakhs content what you have to realize here is the 150 fields that you had mentioned that is actually the most critical Yes That 150 fields is normal a single note I mean normal article type I have created that field there is nothing that I have written a custom it is not recommended anywhere to create 150 is huge but yeah I have Drupal 7 site and I have a custom theme which uses dvls if I migrate to d8 what will happen to the themes So the migrate process won't help you with your templates they care of porting your themes So the migrate process will only migrate content and configuration So the porting of modules, themes, everything has to be done separately manually Yeah 6 and Drupal 7 same site with a lot of contributed modules content everyday most of them are customized which will be faster d6 and d8 are designed to be same Are you asking about So you have a d6 site and d7 site both d6 and d7 are I mean both of them are same See one thing I can say is so when Drupal 7 you still have support so you can still wait that's one option The other thing is when we are actually building migration paths so 6 to 7 is considered priority because in another 4 days you will lose support for Drupal 6 Drupal 6 sites won't have any support after that so it's Drupal's responsibility to provide migration paths from 6 to 8 So if you actually get all your contrib modules and core modules and have a table and look at 6 to 8 and 7 to 8 you will first get support from 6 to 8 and then 7 to 8 So it's safe to say that you will find a lot of d7 modules which doesn't have migration paths but you will find the same for d6 But you can wait for some more time because you already have a Drupal 7 site and then you can migrate them that will be better How difficult it is to like how really difficult it involves let's say 3 steps so what you need to do is you need to define the configurations where you need to specify what is your source for the data and how it has to be processed and what type of field it is let's say it's a text or not type of the field you need to define and then the process and also you need to define the destination so in your Drupal 8 what is it let us say it is cck in Drupal 6 let us say iframe there was a module called iframe so it provides a field whose type is iframe in Drupal 8 it is just a link so what you need to do is you need to specify the source which is your type is iframe then how do you want to process it what is the data you need to retrieve from it and how you want to store it in your Drupal 8 site but it's a simple example it depends on what you have in your Drupal 6 so I think the module you should be using should migrate place it has examples for simple custom migrations as well as advanced custom migrations with inline commands there is a nice documentation within the sample code and what it does in D7 migration migration of few drawbacks means that the multi-link file migrations are not supported in D7 so is that resolved in D8 actually the files there is an issue as I mentioned in known issues the file attachments are not linked when you actually migrate so you are saying you are talking about PO files see it's considered as file attachments at one level so the file attachments themselves are actually not linked in Drupal 8 so when you actually migrate those files are migrated but they are not actually attached to the node itself so there is an issue which is being worked on that's one and there is some issue with multilingual content as well so the multilingual content doesn't have full support yet I think we need to look into the issue queues and what's the progress see most of the issues I am talking about all of these are work in progress see actually here the D8 has a 100% multilingual support the only issue was when you are migrating the multilingual content from a legacy to the Drupal 8 there is an issue that is still being worked on so migrate plus allows us to move from one CMS to another CMS like its support like that actually the migrate model of Drupal 8 the code is built to migrate from any of the legacy system to the Drupal 8 whereas the migrate upgrade is specifically from Drupal to Drupal so in migrate 6 you find example code for how to build a custom plugin so you can use that to migrate so as you specified we could migrate the content and configuration so would it be possibility that where we are not able to migrate some of the third party configuration from D6 or D7 to D8 is there any possibility where we exclude some of the third party configurations what do you mean by third party configuration just like suppose we are using some e-mail servers and we don't want to migrate those configurations from D6 or D7 to D8 that's where elective migrations you could use and skip those particular things from the migration file thanks thank you