I’m putting this here because I think new users will benefit most. You are working on a tutorial, you just created something nifty and instead of building it from scratch you want to transfer (migrate) it to another project and save some time and effort. This may or not be that helpful of an endeavor as compared to just building it again from scratch.
This is not an all encompassing how to, but I can related to some of my experiences with migration.
My first example was migrating an edited character from one project to another. I added some abilities to the default character blueprint named something like BP_ThirdPerson_Character. I added to it blueprints that enabled me to toggle walk-run, with a keystroke, and to zoom from 3rd person to 1st person view. This involved also creating actions, that go into the Project Settings files under Engine-Input.
When I selected this character to migrate, I got a very long list of dependencies:
- ControlRig items
- Mannequin>Meshes- SKM_Manny and SKM_Quinn
- Mannequin>Animations
From this large list of dependencies, I deselected all of them except for the edited Blueprint itself, of which I had changed the name from the default character to easily identify it.
My fear was that the long list of dependencies would be broken my character after migration would be broken. For this case that fear was unfounded.
Of note I first got a message “warning, you are not migrating this to the Content Folder”. That is ok, because I was going to put it in the Third Person Character folder, inside the Content folder, with the other Character blueprints. (For newbs, characters are blueprints. And additional blueprints can be placed inside the Character blueprint to give this character more abilities.)
For the long list of dependencies, all those exist in the target project, and my character could relate to them and was basically functional. However to get the extra abilities I had added, I did have to go to the Project Settings file and add the actions required, there were 3, walk-run, camera zoom in, cameral zoom out, not hard to add at all.
Now if I had chosen to move the long list of dependencies to transfer over, this is the major weakness of migration. All the items from the list of dependencies would have been transferred over to the new project into a single folder all jumbled together, having lost their folder hierarchy.
So here migrating the single blueprint was clearly the way to go, because all of those dependencies are duplicated in the target project, were not needed, and as a newb, with a pile of transferred mixed together assets, you’d be wondering if I dump this stuff will my character stop working? In this case, the character blueprint still worked by not “maintaining dependencies”.
Now I’ll describe what might be the nightmare scenario of migration. You’ve got a nice level with a height map you created in a project, you’ve applied landscape layers, and you think, it would be really nice just to just move this to a new project intact.
You can do this, when you get the question about should the gigantic list of item dependencies be placed into a single folder so dependencies will be maintained, you’ll say yes.
If you say yes, all of it appears in the target project, target folder you create, all jumbled together, all folder structure lost. Sure in my case when I did this, the level loaded up and all the landscape layers were there as I had left them in the original project, but what an project organizational mess! There were all sorts of assets I had no clue of where they belonged and where they should go. If you cherish organization, and are like me, a semi-UE novice, forget this option.
Now if you are a UE expert, this might be a good way to do this, if you know where everything goes, all dependencies maintained, just create some folders and place everything where it belongs.
Option 2 is to choose the option not to maintain dependencies. What you get for this is all the content comes over with folder structure intact, but then you have to put stuff back together.
My perspective is that this is the better choice for project organization. I did have a material and material functions where nodes had to be reconnected, but because I had the original project intact, this was less of a hassle. It was pretty easy to reference that to reconnect stuff in the material, and to place the texture samples in the correct locations.
Option 3 is just to build whatever it is that you want to migrate from scratch in the new project.
I hope this post is helpful to someone. 