I do this in most of my demos, but I realize that I never actually created a post about this.
Notes Migrator for SharePoint can generate the folders automatically when migrating content to SharePoint. This is accomplished via a special type of Target Data Definition Field called "Folder". All the default data definitions you get from Quest already have such a field and you can easily add them to your own custom data definitions. You can edit the Target Data Definition directly (on the Source Data tab)...
or create one on the fly while adding a new field mapping, as shown below.
![clip_image002[4]](/Media/WindowsLiveWriter/HowtoautomaticallycreatefoldersinSharePo_5A09/clip_image002[4]_thumb.jpg)
In the above example, the Categories field from the Source Data Definition is being mapped to the Folder field in the Target Data Definition. This means that for each Notes document that is migrated to SharePoint, the data value that is extracted from the Categories field will be used as the folder name in SharePoint. If the Categories field is set to "APAC" then the new document will be added to a SharePoint folder called "APAC". If a folder of that name did not exist, one would be created.
For multi-level folders, simply map data values that contain forward slashes or back slashes. These characters will be used to delimit the levels of your folder hierarchy. In the above example, if the Categories field value for a particular document is set to "APAC/Japan" or "APAC\Japan", this would cause a folder named "APAC" to be created with a sub-folder "Japan".
In some cases, you might not want to have multiple levels of folders. The "Folder" field definition actually has a special "MultipleLevels" property that controls this. This property is normally set to True, but if you set it to False, this would cause the entire data string extracted from Notes to be used as the folder name, even if it did contain a slash character.

As described in other posts, the Source Data Definition field that you are mapping from might be simple Notes data items, Notes view column values, or it might be a complex formula that computes new values as you migrate. For a simple example, the following formula would concatenate two Notes data items to assign nested folder names:
Region + "/" + @Uppercase(Country)
Finally, I should mention a Notes Migrator for SharePoint feature that many people are not aware of. The data you write to SharePoint does not have to come from Notes! You can also map Constant data values to a target field by setting the Source type to Constant instead of SourceField. If the following example, the folder name will be set to "Folder 99" each and every time. This can be very useful in cases where you want to map many Notes databases to the same SharePoint target but put each one in a different folder.
Of course, everything described above works equally well whether you are migrating to SharePoint Lists, Libraries and InfoPath Form Libraries.