There is no documented or TAC-supported procedure. The official position is that data is lost when you change directory integrations. That said, I've done it a few times for our customers. If you have some comfort level with LDAP (and LDIF files) it isn't that hard to do. You can also do this when moving from DCD to Netscape/Sun iPlanet, but the exact attribute fixups differ.
This post is not an LDAP tutorial. Bulk importing data into Active Directory must be done with care, and if it's done wrong, you can do massive damage to your Active Directory. Don't do this using the Administrator account or an Administrator-level account. There's directions on CCO on how to create and use a minimum privileged user that only has write access to your Cisco OU and a couple selected attributes on your user accounts. Then, you only use Administrator for the schema extension step. This is a very, very recommended configuration as opposed to using Administrator for everything. It also prevents screwups from affecting anything but the contents of the Cisco OU.
First you need an LDIF dump of the entire tree under ou=user_info, ou=CCN, o=cisco.com from your DC Directory. The way you do this depends on what tool you use. I like to use Softerra's LDAP Administrator tool. Once connected, all you have to do there is find the user_info OU, right click on it and hit Export.
Now, save that LDIF file over on the side and open another copy for editing. We need to do two major edits to that file so that it's compatible with Active Directory.
First, rewrite the path of each object to match where it will be stored in Active Directory. Everything gets placed in the new OU you created for the integration, which is traditionally right off the domain root and named "Cisco". So, use your text editor to do a search and replace from "o=cisco.com" to "ou=Cisco, dc=customer, dc=com" or whatever's the right path to your Cisco OU in your Active Directory.
Next, we need to repair the Personal Address Book entries to use the right object classes, as DCD stores them a little differently. The Fast Dial entries are fine as-is. Each PAB entry in the LDIF file will have object classes that look like this:
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: dcdPerson
objectClass: ciscoocUser
objectClass: person
objectClass: top
You need to replace that entire block with the following, for each PAB entry:
objectClass: top
objectClass: ciscoocContact
I don't know of a text editor that'll do multiline search and replace patterns, so unless you write a little script, you'll have to do that by hand. Even for a couple hundred, you should be able to do it in a matter of half an hour.
Now that you've got your LDIF file all fixed up, use your aforementioned favorite LDAP tool to import that file into Active Directory. Everything should magically start appearing on the user's phones, and Attendant Console user preferences will come along as well if you have any of those. Keep in mind you'll still have to fix up user's PINs and/or service subscriptions so they can actually access their PAB/FD services.
I can't predict the result of this import and the behavior of PAB/FD if the users have already set up PAB/FD entries in Active Directory prior to your import. The numbering of those entries could and probably would overlap. You should be able to see in LDAP who has those entries already, and either exclude that information from the import or delete it so that the import can go smoothly.
With a little more patience and engineering, you can actually port over the LDAP stored configs for IPCC Express. In the cases I've dealt with, we let IPCC Express build its configuration and repository and just move the LCC OU since IPCCX won't create that for you anytime except during the initial install.
If people have some further level of interest or curiosity here, I can follow up and attach before-and-after example LDIF files.
