Content Migration from TeamSite 7.3.2 server to TeamSite 8.2 server

Hi All,

 

Did anyone try content migration from TeamSite 7.3.2 server to TeamSite 8.2 server?

 

We have 210 GB of content ( which has 10+ branches, 30+ editions ), so it will take huge amount of time in migration. Instead, I am planning to migrate just one workarea per branch which comes to around 10 GB. I tried to copy one branch using rsync command, but when I try to edit any DCR's they are not getting opened. TeamSite is treating them as binary files or plain XML's. Do we need to run any script to make these plain XML's to TeamSite understandable DCR's?

 

Am I missing any content migration steps? It would be great if anyone has content migration steps.

 

Thanks

Vinod Goud

Comments

  •  

     

    Horrid approach.  I am doing the same thing, 3 TB store on Solaris going to Linux

     

    Choices, copy up the complete iwstore and copy it directly.  That is the easiest. 

     

    If you need to continue to migrate, use iwmigrate to continually update.  

     

    I do not bother migrating workareas,  people need to know that, but doing that increases the complexity significantly. 

  • and the reason that the DCRs don't work is because rsync doesn't copy extended attributes. Write a script to dump them to a file and apply them. Still a very poor approach. DCRs are not the only things that may have EAs. 

     

    You could use OpenDeploy to copy a WA from A to B, but you will likely have issues on submit because of conflicts.  You also are losing all history/ 

  • Hi Andy,

     

    Thanks for the reply. Based on your response it seems content store migration seems to be good to go solution rather than doing workarea.

     

    Are you doing 3TB of content migration? How long it took for the content migration? Are you freezing out or shutting down the Solaries machine?

     

    The only reason I am worried about the content store migration is that we need to shutdown teamsite server on machine A to avoid any file corruption during content migration. TeamSite server on machine A will be used by our business partners. If the content store migration is going to take more time then more downtime for teamsite server.

     

    Is it mandatory to shutdown the teamsite servers while doing content migration?

     

    Are you using scp or rsync to copy the content store from server A to server B?

     

    If you have successfully done with migration, can you please share the migration steps that you have followed. 

     

    Thanks

    Vinod Goud

  • With the 3 TB we moved to the cloud.  We are shutting down the existing server. 

     

    We added a lot more disk (about 4 TB), shut down TS for the weekend and took a snapshot -> tarball -> compress -> split   so in the end I have about 750 4 GB files that could be packed together and uncompressed/untarred to the new store. 

     

    I am also running iwmigrate weekly as we are keeping the 2 servers in sync for a short period of time, qhile QA is going. 

     

    If you have a reliable backup you can take the latest backup and move it to the new server.  We would have done that however, then we would have needed even more disk (3 TB for the backup and then 3 more for the split tar files) 

     

    You can use scp to move them, however we used an AWS product called SNOWBALL,  basically a 50 TB zip drive. Plug it into the datacenter, copy everything to it and then ship it to Amazon

     

  • Thanks Andy for the info. Now I get confidence that I can easily migrate 210 GB of data.

     

    Did you run any commands on new teamsite server once the content is migrated? Or by just restarting the teamsite server you were able to see all the content in new server?

     

    Thanks

    Vinod Goud

  •  

     

    Just make certain the permissions and ownership is good and that the store is good. 

     

    I would run iwfsshrink to drop the size.  iwfsck would be a great idea but that has to be when the server is offline. 

  • Thanks Andy.

Sign In or Register to comment.