 Okay, it's 3 p.m. Thank you everybody for coming. This is upgrading to Drupal 10 using the major API My name is Mauricio Dinharde, the slide deck and everything that I'm going to be presenting today Is already available. So you can go to that URL and from there you will get more content My username is dinarcon. That is my email. My pronouns are he and him. I am from Nicaragua And Nicaragua is very beautiful very hot And there are a lot of lakes and volcanoes I am a software engineer at agaric and I also an instructor understand drupal.com I enjoy reading traveling and learning languages both human and computer languages If you speak english, spanish, french or portuguese feel free to talk to me If you speak another language, I might not be able to reply As I said, I collaborate with agaric. We are a worker-owned comparative based in Boston, but we have people All over the place myself in Nicaragua. We have partners in Germany and here in the states in different cities I am very passionate about teaching I have written a lot about drupal migrations and I plan to just continue writing about other topics site building, model development Theme development in this website understand drupal.com for the most part the content is in english at the moment But I'm working on translating to spanish and french And I would also like to thanks pantheon for helping Me to get here to bits work to be present at the conference through their pantheon heroes program This is what we will be we will be covering today Triggering the upgrade process from the ui from the command line and how we can use The migrations that are automatically generated as a base for a custom migration If you want to follow along as I said the slide deck is already available And there are also companion modules like this session is sometimes presented as a full day workshop and The the code for the workshop and for setting up the whole project is open source is freely available So you can get it from there and by the end of the session I would like you to provide some feedback and that is the feedback link So let's get started Before going too far I just want to point out the fact that the major api in drupal core is an implementation of a design pattern called extract transform and load This is not exclusive to drupal. This is not exclusive to php There are a lot of documentations. I recommend the book on the left The data warehouse etl toolkit And the one on the right is a book that I wrote a few years ago About drupal migrations. Like if you don't know anything about migrations With this book, it's like one short article for 31 days and you will learn how to migrate content from different sources to different destination entities And just like general tips for working with migrations and debugging them As I said before this is sometimes presented as a workshop and there are recordings available So if you want to see like a hands-on demo, those are the links to to watch the recordings today We're going to talk about the process Give some general recommendations But if you actually want to see how to run a migration visually, that's that's where you need to go So let's start by preparing an upgrade and before going any further Upgrading in this context is if you have a drupal 6 or 7 side And you want to move it to drupal 9 or drupal 10 I'm going to explain what about you know those versions later on But just be mindful about this is what I'm talking about 6 or 7 to 8 9 or 10 So what do I recommend that you create an inventory of the modules using the source and in the destination sites audit the content and the configuration in the source side Understand the assumptions that the migrate api is doing be aware of some issues and limitations And know what is the scope of the system? So we're going to go over one by one As for the source site a modeling inventory. I highly recommend that you use the over the status module. This is going to You are going to install it in drupal 7 for example, and it is going to check all the modules that are enabled on the drupal 7 side if They are available or if there is a replacement for drupal 10 And you will get like different recommendations in this screenshot The address field was a module in drupal 7 that didn't exist in drupal 9 It was replaced with another one called address just address so you get You get the recommendation of you know, this is no longer available But you can use this module instead in the case of the date module part of Date in drupal 7 was incorporated into drupal core But some of the elements were not and you will also get a notice about that And in the case of the entity api You know, that is everything available in drupal core basically So you you get a notice about that one thing to be aware is that the operator status module checks That a module is available. It doesn't mean that it will have an automatic operate path. That is something different Just be mindful that being available doesn't guarantee that your data is going to be moved over for free or automatically In addition to Getting the lease of modules. I also recommend that you audit You know content types of vocabulary menus because many many times I would say like 99% of the work projects that I have worked on There is something to change either improve or adopt new features of Like new modules that are available A newer version of drupal or they just have some legacy content that they no longer need They want to change Some configuration. So it is very likely that by inspecting what you have today You are going to find out things that are no longer necessary or that you want to change in some way or another so From a configuration standpoint, but also from a content standpoint like You don't have to to spend too much time on it, but just You know Do a do a Basic review of what you already have and I have a template that I use In the in some of the projects udrupal.com slash size Side dash audit and again, it's just like high level like this is the list of content types This is the list of notes per content type. What do I want to do drop it replace it keep it? And basically for different Entity types I will I will do this analysis Something that is not an entity necessarily, but it's well it is worth checking it's like roles text formats images styles basically anything that Triggers are warning us to oh, I might need this module or I might Need to find a solution to this That I was doing before and it's no longer available Just like documented in one document and have that as a source of truce and as a reference to be used later on In terms of assumptions Of the api itself Let's for for the sake of this presentation So I don't have to repeat and a lot of different version numbers Let's say that we are migrating from Drupal 7 to Drupal 10 So your Drupal 7 side needs to be in the latest Stable release and Drupal 10 should be in the latest stable release In Drupal 10 there should be no content or configuration. You basically install the site using the minimal installation profile and You start the process from there And then if you want to get automatic migrations, you need to enable the modules In both the source site Drupal 7 and the destination site Drupal 10 We're again, we're going to go more in depth into each of these steps as we continue the presentation And Just be mindful that this is the assumption. This is the recommendation But sometimes life is not perfect. You need to dba it from the norm and it is possible, but this is the base That the migratory api is going to use In terms of scope You are only going to be able to migrate content and configuration automatically If you have custom modules that is not covered by the migratory api You can get either You can use either upgrade status or upgrade director to help with the process of upgrading custom code But that's not the migratory api responsibility And if you have a Drupal 7 theme basically you need to recreate it from scratch like the Template that was used for writing teams in Drupal 7 and in Drupal 10 is completely different And as far as I know there are no automatic, you know translations tools And in terms of issues and limitations This comes with a caveat Like everything that I say the next time that I present the session something has changed And one that changed for the better is views migrations in the past It used to be like oh, we don't support views migrations Automatically, you need to recreate them all I have worked on sites with literally hundreds of views and that was very painful to do manually But uh, locally now we have the views migration module it is I would say 80 percent like it will give you 80 percent there there Because views is so popular and there are so so many plugins that might be available for views in Drupal 7 That do not have a counterparty Drupal 10 It may not be able to get everything perfect, but for the most part It does a really good job in getting at least part of the views Migration automated in terms of filter format If there is one that is not recognized in the new site By default it will return an empty string the content will be present in the database You might need to you know do some cleanup after the migration But the data is going to be there If you use PHP module in Drupal 6 or Drupal 7 that is no longer supported for many reasons including security ones so We don't support that and If you already have content in Drupal 10 It is possible still to use part of what we will we will be talking about today But just be mindful that if you're not careful you might be overwriting content and relationships between content let's say that You know in my Drupal 10 site I create node 1 and node 1 was You know authored by user 5 And then I run the automated upgrade procedure and in the outside Node 1 was created by user 3 So you will lose who was the author of the note and the content that was already created before So just be mindful about that. There are a lot of different ways in which you can work around that But this is what the api assumes by default Now how do you actually perform the upgrade? There are at least two different options One is through the user interface and the other one is through the command line If you do it from the user interface, it works out of the box. You don't need any contributed module for it to work But it is not customizable. You basically get a one-to-one copy of the previous site as much as Drupal can do There are things that might not be able to be automatically migrated but Drupal will do its best effort and you get What Drupal could do and you cannot change much of the process itself If you go with the command line route, you will need rush and a couple of contributed modules But it is very customizable And I think like every migration that I have worked on I end up doing command line migration because it is more flexible And I want to highlight that this allows for content model changes. So Most of the time I need to do that So Let's see how we do it from the user interface You install Drupal 10 using the minimal installation profile In Drupal 10 you enable migrate migrate Drupal and migrate Drupal UI So migrate is the core of the API Migrate Drupal gives you a lot of source and process plugins that are specifically for Moving data from a Drupal 6 or 7 site and then the migrate Drupal UI is the interface Um You enable the modules that are going to be automatically migrated both in Drupal 7 and in Drupal 10 You go to your domain slash upgrade and then you follow the wizard In the wizard you are going to be asked to enter the database credentials and if you want to migrate files You will also be able to provide either a fully qualified domain name for uh, or A path on the same server from which you you will be able to pull the files Um after providing the credentials you are going to be presented with a page like this It's like a summary. Um, there are 31 modules that can be upgraded automatically There are 11 that will not be upgraded automatically And I want to highlight that you need to take this screen with a grain of salt because uh, it is not always 100 accurate for example um views When I took this screenshot the other module that I mentioned before was not around so, um But according to this, uh The screenshot itself is that is cropped down But there were two options one views appear twice in the modules that cannot be upgraded Only the modules that could be upgraded. So at the very least it was confusing why it appeared twice Another thing address field address field if if you can see in Drupal 9, I have the address module. So The address module provides an automatic upgrade path from address field in Drupal 7 And it is enabled on both sides and still appears As part of the module that will not be able to be upgraded automatically. So again a little bit confusing Um block in Drupal 7 was broken down into two modules in Drupal 10 So You need block and custom block if you only enable one of them the block migration will not be complete So some of these come with trial and error or you know coming to sessions like this that give you a high level overview of how the system works but The point is treat this page as a reference And for the most part you might need to You know run the process at least twice like See how it goes the first time See what worked what didn't work and then do it again But um, this is like you reviewed after you reviewed It is going to perform the upgrade again. It is not customizable. It is going to do as much as possible Um Everything that happens is going to be locked in the database. So after the process is complete I recommend that you go to the locks that you review the messages that you review the general configuration of the site The general content of the site and I say it and as I said before very very likely You will need to do it again because the very first time You are you are going to find surprises of things that work or didn't work But you know after two or three runs uh You profit like you you you got an a set of rated with relatively very little effort Now if you want to go the other route, which is uh more flexible You will be using the command line again like The last time that I presented this uh, this slide was a little bit different The one thing to remember is uh drosh Just like Drupal is evolving The modules around uh migrate are also evolving and they do not necessarily evolve at the same pace So at some point there might be incompatibilities between drosh versions and let's say migrate plus or migrate tools or migrate upgrade so As of today the latest stable release of all the modules that are needed and drosh itself are compatible But sometimes that is not the case and you need to you know figure out what things why things are not working And you need to pin down specific versions for them to work But as of today if you are going to start a project today everything in the latest stable releases is working Now um, what do you do again you install drupal using the minimal installation profile You enable the migrate module, which is the core api migrate drupal to get the source and process plugins migrate plus and migrate tools and migrate operate You enable again the drupal 7 and the drupal 10 modules that are going to be Automatically migrated and this is where things start to change before you had a A form in the interface where you will provide that database credentials When you do it from the command line, you actually modify your settings that php file and add a new database connection Basically the same information that you provided in the form you do here um And then via the command line you run the migrate operate Command there is something that I want to highlight the In the database arrays the first key where it says legacy That is what you're going to use in the operate migrate operate command where it says legacy db key You know, that's why it says legacy. You can name that whatever you want Uh But in this case it's legacy. That's what I have it there And the important part of running this command is passing the configure only flag If you don't pass the configure only flag when you run the command It is going to produce exactly the same result as if you're running from the user interface Uh, but we want to be able to customize the migration. So we we pass the configure only flag I'm going to explain what it it does in a moment when you run that Um, a lot of migrations are going to be generated for you But where are those migrations that migrations are in Drupal's active configuration? And if you attended another session about the topic, you will know that by default The active configuration is storing the database. So How do you get the files so that you for you to modify them? You need to export the configuration. Uh, you can do that using drosh. So you do a Config export and all the migration files that were generated are going to be exported to the default config directory This is just like a very trimmed down version But you can see that core dot extension is in the same level as the rest of my migration files Now when you have both files again, you have multiple options to run them You can run everything using a group flag This is going to produce the same result as if you do if you do it from the UI Or you can say I only want to run configuration migrations Or I only want to run content migrations and you can do that by using the tag flag But what I recommend is actually reviewing the migrations that were generated and cherry picking only what you need as I said before There is a high chance that something is not longer be needed or has to be changed In this example, I'm going to show how to How to convert nodes to paragraph entities in in the new site. So I bear with me a little bit in this case What I did is I created a custom module called ud drupal upgrade and in my config is I created a config instant folder and I Moved the migration that I care about into this folder And then I can start modifying those files. So This is an example of a content model change the migration for the ud book content type in this case Used to be notes in drupal 7 The annotation number one you can see that I'm using a source plan for notes The notation number two is mapping the Fields and the base properties of notes in drupal 7 to fields in paragraph in drupal 10 And in the notation number three I'm saying that I want to migrate this into paragraph So this is a very simple example of how you can change from one entity to another Another example would be changing notes to user entities Um And I will be going over other examples throughout the the presentation, but be mindful that When you do it like this, you have the option to customize the migrations and change entity types and so on now by default if you run the Migrations today, you will get what is called a node complete migration That means that you will get the latest revision All the history like past revisions and all the translations In one go if you don't care about The history like previous revisions if you don't care about translations Or if you want to have more control as to how those elements are going to be migrated You can fall back to what is called a node classic migration And you do that by again updating things that php with You know setting true to the migrate node migrate type classic And instead of getting one migration per content type that does everything You are going to get three one for the primary active revision one for the previous revisions and one for the translations Another thing that I want to highlight is that when you use the migrate upgrade module By default the migrations that you get are managed via configuration as configuration entities And this is provided by the migrate plus module. It is not the only way to work with migrations Because This is like the default behavior that is why I show in the presentation And when I was cherry picking the migrations I had to put them in config install and I had to treat them as configuration entities If you make any changes to the files For the changes to be detected you need to import the configuration again You need to sync the configuration. There is a drosh command called drosh config import partial that you can use to You know trigger those file changes to the migration And when you run them when you create the migrations like this You can run them either from the command line or from the user interface using the migrate tools module Another way and this is lately what I have been doing more Is just using migration plugins for the most part. The two key differences are that instead of creating a config install directory You create a migrations directory within your custom module and the pattern for the Filing is going to be a little bit different. But other than that, you know, they work for the most part the same way and The reason why I like this approach is because if I want to Make changes, I only need to clear the cache and it's faster than having to Import configuration because sometimes you are working at this like on the configuration of the site at the same time that you are working on the migration And if you're not careful, you might be like Overriding your own work. So that's why I prefer this approach And you need to run the migration from the command line And this is something Well, not new but something that I want to share today like two hours ago I released a new contributed modules related to migrations And this is for something that I have found Like a lot in the price that I have been working on when talking about Making content model changes many many times You want to drop A field You don't want to migrate that field because let's to give a concrete example You were using radio activity in Drupal 7 And you don't want that in Drupal 10 for whatever reason When you run the automatic migration is going to try to operate everything but then When he tries to get to the radiative radio activity field It is going to break because he doesn't find a suitable Drupal 10 alternative So many times this is the type of errors that you are going to get and that you need to manually review So because basically I find this error in every project that I worked on I created a module and made it available for the community And with this module you will be able to escape fields Based on different criteria. You can do it by entity type Let's say I don't want to migrate any field that is attached to node q in Drupal 7 You can also do it by bundles Like I don't want to migrate any field that is attached to the article content type in Drupal 7 Or specifically by field name Or you can also say I don't want to migrate any field of this type like Video or radio activity or something else. So if again like This is probably the most common error that I find So just to make it easier for myself and to share it with the community I released this module earlier today. So I invite you to try it out and you know provide feedback Now some general tips and recommendation If there is one thing that I would like you to take home after attending this session is this slide Leah borough author of css secret says that understanding the process of finding a solution Is far more valuable than a solution itself? And the reason why I bring this up is because I used to Provide a lot of support in slack in the migration slack channel with a lot of other people And many times people go there and ask very specific questions But they just want a snippet of code that they can copy paste and that would be Um, you know, that is fine. Sometimes we're able to provide those snippets of code and they work but sometimes That is not the case and spending time on learning how the migrant api works outside of An upgrade project Will help you a lot when you actually need to to perform an upgrade Um, the book that I referred before 31 days of migration you can read it online for free and again like if you Don't know anything about the migrant api that could be the start And when you fade challenges That are more complicated in in as part of the upgrade process You will be able to you know ask More specific questions or you will be able to understand better the Recommendations that we provide and in general it's just like a good idea to understand the tools that you are using so Again going back to tips and recommendations Be mindful of The concept of Drupal entities and particularly what is a content entity and what is a configuration entity? for example Drupal comes with two no Uh, two content types by default. So the content types belong to the node type entity There are no nodes created which would be uh content So as long as you understand the difference between configuration and content It is going to be very helpful One one thing to note About 90 percent of the products that I have worked over the past I know five years that I've been doing migrations pretty much full time They only do content migrations And the reason is Because they want to use a completely different Content model or they just want to benefit from models that were not available before and they just like want to start from a scratch Normally what they do is like They build the site from a scratch just like the structure the shell of the site And once that is created they move over the content So if you understand the difference, uh, what is content and what is configuration? You will be able to more easily cherry pick the migrations that were generated To only select the ones that are related to content and to be able to make the adjustments as needed And again, I will be talking about those content model changes later on but Just be mindful of the difference between content and configuration entities In terms of content entities, it is good to know why are the different entity properties Also called base field definitions For example, nodes have a node id, a bid The langcode, the type, the status, uid, title when it was created and so on So this is just like A subset of all the different options It is also good to know if they are fieldable or not And if they have bundles or not For example, users can have fields but the user entity doesn't have bundles Files cannot have fields nor bundles Media can have both. So again, like be mindful of All these different combinations And this is useful because When you migrate a Drupal site, there will be different entities that are going to be connected to one another And if you understand how they are connected, how they are related You will be able to make changes to the content model easier For example, in this case, I have Nodes connected to files directly But let's say that in my Drupal 10 site, I want to leverage the media suite of modules So I want to have a media entity in between. How do I do that? Okay, from node, I'm going to make a relationship to media and then from media I'm going to make a relationship to files And as long as you understand, you know, what are those In between entities that need to be created, you will be able to do it again easier Other general recommendations, measure tries, cut once Again, the major API is not only for upgrading from Drupal 6 or Drupal 7 There is actually a bigger use case for it So if you spend some time learning the core of the API, how it works It's going to be very useful for this And you have the book that I talked about before And if you have the time and the technical knowledge Another thing that is very, very useful is Understanding how the modules in Drupal 7 and in Drupal 10 Store data because ultimately what you are doing is moving content and data from one database to another So if you know that, oh, this data, this field type has, you know Three columns and that is the data that I need to move over That is going to be useful when you need to do like very, very custom migrations One example would be if you have fields that you want to break down into multiple ones Or if you have fields that you want to combine into one Understanding the underlying that structure is very useful And I have another presentation in which I give more concrete examples of how to look at the data model There is a website called Drupal.tv And if you look for dinarcon or Mauricio Dinarte, you are going to find recordings to those Sessions that are more technical and The one caveat is that if you are going to be Creating these like very, very custom Migrations be mindful of revisions and translations because usually those are stored in separate tables Or separate columns. So be mindful about that Also create custom plugins as needed source and process plugins are the ones that you are going to create most often Now As I said before it is okay to deviate from the norm like the migratory API has some assumptions It expects you to work in one specific way But real life is different sometimes and you cannot abide by by the rules all the time. So It is possible to migrate a site that has content and that has configuration already And most of the projects that I work on that is the case The only thing that you need to be mindful is about the entity IDs. So to avoid collisions There are different strategies about that But just be mindful of How to deal with the entity IDs Another thing is that I have worked on projects that are like 9 months 12 months 15 months like they are just like Have a very long life span and it would be impractical to You know have built everything and only till the very end start working on the migration So it is possible to you know have you know site builders and developers build part of the site And then someone working on migrations Create the migration for what has already been built and then more people are building and then someone else is like Working on the migrations along the way the only thing is that I have worked on projects in which something was changed No, three months later And you need to be very mindful about the migrations like if you change something But you don't change the migration things are going to break. So you can have test suites. You can have a CI As part of your of your ci process to run a partial migration and if something fails You are going to get an error and that's how you can identify that there might be configuration change that broke what a migration that had already been implemented and Again, just to give an example the majority api can read from multiple sources I think it was like two years ago I work on a Drupal 9 project that was upgrading from Drupal 6 Again, it was long running. They needed to do testing with the content before like launching the site So for that specific project, we had three sources for the for the final site Drupal 6 which they were using very pretty much in the last minute A Drupal 9 environment in which they were entering content Just for practicing purposes But part of that content was supposed to go live at the very end and we had csv files Again, like so we were Getting content from three different sources into one final site and the very end things work out very well More tips start from an existing migration In the As I said before like this presentation is really like a full day workshop And there are like real and complete examples of how to perform a migration So if you have that time, I recommend that you look at the resources and you set up the local environment and run the migrations and If you have something that know that works you can start tweaking that You know To test to practice Read the official documentation the married apis in my opinion one of the best documented apis in the whole of Drupal I find it really useful. It's like one of my bookmarks that I visit every day The the one that lists the process plugins in Drupal core. It's it's very well documented The files that you create are using jamble and jamble is very sensitive to white spaces So an extra white space or a missing white space can break the file But it's not that your migration is wrong. It's like the file itself The syntax is not correct and it will produce a fatal error basically, so be mindful about how you write the files themselves If possible Like divide the migration work in small chunks and Sometimes what I do is like I do one feel at a time I just want to make sure that this field is working before I move to the next one Depending on the complexity of the field Sometimes I just want like every field of this type. I'm going to focus on migrating them after that type is complete I go to the next type and and migrate those but You know, again, this comes with practice Find something that works for you, but you don't want to be in a position that You migrate the whole site Something is breaking and you don't know what it's breaking because There were no like stop points that you can use as a reference Ultimately the migration Definition files is text in in jamble format So commit to your repository often again This is going to be one way in which you can recover if at some point you hit something that Doesn't work and you just don't know Why you can go back in history in in git and to a state that that you knew that was working before another thing is that You you do not you do not have to use the matter API to do all the work Sometimes it is easier to do some cleanup either in Drupal 7 before you start that migration process Or in Drupal 10 after the upgrade is complete. So You can come up with very clever and complicated Process pipelines if you will that are going to give you a perfect migration in one go But then you spend, you know, three days versus spending one hour doing a manual content update So try to balance the different options that you have Analyze the errors and learn how to debug them. This is very very important Debugging migrations is a very useful tool The the reason why I created the module is because I was spending too much time debugging errors about fields So I said that's enough. I'm going to create a module that is going to automate this for me But there are other errors that I find like only once And as long as I am able to pinpoint what the cost of the problem is I can You know provide a fix or see if there is a patch available And the the rest of the migration is going to work fine And as I said before the the migrate the migrate community in general is very active in slack in the pound migration channel Benji is one of the maintainers. He also provides a lot of support there So seek help from the community like we are very open Um the maintenance of the migrate api are distributed across the globe So almost like you can ask 24 seven and you are going to get an answer Either from a maintainer or from a volunteer Some examples of content model changes that I have done over the years again just for reference If you were using files in Drupal 7 and you want to use media entities in Drupal 10 There are modules that help you with that Maybe you had The location module in Drupal 7 and you want to use the address filling Drupal 9 You had some you know blob of text in the body field and you want to put that into layout builder You were using organic groups before and you want to use the group module now If you have inside of your body field in resources that you want to convert to media entities If you want to convert notes to a different entity type like users or groups or paragraph If there are fields or like full entities that need to be renamed or that need to be dropped But this is part of what the module does just like dropping Either full entities or fields within the entities and If you just have like plain text That you want to move into like structured data I remember a project that I worked a few years ago that they were storing like With height and depth and it was just like plain text field and In now there are they are using specific field types that You know for this purpose. So we we were using regular expressions to You know, basically convert what they had before into the new into the new field types and That is the end of the presentation, but maybe it's the start of your own journey I would like to thanks all the maintenance of the mitered api pass and present and in here in the room We have a benji and everybody who has contributed to the api. They have done a very awesome work I was talking to someone before the presentation and I said The very api is very very stable like this session I could have given like Two years ago And probably only two or three slides would have been different So it's a solid piece of work. It's very stable and with timing only gets better because there are new modules That you know, we identify a need for for a common Challenge we provide a model for that but the api itself is quite solid So, uh, thank you. I will be taking questions and uh, thanks for attending today Are there any questions? Yes alt text Okay, so for the recording I will be repeating the question If I have any recommendation for massage massaging html data and the concrete example was uh If I have images in the body field with a missing out attribute so for Image specifically, uh, there are two modules. One is called migrate media handler. The other one is called media migration Uh, they are both specific about moving Drupal 7 files into Drupal 10 media, but they provide a lot of extra like Functionality to help with that if you want to process html generally speaking like not only that The migrate Plus module. Thank you Benji wrote the plugins the migrate plus modules have plugins for manipulating The dome so you can use them directly any other question Uh Yep The question is in terms of entity ids if it is possible to know the idea that is going to be used ahead of running the migration And the answer is no part of the etl The last process of the etl is the one that is saving the node or the user or the entity itself On the little save you cannot get the number One thing Is that the migrate api allows you to Specify the id that you want to use so And that is actually the default behavior The default behavior when you run an upgrade is that it is going to fetch the same id from Drupal 7 And it's going to pass that as the id to be using the new site if And if And if in Drupal 10 you don't have any content it is recommended to keep it like that The alternative is modified the migration that was generated the file itself and remove the mapping for the id of the entity And when you do that you need to take some extra steps Any migration that is going to be related to the one that you modified You will need to use the migrate lookup process plugin to be able to map the old id to the new one The default behavior is just keep the old one if you want to deviate from that You use the migrate lookup process plugin to map the old one and the new one But in advance you cannot know it Yeah Yeah, you you you can Basically you can suggest the migrate api to use an id But I highly recommend that you Any other question Yes, the question is is is there example code for migrations? Yes, uh The migrate plus module has a lot of examples within it the Book that I wrote 31 days of migrations it comes with a GitHub repository and in there is like 20 or so different examples the if if you go to To the slides I pointed out to like the full workshop like this session, but as a full workshop And there is you know, you have the the example of a full upgrade As of like if you mean like a centralized place in which I can find all the examples I don't think anybody has Like compile them in one resource But a migrate tools There are a lot of examples there the 31 days of migration books There are a lot of example there's and this workshop There are a lot of example there's at least those are the ones that I can point out at the top of my head Yes So let me see if I get the question right You want a way to read data from the variable stable in Drupal 7 And create multiple configuration entities in Drupal 10 Okay Yes, that is possible and that is actually heavily used as part of the automatic upgrade process and there are Source plugins to read from the variable table in Drupal 7 and Depending on the destination process that you're using the You know in your custom jammel files, you can create different Con configuration entities in Drupal 10 So I cannot give you like a concrete example, but if you run this process that I just described I would say that at least that that you describe is used like 10 times like reading from variable table And creating configuration entities in Drupal 10 that that is supported out of the box Are there any other questions? Nope. Okay. Oh, thank you very very much for coming