This worked because 5.0.x to other 5.0.y upgrades don't reload the LDAP database, so if the schema is out of sync during the upgrade process, nothing fails. However, when you go from 5.0.x to 6.0.y, the database is completely dumped via slapcat, and then reloaded. This is because both the OpenLDAP and BDB versions changed significantly. Prior to doing any 5.0.x to 6.0.y upgrade, any custom schema modifications must be loaded in. I'm still writing up the documentation on how to do this, which is why upgrades where custom schema are involved are not supported currently. They will be for 6.0 beta 2. Once I get the instructions written, you can certainly try the 5.0.x -> 6.0.y upgrade with them (there's nothing specific to Beta 2 about the process).
Originally Posted by linxunet
However, I'd need to have more data on what specifically you've done, schema wise, to even know if your data is able to be validly ported.
For example, if you modified the existing zimbra objectClasses to include your new attributes, then you will need to manually fixed your data to be using your own auxiliary objectclass with those attributes prior to loading it.
If you created your own auxiliary objectClass already, with your own attributes (which of course, should be suitably named, like "myCustomAttr" not "zimbraXYZattr", as anything prefixed with zimbra means it is a zimbra attribute) it should be fairly straight forward for you to do this once I finish the instructions on how to do so.
Zimbra :: the leader in open source messaging and collaboration