KM Transports web blog is a series discussing in detailed about transport strategies in KM. The current one is the fifth part. For previous and succesive parts and for a quick look on all of my web blogs please click here. in the previous part we actually created a content transport package for KM. Having done with the export of the content, lets now see how we can import it. For importing again we would need system administration permission in the destination system (Or Content management role in specific). Now we log in to the destination system with the appropriate user. Then we start the import process by the traditional first step in any configuration modification we do. We take a back up. The backup now is for the content. So we create a backup package just like how we created the export package in the previous blog. Only the system differs. Last time it was the source system for transporting and this time it is the destination itself for backing up. We don’t use it and we might not probably use it at all. But its always a good practice to take the backups before we start changing them. For learning how to take the backups, refer my web blog KM transports: Part IV. You got to interpret the content there accordingly. Now after we have taken the backups, we will goto Content Management ® Content Exchange. There click on “Package Upload” in the detailed navigation menu. You would get a file upload form, then. Enter a name for the file and browse and select your file. Then Upload it. What happens after you upload is the ICE service interprets the Zip file and puts contents in appropriate repositories as specified in the file. So when you upload the zip file, it is actually uploaded in the ICE repository in the KM repositories from where the ICE service runs. You can also notice at no point of time during this import process have you specified which content should goto which folder and which repository, that’s because all those details are very well there in the file already. All you got to make sure is the target repositories are already created. Because the repositories cannot be created as easily as creating a folder. It has lots of services that the user might opt to enable/disable. So the constraint is the same repositories should exist in the destination systems too. Here are some of the links that you might find useful in further reading about KM Transports, Link 1 Link2 Link 3 To sum it all, we saw how to do a KM transport. Basically the KM has to be transported as content and config as well. We saw the config transport in KM transports: Part II and KM transports: Part III. We saw that content transport for KM can be done in two methodologies namely ICE and WebDav. We saw ICE methodology of KM Content transport in KM transports: Part IV and Part 5 (current one). In the next blog, we would see the WebDav methodology of KM transports for content.